092026 年 11 月
公网访问异常：SSH 隧道与转发链路恢复
Mac mini 上的 Next.js 与本地路由均返回 HTTP 200，但主站和后台的公网部署接口持续超时。现场没有重新构建或部署，而是重启指定反向 SSH 隧道后恢复访问。
- 处置
- 单独重建公网反向隧道；生产代码版本未变化。
- 验收
- 本地 3101、3200，以及主站和后台公网部署接口均返回 HTTP 200，提交与部署 ID 一致。
- 边界
- 隧道相关链路恢复已验证；最初触发原因和完整浏览器体验仍待查证。
LMN516 / 专题档案2026 年 11 月 · 第一辑
技术故障与
恢复档案
把真实故障留下来，不只是记录“最后修好了”，还要说明问题在哪里、为什么选择这一步恢复，以及哪些结论至今没有证据。这里集中整理 LMN516 的运行事故、关键链路和可复用的排查经验。
报告目录
102026 年 11 月
微信 MCP 调用异常：独立运行时路由恢复
ChatGPT 调用 wechat_takeover_status 反复出现内部错误，但 M4 控制器的本地状态命令正常。排查发现过期的隧道目标与关闭的 MCP 路由切换开关，修复后真实工具状态读取恢复。
- 处置
- 将隧道目标改为已验证的 Tailscale 别名，再开启独立 MCP 路由。
- 验收
wechat_takeover_status返回ok: true；记录中的一次调用耗时 124 ms。- 边界
- 状态查询已恢复；微信真实发送、监听及完整入口路由仍需单独验收。
两次事故放在一起看
两篇报告涉及不同的业务，却都暴露了分层系统中常见的误判：服务进程存在、端口返回状态码，并不能证明请求经过了正确的路径，也不能替代真实业务验收。
11 月 9 日：浏览器 → VPS / Nginx → SSH 反向隧道 → Mac mini 路由 → Next.js
11 月 10 日：ChatGPT → /api/mcp 入口 → 独立 MCP 运行时 → M4 微信控制器（切换完成后的目标链路）
| 排查层次 | 11 月 9 日：公网 | 11 月 10 日：MCP |
|---|---|---|
| 局部检查 | 3101、3200 的部署接口正常 | M4 状态命令、远程执行退出码正常 |
| 关键异常 | 公网入口超时，本地服务健康 | 端口返回 401，但实际路由仍指向主站 |
| 局部恢复 | 重建公网 SSH 隧道 | 修复 SSH 目标，开启 MCP 路由 |
| 验收证据 | 四个部署接口一致返回 HTTP 200 | ChatGPT 真实 MCP 工具状态查询成功 |
比较仅整理两篇报告中已经记录的证据；不能据此认定两次事故具有同一个根因。
尚未闭环的事项
公网访问事故
需要补充 VPS 转发端口、SSH 错误日志和 Nginx upstream 日志的故障时取证；还应独立核实首页资源加载，并评估具备冷却与限流的健康检测、自愈策略。
MCP 与微信事故
状态接口恢复不等于微信消息可发送。真实发送和监听仍须验证；历史 wechat-window-not-found 错误、切换后的完整路由证据也不能略过。