MCP 连不上先分层定位配置令牌与代理

更新于 2026-07-20

**MCP 连不上时按「配置 → 令牌 → 代理/TLS」分层定位，不要一上来就重装或反复重登。** 症状都是「连不上」，但断点可能在三层里的任意一层。

分层排查顺序

  1. 配置层：注册项是否还在（如 ~/.codex/config.toml 里的 MCP 注册）。
  2. 令牌层：授权是否有效、凭据是否加载。
  3. 代理层：请求是否经本机代理、TLS 是否握手成功。

判定技巧：直连能拿到标准响应、经代理失败，就能把锅锁死在代理层。实测：直连 mcp.linear.app 稳定返回标准 OAuth 401（说明端点与令牌链路正常），而经过本机 HTTP/SOCKS 代理时 TLS 握手直接失败 → 根因是 MCP 初始化继承了全局代理，连接在发送有效令牌前就被代理关闭。

  • 验证手段：用一次性 NO_PROXY 绕过代理复现，不改永久配置。
  • 修复方向：把该域名加入绕过代理的名单，而不是重新授权。

「登录失效」可能是两个不同问题

同一个「每次都要重新登录」的体感，背后其实是两件事，要分开归因：

  1. 配置项消失：注册项被覆盖/删除，但插件文件与 Keychain 授权仍在（谁覆盖的若无审计证据，不能断言）。
  2. 代理阻断：令牌已加载，但请求经代理时 TLS 被关闭 —— 看起来像登录失效，实际是网络问题。

把两者混为一谈，就会误判成「OAuth 每次失效」，然后反复重登（治标不治本）。一次性做法：注册持久化在全局配置、凭据放系统 Keychain、故障域名绕过代理、MCP 名称固定不生成新凭据槽位。

「授权过」不等于「这次连着」

排查前先分清两样东西：

  • 授权缓存（如 ~/.claude/mcp-needs-auth-cache.json）只记录「某个会话里你同意过这个服务器的 OAuth」，作用是避免重复弹确认框。
  • 当前会话连哪些 MCP，由这个会话加载的 MCP 配置文件决定。

所以「我之前明明授权过 Linear，为什么现在没连上」的答案通常是：授权记录还在，但当前会话的配置里根本没有 Linear 这一项（它在另一个客户端的配置里），于是服务器压根没被启动。

授权是「允许连」，配置才是「去连接」。 两者分属不同层，别用一层的证据去证明另一层。

相关