MCP 连不上怎么排查：按这个顺序走六步
数据截至 2026-07，价格与限额以各官网为准。
MCP 连不上的时候，最浪费时间的做法是从最里层的业务代码开始猜。正确的顺序是从外往里剥：先确认端点通不通，再确认协议版本能不能握手，然后是授权、路由，最后才轮到能力清单和 server 本身。尤其在 2026-07-28 官方发布新规范之后，“版本对不对”这一步的排查权重明显上升了——官方称这是自协议发布以来最大的一次修订，新版本的 server 可能无法与旧 client 协同，反之亦然。
先承认一个很常见的误解：不少人默认”MCP 连不上”就等于配置文件写错了，于是反复检查 JSON 里的路径和引号。配置错当然是高频原因，但它只是六个环节里的第一个。如果你的 server 是远程部署的、走了 OAuth、又刚好赶上这次规范升级，那问题很可能根本不在配置文件里，你把那几行 JSON 抄十遍也不会好。
下面这六步是有先后关系的，请按顺序走，不要跳。每一步都给出可以立刻执行的动作和判断依据。
第一步：确认端点/进程本身是活的
MCP 的连接形态大致分两类：本地以子进程方式启动的（客户端拉起一个命令），和远程通过 HTTP 访问的。这两类第一步的检查动作不同。
本地进程类：把客户端配置里的那条启动命令，原样复制到终端里手动跑一次。这一步能筛掉相当大比例的问题——命令不存在、依赖没装、运行时版本不对、脚本第一行就抛异常，全都会在这里暴露出来。注意两点：一是客户端拉起子进程时用的环境变量往往和你的交互式终端不一样（PATH 尤其容易不同），手动跑通不代表客户端能跑通，反过来手动跑不通就一定不行；二是本地传输把标准输出当协议通道用，如果你的 server 代码里有 print 之类往标准输出写调试信息的语句，协议数据会被污染，表现就是”进程活着但客户端说连不上”。调试日志应该走标准错误或者写文件。
远程 HTTP 类：先用最朴素的方式确认端点可达——能不能解析域名、TLS 握手成不成、返回的 HTTP 状态码是多少。这一步只看网络层和传输层，不要急着解读协议内容。如果这里就已经是超时或者连接被拒，后面五步都不用看了。
判断依据很简单：这一步过不去，问题在部署和环境，不在协议。
第二步：确认协议版本能握手
这是 2026 年新增的排查重点。2026-07-28 发布的新规范被官方称为自协议发布以来最大的一次修订，覆盖六块内容：无状态协议内核、Extensions 框架、Tasks、MCP Apps、授权加固，以及一套正式的弃用策略。维护者 David Soria Parra 形容这次是自加入授权以来最实质的变更，原话是 “A lot of things that made MCP are gone.”
对排查的直接含义是：新旧版本之间可能无法协同。你会看到的现象未必是明确的”版本不匹配”报错，也可能是握手阶段直接断开、或者返回一个语焉不详的错误。所以在这一步，请把 client 和 server 两边各自实现的规范版本都拿出来对一遍，而不是只看一边。
好消息是官方这次给了缓冲：弃用机制为旧版本留了 12 个月的窗口。也就是说你不需要在一夜之间全量切换，可以让新旧并行一段时间，分批迁移。具体怎么排期，可以看 新旧 MCP 版本不兼容怎么办 和 升级前的检查清单。
另外提醒一件事：网上有些站点的信息已经过期，仍把更早的版本标为当前稳定版。判断版本这种时效性极强的事，请以官方 blog 与规范文档当前版本为准，别信搜索结果里排在前面的旧文。
第三步：确认授权链路
如果前两步都通过，连接却在鉴权环节挂掉，那多半落在授权这一块。这次规范的授权部分由 6 个 SEP（Specification Enhancement Proposal，规范增强提案）加固，目标是让授权规范更贴近真实世界的 OAuth 2.0 / OpenID Connect 部署。
其中一条对排查特别有指导意义：要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。换句话说，客户端现在会检查授权服务器返回的 issuer 标识符是否符合预期。如果你的授权服务器配置里 issuer 和实际下发的不一致——这在反向代理改写了域名、或者内外网地址不同的部署里非常容易发生——升级后的客户端就会拒绝这次授权，而升级前的客户端可能压根不检查，于是表现成”我什么都没改，升级完就连不上了”。
这一步的可操作动作：把授权服务器的 discovery 文档拉出来，看 issuer 字段的值，和客户端实际请求的地址逐字符比对，注意结尾斜杠、http/https、有没有端口号。授权这块的完整改动可以看 MCP 授权加固。
第四步：确认远程部署的路由
这一步只针对远程 server。这次修订里改动最大的一处是：MCP 在协议层是无状态的，由 6 个 SEP 共同实现，完成了 “The Future of MCP Transports” 里的计划。协议层不再要求会话追踪。
实际影响是：以前需要粘性会话（sticky session）、需要共享 session 存储、需要网关做深度包检测才能跑的远程 server，现在可以直接部署在普通的轮询负载均衡后面，按 Mcp-Method 头做路由。
对排查的含义有两个方向：
一是如果你还在按旧假设部署，比如网关上配了一堆基于会话的规则，升级后这些规则可能反而成了干扰源，表现为”偶发连不上”——同一个请求打到不同实例上结果不一致。这种时序性、间歇性的故障最难查，如果你的现象是”十次里有三次失败”，优先怀疑这一层。
二是如果你按新方式部署了但路由没配对，网关不认识 Mcp-Method 头、或者把它剥掉了，请求就会被投递到错误的地方。检查动作是在网关侧打开请求头日志，确认这个头是不是原样透传到了后端。
需要澄清一点，避免误读：无状态说的是协议层不再要求会话追踪，不是说 MCP 从此不能有状态。你的应用层要维护什么状态，那是另一回事，规范并没有禁止。这部分展开见 无状态协议内核 和 MCP 部署与负载均衡。
第五步：连上了但工具没出来——查能力清单
有一类故障不该叫”连不上”：连接建立成功，客户端也不报错，但工具列表是空的，或者少了几个你确定写过的。这时候排查方向要换。
新规范里有一处直接相关：用于长时间运行操作的 Tasks 特性，已经从核心协议移到了 extension。也就是说它不再是内核的一部分了。如果你的 server 依赖 Tasks 相关能力，而对面的 client 没有启用对应的 extension，那这部分能力就不会出现在你以为它该出现的地方——连接是好的，功能是缺的。
Extensions 框架同时也允许用户自建 extension，与官方认可的 extension 并存。这带来灵活性，也带来一个新的排查维度：两端启用的 extension 集合是否一致。排查动作是把 client 侧和 server 侧各自声明支持的能力列出来做交集，缺什么一目了然。细节参见 Tasks 移出核心 和 Extensions 框架。
这次修订还包含 MCP Apps 这一块，但官方博客没有展开细节，具体形态和对客户端的要求请以官方规范文档当前版本为准，这里不替它下结论。
第六步：核对 server 本体
走到这一步还没解决，就该怀疑你手上这个 server 本身是不是你以为的那个了。
官方维护着 registry.modelcontextprotocol.io 这个 MCP Registry，提供 server 的发现、文档与 API 参考，由 modelcontextprotocol 这个 GitHub 组织维护、社区驱动。排查时它的用处是给你一个可对照的基准：这个 server 的官方文档怎么写的、当前版本是什么、有没有已知的兼容性说明。别只看某篇教程里的配置片段就认定它是对的，教程会过期，注册表和仓库文档更新得快一些。
路线图里还有一项叫 MCP Server Cards：通过 .well-known URL 暴露 server 元数据的标准，让注册表和爬虫不用真的建立连接就能发现能力。对排查的意义是，未来判断”这个 server 支持什么”可以不必先连上去试。可以关注 MCP Server Cards 和 官方 Registry 两篇。
顺便说说这个协议现在的位置
排查之外，有个背景值得知道，它能帮你判断”要不要为这次变更投入时间”。
MCP 于 2024-11 发布，到 2026-07 大约一年八个月。2025 年 12 月，Anthropic 把它捐给了 Linux 基金会下的 Agentic AI Foundation，成为厂商中立、社区治理的标准，到现在约七个月。OpenAI、Google、Microsoft、AWS 这四家主流厂商都已经把它接进了自家的 agent 栈。
规模方面，按官方与行业公开资料的口径，有超过一万个公开 MCP server 运行在生产环境中，SDK 月下载量超过 9,700 万。这两个数字来自公开资料汇总，不是精确统计，看个量级就好。
这套顺序的局限
得诚实说几句它不管用的地方。
第一，它假设你能拿到两端的信息。如果 server 是别人托管的黑盒，第二步到第五步你只能靠对方的文档和错误信息去猜，排查效率会大幅下降。
第二，它对具体客户端的实现差异无能为力。同样是”连不上”，不同客户端的报错措辞、日志位置、重试策略都不一样。特定客户端的坑得单独看，比如 Claude Code 的 MCP 连不上怎么排查 就有一批 Claude Code 独有的检查点。
第三，这次规范发布时间很近，中文资料几乎没有，工具链和各家客户端的适配进度参差不齐。你遇到的问题有可能是某个实现还没跟上，而不是你配错了。碰到这种情况，去项目仓库的 issue 列表里搜一下，往往比继续改配置更快。
小结
MCP 连不上不要靠猜，按端点、版本、授权、路由、能力清单、server 本体这六步从外往里剥，绝大多数问题会在前三步落地。2026-07-28 的新规范把”版本”这一步的重要性抬高了不少，官方给了 12 个月的弃用窗口，别把它当成可以拖到最后一天的缓刑。远程部署的人重点看无状态化带来的路由变化，用长时间运行操作的人重点看 Tasks 移出核心之后两端的 extension 是否对齐。所有版本与规范细节，以官方 blog 与规范文档当前版本为准。