晚上十一点，网络手机弹出一条告警：某台线上服务器的中出接口成功率从99.9%掉到了72%。我打开电脑，现问先ping了一下网关，题何延迟正常。进行再curl一下接口，排错超时。网络这时候千万别急着重启服务——重启能解决80%的中出问题，但也会让剩下20%的现问问题永远找不到原因。

排错的题何第一步不是动手，是进行确认“谁在报错”。是排错用户端？还是服务端？还是中间某个环节？有次同事说“网站打不开了”，我让他截个图，网络结果浏览器地址栏里写的中出是内网IP，他连的现问是公司WiFi，当然打不开。这种问题查半天代码，最后发现是网络环境不对，特别常见。

确认范围之后，用分层法往下切。网络排错有个好处：OSI七层模型虽然老，但真的好用。物理层——网线插没插、网卡灯亮不亮；网络层——ping通不通、路由对不对；传输层——端口开没开、防火墙拦没拦；应用层——服务进程在不在、日志报什么错。一层层往下，别跳。

我习惯从应用层往回查。先看服务日志，如果日志里连请求都没收到，那问题大概率在传输层或网络层。这时候telnet一下端口，不通的话，再查防火墙规则、安全组、iptables。有次折腾了半小时，发现是云厂商的安全组没放行新加的端口，代码一点问题没有。

如果日志里有请求但报错，那就是服务内部的问题。看错误类型：超时？连接池满了？数据库慢查询？内存溢出？每种对应不同的排查方向。超时就查下游依赖，连接池就调大参数或者找泄漏点，慢查询就explain。别一上来就翻代码，先看现象指向哪里。

DNS问题特别隐蔽。有次服务偶尔超时，重启就好，过一阵又犯。最后发现是DNS解析偶尔失败，容器里的resolv.conf指向了一个不稳定的DNS服务器。这种问题日志里看不出来，因为请求根本没发出去。后来加了个本地DNS缓存，再没犯过。

抓包是终极手段。tcpdump或者wireshark，看三次握手有没有完成、有没有RST、有没有重传。有次用户说上传文件总失败，抓包发现TCP窗口一直缩到零，是中间某个网络设备做了限速。这种问题看日志永远看不出来。

排错最怕的是“我以为”。我以为防火墙关了，其实没关；我以为服务监听的是0.0.0.0，其实只监听了127.0.0.1；我以为DNS没问题，其实解析到了旧IP。每个“我以为”都要用命令验证一遍，别靠记忆。

还有一点：改配置之前先备份，改完记下来改了什么。有次我调了个内核参数，问题没解决，后来忘了改回去，第二天另一个服务挂了。排错过程本身也会引入新问题，这很常见。

最后说个反直觉的：有时候最快的排错方法是“重启试试”。但重启之前，尽量把现场留下来——日志、堆栈、连接状态。重启能恢复服务，但如果不找到根因，下次还会再来。我一般会先留一份现场，再重启，然后慢慢分析。

排错不是玄学，是逻辑加经验。逻辑让你不跳步，经验让你知道先看哪里。两者都有了，大部分问题都能在十分钟内定位。剩下的，就是耐心。