十次 MCP 连接失败里有九次并不玄乎。它们要么是拼写错误、要么是端口、要么是进程根本没起来。这三样我都撞过，而且通常就是按这个顺序。下面这份清单是我当初希望有人直接塞给我的，从"先查无聊的那个"排到"好，现在开始有点意思了"。
1. 先从配置查起
大多数故障都追溯到配置块。打开你的 mcpServers 段，检查三个词：command、args、env。命令跟包期望的拼得一模一样吗？必要的参数都在吗？服务器需要的每个环境变量都定义了吗？往往一个缺失的 env 值，就会表现为一个令人困惑的握手失败。如果你不确定这块该长什么样，这篇 配置 JSON 指南 讲明白了每个键。
2. 它到底起来没有
接着，确认服务器进程真的在跑。如果你在终端里手动启动的它，除非那个终端一直开着，否则 App 连不上。如果你用的是进程管理器，确认进程是 up 的。一个非常常见的坑：你重启了 App 却没重启服务器，或者反过来。配置改动之后，客户端和服务器两边都得重新启动。
3. 查端口和主机
对本地服务器来说，"connection refused"（连接被拒）几乎总意味着端口或主机不匹配。服务器听在一个端口，配置指向另一个；或者一个在听 127.0.0.1，另一个却期待不同的主机。确认服务器公布的确切 URL 跟你配置里的 url 一致。对远程服务器，防火墙或被封锁的区域也会导致同样的被拒——有时换个网络测一下，立刻就知道答案。
4. 读握手错误
如果服务器起来了也能访问，但连接还是失败，去看协议错误。在 JSON-RPC 里，失败是以带 code 和 message 的结构化 error 对象返回的，而不只是一个 HTTP 状态码。那条 message 往往直接说出哪里不对，比如不支持的协议版本。想流畅地读懂这些错误，这篇 MCP 和 JSON-RPC 讲解 展示了一个健康的握手长什么样，这样你就一眼能看出失败的那个。
5. 直接测端点
把 AI App 从等式中拿掉。直接用 curl 指向服务器，看看能不能得到一条合理的 JSON-RPC 响应。如果 curl 失败，那是服务器的问题。如果 curl 成功但你 App 不行，那是 App 或它的配置问题。这一个测试，瞬间就把系统劈成两半对照。想要对着真实服务器跑 curl 的例子，连接指南 里有一个。
6. 静默配置陷阱
有时一点错误都没有——服务器就是没出现。十次有九次，是配置文件存错了位置或存成了错误格式（一个多余的逗号就会悄悄让 JSON 解析失败）。用复制粘贴的方式重新存一次文件，在去研究任何聪明的东西之前，先确认它是合法 JSON。
7. 实在没办法时
如果配置、进程、端口、握手都验证过了，服务器还是连不上，那就检查一下你的客户端版本是否支持服务器说的那个协议版本。版本不匹配是最后一个常见元凶，通常升级之一就能解决。如果还卡着，先搞懂 MCP 服务器本身是什么，往往能帮你换个角度看整件事——我们的 什么是 MCP 服务器指南 讲了地基。
收个尾
MCP 连接失败很少是什么深奥的谜题。先配置，再进程，再端口，再握手。用 curl 把服务器隔离出来，保持静默时就重新核验配置。顺着这个顺序，绝大多数"MCP 不工作"的报告几分钟内就消失了。