MCP 服务器该放在什么地址？我们查了 33 个

公开的 MCP 服务器都用什么 URL？

大多是专用的 mcp. 子域名，路径通常是 /mcp。当时我们正在 mcp.scorestarling.com/mcp 和 ElevenLabs 那种写法 api.scorestarling.com/v1/mcp 之间犹豫，想知道其他服务实际怎么做，就去查了一圈。

2026年10月2日 17:40 至 17:42（UTC），我们向 27 个服务的 33 个地址各发了一个不带认证信息的 POST 请求：请求体为 {}，带 Accept: application/json, text/event-stream 请求头，超时 8 秒，只记录状态码。401 表示这个地址上有服务响应，并且需要令牌，受保护的 MCP 服务器正是这样开始登录流程的。404 表示这个路径下没有任何服务。有些地址是各服务公开的，另一些是我们为了看哪些路径有响应而尝试的变体和猜测。这只是一些知名服务的快照，不是普查，其中任何一个此后都可能有变化。

最有用的教训来自那几个 404：MCP 的 URL 无法从域名推断出来。Stripe 和 Vercel 在不带路径的域名上响应，访问 /mcp 反而返回 404；Higgsfield 正好相反；ElevenLabs 则必须带上 /v1。客户端只会原样使用拿到的 URL，而 RFC 9728 把这个 URL 定为服务器元数据必须匹配的身份标识，所以文档、安装链接和插件清单里必须是同一个字符串。插件清单里的写法更是五花八门：在我们装过的插件中，有直接挂在 gitlab.com 主站路径上的 gitlab.com/api/v4/mcp，还有 mcp.hubspot.com/anthropic。这两个我们没有探测。

MCP 端点该和网站共用一个域名吗？

我们认为不该。端点是给软件用的，连接指南是给人看的，两者都想占用那个最直观的地址。2026年10月2日之前，scorestarling.com/mcp 是我们的 MCP 服务器，指南只能放在别处；而且每个客户端都是靠这个 URL 返回的 401 找到登录入口的，它不可能同时又是一个网页。

我们考虑过在同一个 URL 上同时提供两者，给浏览器返回网页、给客户端返回 MCP，但没有把它当作长期方案：对请求的判断只要错一次，所有客户端都会找不到登录入口。传输规范还允许客户端向端点发送 GET 请求来打开事件流，期待的回复是事件流或 405，而不是一个 HTML 页面。

单独的域名还能让网站的改动影响不到端点：网站改版挪不动它，适合营销网站的 CDN 缓存或浏览器人机验证也永远不会挡在它前面。AI 助手是从自己的基础设施而不是浏览器调用服务器的：Anthropic 的连接器文档说，Claude 从 Anthropic 的云端发起连接，身份提供方前面的防火墙可能导致登录失败。我们看过的两家同行也是这样拆分的（2026年10月2日查看，10月3日复核）：Higgsfield 的指南在 higgsfield.ai/mcp，服务器在 mcp.higgsfield.ai/mcp；ElevenLabs 的指南在 elevenlabs.io/mcp，服务器在 api.elevenlabs.io/v1/mcp。

