把 MCP 采集放进云上独立网络之后，结论为什么变了
同一套采集脚本，在办公网笔记本上跑和在一台云上独立网络的机器上跑，出来的格子会不一样。不是脚本变了，是「哪些格能拿到结论」变了——网络边界决定了你能观察到什么，观察不到的那部分会以别的形式落进表里。
这份 2026-10-29 的快照里有 51 格 na，全部落在协议实测那一档。na 不是「不支持」，是「没拿到结论」。在云上做这类采集，把 na 压到最低比把 pass 拉高更重要，因为 na 会把一个未知项伪装成一个统计项。
数据里跟网络直接相关的三个字段
161 个 server 的传输形态是 147 个 stdio、14 个 http。这个比例决定了网络策略的重心：
| 字段 | 分布 | 对采集网络的含义 |
|---|---|---|
| transport | stdio 147、http 14 | 绝大多数是本地子进程，只有 14 个真的走公网端点 |
| startupMs | 34 个超过 5 秒 | 超时阈值必须比它宽，否则会把慢启动记成失败 |
| na | 51 格 | 全部在协议实测档，是「未取得结论」而非「不可用」 |
stdio 型的采集看起来不碰网络，实际上首次拉包仍要出网——npx、pip、uvx 这类启动方式会在会话开始时去公网取依赖。第一次跑通了，第二次因为缓存才快。如果你的出网策略在第一次就拦掉，后面所有格都会往失败方向倒。
为什么要把采集机放进独立网络
三个理由，按重要性排：
可复现。 采集结果要能被人按同一份环境重跑。办公网有代理、有 DNS 劫持、有同事在改 hosts，任何一条都会让结论不可复现。独立 VPC 里只跑这一件事，网络形态是固定的。
可回滚。 161 个 server 里有相当一部分会往磁盘写东西，配置、缓存、临时凭据。一台可以被快照回滚的机器，比一台「清理干净再跑」的机器可靠得多。
不污染。 采集会拉起大量子进程，其中 34 个启动要 5 秒以上。放在业务机器上，最直接的后果是业务抖动，而不是采集变慢。
具体到落地，就是一台独立 ECS、一个独立 VPC、一条独立的 NAT 出口。不要和业务共用 NAT——共用之后，出网侧的限流、QPS 配额、异常流量处置都会互相影响，出问题时你分不清是谁的。
出网白名单按「必需」建，不按「方便」建
全通最省事，但全通之后你就失去了对 na 的解释力：任何一格拿不到结论，你都说不清是目标挂了还是你的网络抖了。
按采集对象建白名单，粒度到域名加端口：
- 14 个 http 型 server 的目标端点，逐个加，端口固定 443。
- 包管理与运行时源：
npx、pip、uvx对应的仓库域名。 - 其余默认拒绝，拒绝日志单独留一份。
拒绝日志的价值在于它把 na 变成了可归因的：某格 na，去日志里搜目标域名，命中就是网络侧拦的，没命中才是目标侧的问题。这一步不做，51 格 na 会一直是笔糊涂账。
有一点容易忽略：出网策略变更会导致采集结果整体漂移。今天放开一个域名，明天那一片格子就从 na 变成 pass 或 fail，历史对比就断了。所以策略变更要跟快照时间一起记，采集结果才有纵向可比性。
常驻与超时：两个最容易把结论做坏的参数
超时阈值。 34 个 server 启动超过 5 秒，其中一部分接近宿主侧的超时上限。采集侧的等待时间如果按默认值设，会把「慢」记成「不通」。判断方法很直接：同一格跑两次，一次 fail 一次 pass，基本就是超时踩线，不是兼容性问题。
子进程回收。 stdio 型是起子进程走管道，会话结束没杀干净就会留一堆孤儿进程。跑到几百格之后，机器上的进程数会干扰后续采样，表现是后面的格越来越慢。按进程组杀，不要只杀父进程。
常驻形态。 采集任务本身适合一次性容器或一次性实例，不适合常驻服务。常驻带来的问题是状态累积：缓存、临时目录、残留凭据。真需要常驻，至少保证每轮开始前重置工作目录。
三个验收点
验收点一：na 归零或可解释。 采集完成后，na 的每一格都要能对上一条拒绝日志或一条目标侧错误。对不上的 na 等于没采。
验收点二：同一格跑两次结论一致。 抽 20 格重跑，pass 与 fail 不应翻转。翻转说明超时或网络抖动在干扰，先修环境再看数据。
验收点三：缓存命中前后分别采一次。 首次全部走公网拉包，第二次走本地缓存。两次结果如果差很多，说明你的通过率里混进了网络因素，报告里必须写明是哪一次。
口径必须跟数字一起走
云上部署只解决了「怎么采到」，不解决「采到的是什么」。这三句话在任何引用场合都不能省：
文档格的 pass 是按目标宿主的配置格式与已知能力推出来的，不是跑出来的；协议实测这一档在当前快照里 555 格、pass 0，是按协议规范判定不可用，不能读成实测失败；17 个宿主里 12 个没有真机格，它们的绿整体属于推断。另外 71 格 limited 是「能用但受限」，不能并入 pass 一起数。
三档的证据不同，通过率也不同：文档格 1,392 格、pass 1,264、占 90.8%，是按宿主规则推的；真机格 790 格、pass 319、占 40.4%，是跑出来的。网络隔离能提高的是 na 的比例，改变不了这几条。
总结
把采集机放进独立网络，换来的不是更高的通过率，而是更少的未知项——白名单让 na 可归因，独立的 NAT 让结果可复现，超时与进程回收让重复采集稳定；这套环境的落地清单可以对着 MCP 兼容矩阵 的宿主维度一起看，站点总览在 DeepSeek Harness Hub。
适合与不适合
适合：要在云上跑批量探活或兼容性采集的人；正在把本地脚本搬进 VPC、被出网策略卡住的人；需要让采集结果可复现、可回滚的人；维护内部兼容性看板、必须解释每一个 na 的人。
不适合：只有十几个 server 要测、本地跑一次就够的人，独立 VPC 的成本不划算；不愿意维护白名单、准备开全通的人，na 会一直无法归因；把通过率当成质量指标往上汇报的人，这套方法只会让数字变得不那么好看。
标签：MCP、DeepSeek Harness、云上部署、网络策略
本文由 DeepSeek Harness Hub 自动整理，数据来源于 MCP 兼容采集快照。
