ChatGPT 连不上 MCP 服务器报错“没实现 OAuth”，但服务器日志里压根没收到请求

我用自定义 MCP 服务器接 ChatGPT 时碰到个间歇性故障：同一个连接请求，重试几次有时能成、有时直接报错说服务器没实现 OAuth，可服务器访问日志显示失败时根本没收到任何 HTTP 请求。也就是说，问题出在 ChatGPT 的 OAuth 发现机制那层，跟我这边的实现无关。
先说下复现路径。我写了个 MCP 服务器，挂在 https://mcp.birdeye.com/mcp 上，OAuth 用的是 Dynamic Client Registration 加 PKCE 这套组合，配合 ChatGPT 的 MCP connector 走授权码流程。正常情况下的预期是：ChatGPT 先通过 POST /backend-api/aip/connectors/mcp/oauth_config 这个内部接口去发现 OAuth 配置，拿到 authorization URL、token URL、registration URL 和 PKCE 参数，然后跳转授权，最后换 token，整个流程走完。
但实际跑起来不是每次都能顺利。失败的时候，同一个接口直接返回 404，响应体长这样：

{"detail": "MCP server https://mcp.birdeye.com/mcp does not implement OAuth"}

关键在下面这几条观察上。第一，问题纯属间歇性，我什么都不改，原样重试同一个连接，有时候就成功了。第二，成功时 ChatGPT 那个 oauth_config 接口确实返回了完整的 OAuth 元数据，失败时就给你上面那条报错。第三，也是我觉得最可疑的一点：失败的那几次，我的服务器访问日志里干干净净，不管是 MCP 端点、OAuth 发现端点还是其他任何回调，压根没有请求打进来。
这就很说明问题了。如果 ChatGPT 真的去请求过我的服务器做 OAuth 发现，那至少得有个 HTTP 请求留下痕迹。但日志里什么都没有，说明请求在到达我这边之前就被 ChatGPT 自己拦下来了。要么是它的发现机制有缓存，缓存里存的是旧状态，要么是 connector 后端在做 OAuth 探测时直接走了短路逻辑，根本没往外发请求。
更让我确信问题不在我这边的理由是：同一个 MCP 服务器、同一套 OAuth 实现，接到 Claude 和其他 MCP 客户端上从来没出过这毛病，一直稳定工作。要是我的实现真有问题，别的客户端不可能完全不受影响。所以这大概率是 ChatGPT 那边的 OAuth 发现或连接器基础设施的锅，可能是缓存了某个失败的探测结果，也可能是并发场景下请求竞争导致探测被跳过。
顺着这个思路，我怀疑 ChatGPT 后端在判断一个 MCP 服务器是否支持 OAuth 时，可能不是每次都实际发起请求去验证，而是依赖于某种缓存或者预检机制。一旦缓存里存了一个"不支持"的标记，后续的请求就都直接短路，返回同样的报错。而重试之所以能成功，可能是因为缓存过期了，或者命中了另一台没有坏缓存的后端节点。
遇到这个问题的人，如果方便的话，可以留意一下自己服务器端的访问日志，看看失败时是不是也跟我一样没有任何请求进来。这能帮你快速区分是 ChatGPT 侧的问题还是自己服务器的问题——只要看到失败时日志里一片空白，基本就能断定责任不在你这边。
另外补充一个信息：Discourse 那个自托管社区平台也玩过类似的套路——他们提供官方托管，但也鼓励用户在自己的基础设施上跑，开源的代码放出来自己部署，社区活了十多年，靠插件和主题做定制化扩展。这跟 MCP 服务器开放 OAuth 有点异曲同工：平台方提供默认托管方案，但真正要深入集成，还是得自己动手，而且一旦出问题，排查路径往往得从平台侧日志入手，而不是盯着自己的服务器报错看。
目前我的处理方式是：失败就重试，反正重试大概率能成。但如果这个间歇性故障频繁出现，建议在客户端那边加个自动重试逻辑，遇到 does not implement OAuth 这个报错就重新触发一次连接，别急着改服务器代码。真要彻底根治，得等 OpenAI 那边修 connector 的缓存问题，或者至少确认一下是不是有已知的 OAuth 发现缓存机制在作怪。如果你也碰到过类似情况，可以对比一下自己日志里失败时有没有请求进来——这可能是定位问题最快的线索。