早上开电脑，浏览器一直在转圈。终端里十几条连接全部卡在握手，手机上的几个境外服务也一起超时。
第一反应永远是一样的：机器是不是挂了。毕竟它跑着七八个服务，一周前才刚重启过一次。
五步，把嫌疑从机器上挪开
顺序很重要，先从最便宜、信息量最大的地方开始：
- 进程还在不在
- 端口有没有应答
- 机器自己能不能出网
- 外部节点能不能连上这个端口
- 客户端在那边的日志里有没有出现
前四步全部正常：进程活着，端口有应答，机器自己访问外网 200，从几个不同地区探端口也都是零点几秒连上。
第五步是分水岭。翻那一小时的入站日志，只有零星的扫描器来敲门，我自己那条线的地址一次都没出现。
“连不上”和”没到”是两件事。 前者是服务拒绝了你，后者是路断了。日志里连你的地址都没有，说明数据包根本没走到机器上——这时候再去查服务配置，纯属浪费时间。
换门牌号救不了
第一个念头很自然：加两个备用端口，把入口换个地方。
结果三个端口全部不可用。原因也很简单——不是门牌号的问题，是整条路被掐了。按地址拦的时候，换哪个端口都一样。这个结论我花了一个小时才肯接受，因为改端口只要两分钟，接受”两分钟的活儿解决不了问题”要久一点。
兜底方案最好是提前存在的
后来能恢复，不是因为那一刻想出了办法，而是因为机器上本来就跑着一条反向隧道：本机主动连出去到 CDN，外部再从 CDN 回源进来。把内部服务挂在这条隧道后面，客户端要连的就是 CDN 的地址，而 CDN 不在被封范围内。
顺手把 SSH 也挂了上去。运维通道和业务通道走同一条隧道，好处是只需要盯一个链路状态；坏处也很直白——隧道挂了，两样一起没。
三件事记住了
观测点要两端都有。 只在服务器上看，看不出”包没到”；只在客户端看，分不清是 DNS、路由还是服务。
日志里”没有记录”比”有报错”信息量大。 报错告诉你对方来过，空缺告诉你对方没来——后者往往才是真答案。
兜底不需要复杂，但必须是现成的。 临时设计的方案，在断网那一刻基本写不出来，因为你连查文档的条件都没有。
那天最大的收获不是把连接修好了，是能在半小时内判断出方向。以前这种事能让我焦虑一整天。