1. OAuth 成功与 MCP 连接成功不是一回事
| 阶段 | 成功证据 | 失败重点 |
|---|---|---|
| 发现授权端点 | 能读取 OAuth metadata | URL、DNS、TLS |
| 浏览器授权 | 回调收到 code | 回调端口、redirect_uri |
| 换取 Token | 获得有效访问令牌 | Scope、Client ID、时间 |
| MCP initialize | 服务返回协议响应 | 服务进程、代理、传输协议 |

2. 保存服务端日志和 Claude Code 日志
对齐同一时间段:OAuth 回调是否成功、Token 端点是否返回、MCP 服务是否收到 initialize、服务是否在返回前崩溃。若服务端完全没有 initialize 记录,问题仍在客户端网络或地址。
3. 检查本地回调与 NO_PROXY
本地 MCP 或 OAuth 回调通常使用 localhost、127.0.0.1 或 ::1。代理开启时应保证这些地址不被转发。
export NO_PROXY="localhost,127.0.0.1,::1"
export no_proxy="localhost,127.0.0.1,::1"4. 清理过期授权并重新建立连接
- 记录 MCP 服务名、URL、Claude Code 版本与错误时间。
- 撤销该服务的旧授权或删除对应的失效连接记录。
- 确认系统时间准确。
- 重新授权并核对所需 Scope。
- 立即观察服务端是否收到 initialize。
- 成功后再恢复代理和多个 MCP 服务。
5. 增大 MCP_TIMEOUT 只能验证慢服务
若服务确实收到 initialize 并持续处理,适度增加超时可作为诊断。但公开 issue 中存在“OAuth 成功、initialize 永远不返回”的情况,此时延长等待只会更晚失败,应修复协议响应或网络链路。
6. 用最小 MCP 配置隔离冲突
暂时禁用其他 MCP 服务,只保留一个问题服务。分别测试本地直连、代理网络和不同 Claude Code 版本,并保存每组结果。不要同时改 Token、代理、超时和服务版本,否则无法确认哪个动作有效。
7. 常见问题
OAuth 页面成功为什么 MCP 仍然超时?
OAuth 成功只代表授权或 Token 阶段完成,MCP initialize 还需要客户端连接服务并收到协议响应。
把 MCP_TIMEOUT 调大能解决吗?
只对真实的慢初始化有帮助。如果服务没有收到 initialize 或永远不返回,增大超时不会修复根因。
NO_PROXY 应包含哪些地址?
本地回调和 IDE 服务通常至少包含 localhost、127.0.0.1 和 ::1,并同步检查大写与小写变量。
排查时为什么要只保留一个 MCP?
多个服务会混合日志和失败事件。最小配置可以明确故障属于特定服务、认证记录还是 Claude Code 网络层。
* 本文由 island AI Coding 技术团队根据官方文档与公开问题记录原创整理。公开 issue 描述的是特定版本和环境,修复状态可能变化;操作前请记录版本并保留回滚路径。更新时间:2026-09-01。