「是否在线」不是一个是非题
有些 MCP 服务器同时既在线又不在线。我们发现一台会丢弃三分之一连接的服务器——而它在浏览器里看起来完全正常。
有读者问我们，为什么一台在他浏览器里正常打开的服务器会被标记为无法访问。他没错，我们也没错。这台服务器大部分时候会响应——其余时候直接断开连接。
一台服务器，两个真相
我们发了二十五次请求，大约三分之一是这样回来的：
curl: (56) Recv failure: Connection reset by peer不是超时，也不是 TLS 问题。连接建立了，请求发出去了，然后服务器在应答中途挂断。把请求间隔拉开到三秒也没有任何变化，所以也不是限流。我们自己的测量结果一致：对该主机的探测有 31% 失败。
为什么单次检查会骗你
如果一台服务器每三次请求失败一次，那么只检查一次几乎什么也说明不了。你有三分之二的概率说它「健康」，三分之一的概率说它「故障」——而两个答案同样错误，因为真相是一个百分比，不是一个状态。
告警的情况更糟。连续两次失败看起来像一次故障。在 31% 的失败率下，连续两次大约有 9% 的概率发生——如果每两小时检查一次，差不多每天一次。那不是故障，那是算术。
这种情况有多普遍？
我们扫描了目录，寻找既不稳定在线、也不稳定离线的服务器。大约有 180 台处在不稳定的中间地带，失败率介于 10% 到 90% 之间。它们在生态中占比很小——在困惑中占比很大。
该怎么处理
- 如果你在挑选服务器：看百分比，不要看徽章。70% 的服务器会在生产中静默失败，每三次调用就有一次。
- 如果你在运营服务器：间歇性的连接重置通常指向应用前面的代理或负载均衡，而不是应用本身。应用日志会显得干干净净。
- 如果你在做监控：绝不要根据单次采样下结论。要求连续失败，并且明确说出失败率。