早上八点多，收到一条消息。
“你们平台打不开了。”后面跟了一张截图——浏览器白底黑字，502。
那一刻的第一反应，说实话，是“完了”。车间在跑车，调度在看位置，服务器要是真躺了，这不是道歉能解决的事。
但我上机看了一眼，先看到的是这么几个数字：进程还在，启动时间是前一天下午，一秒都没重启过。
接口在本机直接请求，200，耗时 1.17 毫秒。
平台没挂。它一直站着，只是有个入口，被人指到了别的地方。
先说说 502 到底在说什么
很多人以为 502 是“服务端崩了”的意思。不准确。
502 的原话是“网关从上游收到了无效响应”——说白了，是前面那个“前台”（负责接客、转发请求的那一层），转头去叫“后台”干活，结果后台那扇门后面是空的。
所以 502 只说明一件事：这条转发链断了。 断在哪一头，得查。
而这次的断点，是一条四月份的旧配置。
那是一套早就下线的服务，程序删了、目录空了、连开机自启都没了，但它在服务器上留了一段配置，内容是“80 端口的默认流量，都转给我”，转向一个 8000 端口。而那个端口上，早就没有任何东西在听。
四月的配置，一天一天，把每一个敲裸地址的访问，送进一扇不存在的门。
更值得说的是：为什么只有一部分人打不开
这是这次最反直觉的一点。
同一台服务器上，走域名的访问一直好好的，一个都没受影响；只有直接敲那串 IP 地址的人，看到的是 502。
因为那一层“前台”是按来客报的名字（Host）分流的。报得出域名的，走正门；报不出、只报了个 IP 的，落到那段兜底配置里——也就是四月的那个门口。
所以那天真实的场面是：已经在用的客户毫无察觉，反倒是我们自己随手敲 IP 做检查时，撞见了 502。
“你们平台挂了”和“平台挂了”，很多时候不是同一件事。
我早上判断错了一半
这里得说个不好听的部分。
那天早上八点，我在公网上测了一轮，看到的现象是：静态页面能打开（200），接口打不开（502）。
我当时的结论是——“后端死了”。
错了。 平台活得好好的。
错在哪儿？我默认了“所有请求都走同一个门”。可实际是：那个 200，可能只是前台自己在本地翻到了一个文件给你；那个 502，可能来自另一个门口。两件事根本不是一条链上的，我却把它们当成了一条链的两头。
这个错值得记住，因为它太容易犯：只看公网状态码，等于只看别人家门口的灯亮不亮，就断定屋里有没有人。
真要判断，得分开看三件事——
第一，这个请求命中的是哪个门？（配置里按名字分流的那一段，谁在兜底）
第二，这个门往里转，转给谁？（转到的是哪个端口）
第三，那个端口上，到底有没有人在听？
三件事凑齐，五秒钟就能定案。少一件，就会像我早上那样，把“没人应门”说成“家里没人”。
顺带一个刺眼的对照：日志里那个不存在的端口，每天都在报错——故障前四天，分别记了 652、604、306、819 次连接失败。而真正在干活的那个端口，同期连接失败记录是 零。
也就是说，这件事在日志里喊了四天，只是没人去读。
我们后来补了什么
复盘如果只停在“下次注意”，那等于没复盘。所以补了四样东西，都不复杂：
一、四个入口一起测。 以前只看首页，或者只看域名。现在裸 IP、域名、静态页、接口，四条一起探，任一异常就报警。这次的教训很直接：只看首页会漏，只看域名更会漏。
二、把“转发目标还活着吗”变成一条断言。 遍历所有转发规则，逐个核对那个端口有没有在监听。这条如果早写四天，这次故障在发生前就会被发现——因为那个端口，早在四天前就已经没人听了。
三、配置卫生。 服务删了，配置要跟着删。这条听起来像常识，但恰恰是最容易漏的：程序没了会报错，配置留着不会报错，它只是安静地等着哪天劫持一个入口。所以现在服务器上出现非标准后缀的备份配置，会直接告警。
四、备份到底能不能用，真的打开看一次。 这条是后来做“体检”时补的——不是看备份文件在不在、多大，而是把它解压出来，做一次完整性校验，再逐表和线上对数。结论是能恢复，差异也在可解释的范围内（两份快照隔了两个小时）。备份“存在”和备份“能用”，中间隔着一次真的打开。
带走一句话
如果你也在用一套车队管理平台，某天听到“打不开了”，先别急着让人重启。
问三个问题就够了：是所有人都打不开，还是只有某些入口打不开？是页面打不开，还是只有数据不回来？后台进程最后一次启动，是什么时候？
答得清楚，说明这套系统是分层的、可归因的；答不清，那才真该紧张——因为下一次，你可能连“坏在哪一层”都不知道。
我们做这一行越久越觉得，能分清“哪一层坏了”，比“永远不出事”更接近可靠。永远不出事是运气，分得清是能力。而运气，是不能写进 SLA 的。
这里是琪致，下篇见。
本文同步收录在琪致官网「808 手记」
全文与往期：qizhi808.com/notes/
