LMN516 / 运维事件记录
LMN516 公网访问异常故障记录
发生日期：2026 年 11 月 9 日（北京时间） 事件状态：公网已恢复，触发原因待查
故障记录
11 月 9 日上午，LMN516 主站出现长时间加载、无法正常打开的现象。最初从浏览器观察，既可能是 Next.js 进程异常，也可能是公网网络中断。现场没有立即重新部署。首先使用生产状态接口分别检查本地应用、本地路由和公网入口，以免在没有定位故障点的情况下重启仍然正常的服务。
当时的主要访问路径是：浏览器通过 HTTPS 连接 VPS 上的 Nginx，Nginx 将请求交给 VPS 本机的 127.0.0.1:13203；这个端口由一条 SSH 反向隧道映射到 Mac mini 的 127.0.0.1:3200，随后由本地路由转发至 3101 上的 Next.js 应用。网站代码运行在 Mac mini，VPS 负责对外入口，两者之间的长期 SSH 连接是用户访问网站的关键一环。
第一轮检查给出了清楚的边界：Mac mini 的 3101 与 3200 端口的部署接口均为 HTTP 200，而 lmn516.com 与 admin.lmn516.com 对应的公网部署接口都发生 TimeoutError。本地服务能响应、两处公网入口同时超时，说明不能把“网站打不开”简单等同于“应用已崩溃”；需要优先检查公网入口到本地路由之间的转发环节。此时的生产提交为 f3265996047793e1b80906aee098dd12962af8c5，部署 ID 为 dep_20261109013057_f326599。
随后通过 SSH 进入 Mac mini，检查了磁盘、launchd 服务及 SSH 进程。磁盘命令报告根卷约有 22 GiB 可用；本地首页仍返回 HTTP 200。launchctl 列表中，com.lmn516.public-origin-direct-tunnel 对应 PID 12030，历史退出状态字段为 255，同时 ps 仍能看到该 SSH 进程。进程实际使用 -R 127.0.0.1:13203:127.0.0.1:3200 建立反向端口转发，并绑定 en1 接口。
这里必须区分证据和推断：SSH 的 255 提示该服务曾出现 SSH 层错误，但进程在观察时确实存在，因此不能直接断言它当时已经退出。进程存在也不能证明业务转发有效，因为 SSH 保活只代表 SSH 通道层面的响应，并不等于从公网到 Next.js 的一次完整 HTTP 请求成功。故障时间与近期部署时间相近，但缺乏证据证明部署引发了这次异常。
技术故障记录 · 续 / 02
故障处理与恢复结果
现场采用了最小恢复操作：不重新构建 Next.js，不改动 Git main，不切换生产版本，也不重启 Mac mini，而是单独要求 launchd 终止并重启对公网使用的 SSH 隧道服务。操作命令如下：
launchctl kickstart -k \
gui/$(id -u)/com.lmn516.public-origin-direct-tunnel
命令执行后，launchctl 列表显示新 PID 为 24597，退出状态字段为 0。紧接着，从 Mac mini 发起对 https://lmn516.com/api/meta/deployment 的请求，得到“公网 HTTP 200”。随后使用 LMN516 生产状态检查再次验收：本地 3101、本地 3200、主站公网接口及管理站公网接口全部返回 HTTP 200，并且四处报告了同一个 Git SHA 和部署 ID。
因此，能够确认的是：重建指定 SSH 隧道之后，先前超时的公网部署接口恢复了访问，生产版本并未变化。这是一次网络转发链路层面的恢复操作，而不是代码修复或重新部署。由于没有取得故障时 VPS 上 13203 端口的实际转发测试、Nginx upstream 日志和 SSH 详细错误日志，尚不能证明最初是连接断开、半开会话、端口监听异常，还是网络接口或 VPS 侧的短时故障。恢复结果支持“隧道或其相关转发路径异常”的定位，但具体触发原因仍须保留为待查。
后续处理意见
后续不宜把“发现网站打不开就重启隧道”作为永久方案。应在现有生产系统内增加一条短而完整的健康检查链路，分别检测 Mac mini 的 3200、VPS 上经隧道暴露的 13203，以及公网 HTTPS 部署接口。只有本地服务正常而 VPS 转发异常、且连续多次检测失败时，才考虑自动重建隧道；如果 VPS 端口正常但公网失败，应优先检查 Nginx、TLS 与外部网络，不应盲目重启 SSH。
建议将健康检查间隔设置为约一分钟，并以连续三次失败作为初始报警或处置阈值；这只是待验证的建议值，部署时需要结合正常网络波动调整。恢复逻辑必须设置冷却时间和单实例锁，避免并发守护程序反复重启同一连接。每次自动动作应记录检查时间、失败端点、HTTP 状态或超时类型、隧道 PID、动作原因及恢复后的端到端结果。对于重复恢复无效的情形，应停止循环操作并发出告警。
还需要补足事故取证。下次同类问题发生时，在重启之前先保存 VPS 本地 127.0.0.1:13203 的请求结果、SSH 客户端与服务端日志、Nginx 错误日志，以及 Mac mini 网络接口 en1 的状态。原始日志能够解释故障为什么发生，而重启后的一次 HTTP 200 只能解释问题如何得到缓解。建议同时监测真实首页的加载结果，因为部署接口返回 200 不能完全证明首页静态资源和页面交互均正常。
本次事故的闭环标准应分开记录：公网链路恢复已验证；浏览器完整页面体验尚未单独验收；SSH 异常的触发原因没有最终证据；自动检测与自愈机制也尚未实施。下一次再发生相同现象时，优先按“本地应用—隧道转发—VPS 代理—公网访问”的顺序逐层核对，确认故障边界后只处理对应组件。这样的流程比一遇到访问超时就部署新版本更安全，也更便于积累可复用的运行经验。
记录依据：本次终端输出、两次生产状态检查及重启后的 HTTP 验收。
结论边界：恢复动作已验证有效；深层触发原因尚未证实。