我遇到了同样的问题。我们将多个带有相对URL的故事书打包到一个Docker容器中，并通过相对URL引用它们，当然在构建时这些相对URL是不可用的。

这在6.0.19版本中运行良好，但现在在6.1.14版本中失败了。当比较这两个版本创建的构建输出时，我在6.0.19版本中得到的是type: "server-checked",而在6.1.14版本中得到的是type: "unknown"。我相信之前错误地返回了"server-checked",这个问题在9ed3786版本中已经修复了。

这是由这个bug修复引入的回归，应该像@tingzuge-dio建议的那样修复。

对于遇到同样问题的人，我们在我们的storybook main.js中使用string-replace-loader来解决这个问题：

managerWebpack: (config) => {
  config.module.rules = [
    {
      test: /\.(js|mjs|jsx|ts|tsx)$/,
      use: {
        loader: 'string-replace-loader',
        options: {
          search: /"type": "unknown"/g,
          replace: () => '"type": "server-checked"',
        }
      }
    },
    ...config.module.rules
  ]
  return config;
},

我们正在使用另一个解决方法，这可能会在运行时为您提供更多的灵活性(以牺牲稍微hacky的方式为代价)。
在 .storybook/manager.js 中使用以下内容：

import { addons } from '@storybook/addons';

addons.setConfig({
  refs: {
    "uniqueRefKey": {
      "id": "uniqueRefKey",
      "title": "Stories (remote)",
      "url": `${document.location.protocol}//${document.location.hostname}`,
      "type": "server-checked"
    }
  }
});

var originalSetConfig = addons.setConfig.bind(addons);
addons.setConfig = (values) => {
        if (values.refs && !values.refs.devremote) delete values.refs;
        originalSetConfig(values)
}

在这里需要 originalSetConfig 的解决方法，因为故事书默认的 setConfig 将 refs 设置为 main.js 中使用的任何内容(否则为空哈希),这发生在 manager.js 运行之后，并对此进行了清理。
可能有一种比故事书内部 setConfig 更早设置配置的方法，但这对我们有效，并且从那时起正确地使用了 stories.json。
从经验上看，似乎您还需要至少一个静态故事，否则故事书将根本不尝试启动引用。

谢谢你@tstehr,你的解决方案对我也有用。

出于某种原因，一开始使用addons.setConfig的hack对我有效，但后来停止工作。我的团队中没有人能够使用这种hack使composition与本地storybook一起工作。
如果可以在storybook内部修复这个问题，那就太完美了。

出于某种原因，一开始使用addons.setConfig的hack对我有效，但后来停止工作。我的团队中没有人能够使用这种hack使composition与本地storybook一起工作。
如果可以在storybook内部修复这个问题，那就太好了。
看起来这是由于宿主storybook的启动过程比注入的storybook早一些，在注入的storybook构建并开始提供服务之前就开始了。