云上跑 MCP：出网、常驻与权限收敛的三道关
把 MCP 从本机搬到云上，第一反应通常是网络——安全组、NAT、出网带宽。这些确实是前置条件，但真踩过一次就会发现，决定「这一批服务能落地几个」的，是镜像里那个客户端可执行文件的版本号。
本机装坏了立刻重装就行，云上是几十台实例共用一个镜像，一个版本写错，错误的面积会被乘上实例数。所以云上这条线的核心不是「通不通」，是「基线稳不稳」。
先把镜像里的版本号写死
采集机实录的三个真机测宿主，版本是明确的：claude-code 2.1.311、gemini-cli 0.66.0、qoder 1.1.80。这三个版本各自对应 150 格的实测结果，claude-code 102 通过 / 48 失败（68.0%），gemini-cli 34 / 116（22.7%），qoder 33 / 117（22.0%）。
这三个数字是绑在版本上的。同一个 CLI，换一个次版本，工具数量上限、认证流程、远程连接支持都可能变，那 150 格的结果就不再生效。如果镜像里写的是 latest，等于主动放弃复现能力——今天量出来是 68%，下周重建镜像可能变成另一个值，而你不会知道原因。
第一条基线规则很朴素：锁死版本，不用 latest，不用范围符，把版本号写进构建脚本而不是文档里。
版本为空的宿主，整列没有数据
codebuddy 和 opencode 在采集记录里版本号一栏是空的，对应的 153 格全部无数据。这不是「不兼容」，是「没有装」。
这件事在云上会被放大。镜像里没预装某个 CLI，那这个宿主在你整个集群里就是空列；装了但装的是另一版，结果可能落进失败列。两种情况的处置方式完全不同：前者补装，后者降级或改配置。
2,601 个可判定格子里，无数据占 351 格，失败占 856 格。它们经常被合并成一句「不行」，但一个是缺数据，一个是真失败，混在一起做容量规划会得出错误结论。
「没装」与「装了不兼容」必须分成两列
按宿主看差距：cline、codex-cli、continue、roo-code、trae、vscode-copilot、workbuddy 七个并列 103 / 47，68.7%；claude-code 68.0%；windsurf 66.0%；cursor 62.0%；claude-desktop 与 lingma 都是 61.3%；zed 48.7%；再到 gemini-cli 22.7% 与 qoder 22.0%。
一个宿主的可判定格子是 150 格。如果你的镜像统一装 workbuddy 这一档，150 格里约 103 格能落地；换成 qoder 那一档，只剩 33 格。同一台机器、同一份配置、同一个安全组，落地数量差三倍，差别全在客户端实现。
所以在做容量规划时，「多少服务可用」这个数字必须带上宿主名与版本号，否则不具备可比性。报表里只写一个百分比的，基本可以认为没做分层。
出网与安全组，只是背景
远程类服务（http 传输）在这批数据里是 141 通过 / 11 失败 / 13 部分 / 73 无数据，本地进程类（stdio）是 1,198 / 845 / 42 / 278。远程连接占比不高，但一旦要用，出站可达就是硬前提。
这部分按常规做法配即可：实例放通出站，入站只留运维端口，需要固定出口的走 NAT 网关。它是必要条件，不是决定项——通不通决定「能不能试」，版本决定「试了成不成」。
权限收敛：配置里别塞长期凭据
需要授权的服务在这批数据里只覆盖 17 格，且全部无数据。含义很直接：这一类服务没有可用的实测结论。
在云上这意味着两件事。一，不能假设「配好就能用」，授权流程要单独验收，别混在连通性测试里。二，不要在镜像或配置模板里写死长期凭据——镜像会被复制、被归档、被别的团队拉走，写进去的 token 等同于公开。
正确做法是实例启动时通过实例角色或外部密钥服务注入短期凭据，配置里只留引用与占位。这条不是 MCP 专属，但 MCP 的配置形态很容易让人把 key 直接粘进 JSON。
镜像基线该固化哪几项
一、基础运行时版本，与客户端的 peer 依赖对齐，别让装包阶段去解析浮动版本。二、每个 CLI 的确切版本号，并在旁注里记录它对应的实测通过率。三、配置目录与 profile 隔离方式，避免多实例互相覆盖同一份文件。四、凭据注入路径，写清是实例角色还是外部密钥服务。五、一段验收脚本，装完立刻跑一次真实工具调用，而不是等上线才发现。
五项里第二项最容易被跳过，也最容易在扩容那天反噬——你会在一个新批次上看到完全不同的通过率，然后花两天去找一个根本不存在的网络问题。
落地比例的粗算
以 153 个真实 server 为分母：在 15 个可判定宿主上全绿的有 11 个；全程零通过的有 50 个，占 32.7%；工具数为 0 的覆盖 850 格，通过数为 0。也就是说，无论选哪个宿主，「一半左右能用」已经是偏乐观的估计。
逐格记录可以按宿主与服务交叉核对，采集口径说明 里列了分母算法；按类别看的分布见 MCP 服务榜。
总结
云上跑 MCP，出网是最容易配的一关，版本基线才是决定落地数量的那一关；镜像里锁死版本、把「没装」与「不兼容」分开计、凭据走短期注入，这三件事做完再谈扩容。同类对照见 MCP 服务榜。
适合与不适合
适合：要在多台云主机上批量分发 MCP 配置的运维；在做自建镜像基线的人；需要给「能支持多少服务」做容量估算的人；关心配置里凭据怎么管的安全负责人。
不适合：只在一台笔记本上用单一客户端的人；把 MCP 当成纯网络问题、只想调安全组的人；期待这里给出某家云厂商专属最佳实践的人——本篇只谈版本与基线，不涉及具体产品。
标签：MCP、云上部署、版本基线、权限收敛
本文由 DeepSeek Harness Hub 自动整理，数据来源于 MCP 采集快照（2026-11-02）。
