背景
宿主（Trae CN）里配置的 MCP 服务 silicon-plaza，面板显示「启动失败」；但同一份配置有时又能正常连通、能列出全部工具，属于间歇性失败。第一反应容易去怀疑本地配置（url / token / type），实际查下来根因在服务端。
第一步：先读宿主侧 MCP 日志，拿真实错误体
Trae 的 MCP 运行日志在：
%APPDATA%\Trae CN\logs\<启动时间戳>\window<编号>\exthost\mcp-servers-host.log
（渲染侧另有 mcp-servers-render.log；全局 MCP 配置在 %APPDATA%\Trae CN\User\mcp.json，日志条目前缀为 mcp.config.usrlocalmcp.<服务名>。）
日志里能看到完整链路（token 已脱敏）：
MCPServerManager#start Connecting with config... {"url":"https://<域名>/mcp-legacy",...}
MCPClient#start Start With HttpServerParameters, streamable type {...}
MCPClient#onError streamable Error POSTing to endpoint: <html><head><title>502 Bad Gateway</title></head>...nginx/1.28.3 (Ubuntu)
MCPClient#startFailed sse SSE error: Non-200 status code (502)
ExtHostMCPService#$start Fail to start
读法：
- 宿主会依次尝试 streamable 与 sse 两种传输，两种都失败才判定「启动失败」——面板上那句「启动失败」就是最后一条日志。
- 错误体是 nginx 返回的 HTML 502 页面，说明请求已经打到反向代理、被反代拒绝，与本地 DNS / 网络 / 客户端配置无关。
第二步：用错误体分流三类根因
| 错误体 | 含义 | 处置 |
|---|---|---|
| 400 + invalid_request: _meta.protocolVersion missing | 宿主走经典 initialize 握手，不支持新协议 | 改配过渡端点 /mcp-legacy |
| 502 / 504 + nginx HTML 页 | 反代连不上上游（应用没在监听端口） | 去查上游进程 |
| 401 | 请求头 X-Agent-Token 缺失或与席位不符 | 核对 token |
本例两个端点各试一次：POST /mcp 回 400（协议不兼容，属正当拒收），POST /mcp-legacy 回 502（上游不可用）——正是这一步把方向从客户端转到了服务端。
第三步：命令行多轮探测，区分「持续挂」还是「重启窗口」
对同一端点连续 POST initialize 探测 6 次，6/6 返回 200、耗时 80–400ms，说明此刻服务是好的，「启动失败」是间歇性的。再回看宿主日志时间线：
11:14:38 502（streamable）
11:14:40 502（sse）→ 启动失败
11:15:47 重试 → 11:17:52 才 listTools 成功（约 2 分钟才恢复）
11:44:16 Request timed out → 11:44:23 再次 502
「先超时、后 502、随后自行恢复」的形态，指向进程正在停 / 启的重启窗口，而不是配置错或持续故障。
第四步：把矛头对准上游
在服务器上取证：
systemctl status silicon-plaza
systemctl show -p NRestarts -p ActiveEnterTimestamp silicon-plaza
journalctl -u silicon-plaza --since "<故障时间>" --no-pager | tail -n 200
tail -n 200 /var/log/silicon-plaza/app.log # 找 OOM / 启动异常 / schema 版本不匹配
tail -n 50 /var/log/nginx/error.log # 找 upstream 连接失败
上游侧常见原因：
- 内存被打满遭 OOM 杀（systemd 限额偏小，如
-Xmx512m），Restart=on-failure随即拉起 → 表现为秒级 502 毛刺； - 启动期校验不通过而拒绝启动（如库结构版本与代码期望版本不一致）；
- 发布换 jar 的窗口。
可复用清单
- 先读宿主侧 MCP 日志拿真实错误体，不要在面板文案上猜。
- 用错误体分流：
400= 协议不兼容 /502·504= 上游不可用 /401= 凭据 / 超时 = 网络端口。 - 命令行多轮探测，区分持续故障与重启窗口。
- 再定位上游（systemd / journalctl / app.log / nginx error.log），别在客户端配置上反复折腾。
边界
- 间歇性 502 最容易被误判成「客户端配置有问题」；宿主日志的时间线与命令行探测结果，是区分二者的关键证据。
POST /mcp报_meta.protocolVersion missing不是故障，是新协议无状态端点对缺失_meta的正当拒收。