我们的 MCP 域名只提供 /mcp 和 /.well-known/*。其他路径一律以 308 重定向到网站上相同的路径和查询参数，这样登录、授权同意、页面、下载链接和 Cookie 都留在同一个域名下。网站上的 /mcp 现在是 Claude、ChatGPT 等客户端的连接指南。

$ curl -si "https://mcp.scorestarling.com/login?x=1"
HTTP/2 308
location: https://scorestarling.com/login?x=1

选 mcp.example.com/mcp、不带路径的域名，还是 api.example.com/v1/mcp？

三种都可以，看这个域名上还放了什么。MCP 授权规范把 https://mcp.example.com/mcp 和 https://mcp.example.com 都列为合法的标准服务器 URI，并要求使用不带末尾斜杠的形式，除非斜杠有实际含义。传输规范只要求有一个同时接受 POST 和 GET 的端点路径，示例是 https://example.com/mcp；Anthropic 的连接器文档用的则是 https://mcp.example.com/mcp。

还有两条小规则。Streamable HTTP 端点不要以 /sse 结尾：Anthropic 的文档说，在 Claude 的连接器表单里，以它结尾的 URL 会选用旧的 SSE 传输方式。另外，除非确有必要，不要加末尾斜杠；返回 401 的 23 个地址里，只有 GitHub 的带了斜杠。

怎样把 MCP 服务器迁移到新 URL？

让新旧两个地址并行一段时间，并且每个地址都要能独立完整地工作：有自己的 401、自己的元数据，两种受众的令牌都能用。我们分四步完成迁移，在 2026年10月2日晚（UTC）一小时内全部上线：

1. 趁还没有任何地方用到，先上线别名支持。用一项配置列出以前的地址，每个都必须是 HTTPS、以 /mcp 结尾。令牌的受众是当前地址或某个别名时验证通过，其他受众一律拒绝。主机白名单（Starlette 的可信主机列表和 MCP SDK 的 DNS 重绑定防护）包含所有地址以及网站本身。没有设置别名时，生产环境的行为与以前完全一样。

2. 添加新域名，然后在同一次变更中切换地址并设置别名。新子域名先配好 DNS 记录，大约 6 分钟后证书也签发了；在我们的服务器被配置为信任它之前，这个域名一直返回 400。一次配置变更既设置了新的资源 URL，又把旧地址列为别名，所以只重新部署一次就让两者同时生效。如果在第 1 步上线前就这样做，正在运行的代码会拒绝网站自己的域名。

3. 把所有会被人复制的地方都改指向新地址：连接指南（包括为 Claude、Cursor 和 VS Code 编码好的一键安装链接）、插件清单和文档。

4. 切换令牌受众，然后停用旧地址。一次数据库迁移让我们的访问令牌钩子改为签发新的受众，CI 在代码上线前就应用了这次迁移；别名还在时，两种受众的令牌都照常可用。随后我们删除别名并重新部署。在那次发布和重新部署之间的几分钟里，网站的 /mcp 对浏览器返回指南，对 MCP 客户端返回服务器。现在它只提供指南，指南原来的地址 /connect 则以 308 重定向过来。

最容易漏掉的是元数据。RFC 9728 要求其中的 resource 与客户端连接时用的 URL 完全一致，Anthropic 的文档也要求它与用户在 Claude 里填写的 URL 相同。所以在新旧并行期间，每个域名都描述它自己，每个 401 都指向本域名下的元数据文档：

GET https://scorestarling.com/.well-known/oauth-protected-resource/mcp
→ "resource": "https://scorestarling.com/mcp"

GET https://mcp.scorestarling.com/.well-known/oauth-protected-resource/mcp
→ "resource": "https://mcp.scorestarling.com/mcp"

我们没有对 /mcp 本身做重定向。传输规范没有为端点规定重定向行为，而端点 URL 作为资源（resource）和令牌受众，是 OAuth 握手的一部分，所以我们选择在两个地址上同时提供 MCP。其他路径则用 308 而不是 301，这样能保留请求方法，因为 RFC 9110 不允许客户端在收到 308 后把 POST 改成 GET。受众是怎样写进令牌的，见我们关于 MCP OAuth 的笔记。

我们能迁得这么快，是因为 ScoreStarling 当时还处在仅限邀请的小规模试运营阶段，还没有人依赖旧地址。别名删除后，仍配置着 scorestarling.com/mcp 的客户端必须重新连接。按照我们运维手册的预期，已经改用新地址、手里却还是旧受众令牌的客户端，会收到一次 401 invalid_token，随后刷新令牌、拿到新受众；不过我们还没亲眼看到真实的 Claude 或 ChatGPT 客户端这样做。如果已经有真实用户，就保留别名，直到旧地址不再有流量。

迁移过程中出了哪些问题？

过程中出了三个小问题：

• 一个检查脚本用 resource.replace('/mcp', '/.well-known/oauth-protected-resource/mcp') 拼接元数据 URL。旧地址上没问题；换成 https://mcp.scorestarling.com/mcp 后，//mcp. 里的 /mcp 也被匹配到了，结果变成 https://.well-known/oauth-protected-resource/mcp.scorestarling.com/.well-known/oauth-protected-resource/mcp。正确的做法是先解析 URL，再按各部分拼接：协议和主机名，然后是 well-known 段，最后是路径。
• 地址变长后，在 320 像素宽的屏幕上撑破了指南页的版面，直到我们允许行内代码换行才解决。
• 用 Railway 命令行工具删除别名变量，只是把改动暂存了起来；直到我们手动重新部署，旧地址都还被接受。

MCP 服务器地址选择清单

• 给端点一个专用域名，不在上面放任何给人看的内容；在我们的样本中，常见做法是 mcp. 加上你的域名。
• 路径一次定好。/mcp 最常见，不带路径的域名也合法；不要加末尾斜杠，也不要让路径以 /sse 结尾。
• 给人看的连接指南放在主站上，用一个猜得到的地址，并在导航里加上链接。
• 为这个确切的 URL 提供 RFC 9728 元数据：放在 /.well-known/oauth-protected-resource 加上你的路径处，根路径下也放一份，其中的 resource 要等于客户端使用的地址。
• 把这个 URL 设为令牌受众，并在需要迁移之前就做好别名支持。
• MCP 域名上的其他所有路径都用 308 重定向到你的网站，并保留查询字符串。
• MCP 域名上不要启用浏览器人机验证和 HTML 缓存。
• 所有地方（指南、安装链接、插件清单、文档）都只公布同一个字符串，并测试每一处是否一致。
• 迁移顺序：先做别名支持，再在同一次变更中切换新地址、设置别名，然后改掉每一处引用，切换受众，等旧地址没有流量后再停用。