凌晨两点，网站手机弹出告警：核心接口错误率飙到17%。排查我爬起来打开电脑，何体第一件事不是网站重启服务，而是排查打开终端敲下 curl -I https://api.example.com/health。返回 502。何体再看负载均衡器日志，网站后端三台机器有两台在反复重启。排查这不是何体网络问题，是网站应用自己崩了。排查网站故障，排查说到底就是何体不断缩小范围，直到锁定那个具体的网站、可复现的排查触发条件。

很多人一上来就查监控大盘。何体大盘有用，但它是滞后的。我更习惯从最外层往里剥。比如先确认 DNS 解析是否正常：dig +short example.com。如果返回的 IP 不对，那后面所有事都白搭。有一次客户说网站打不开，我查 DNS 发现解析到了一个已经下线的旧 IP，原因是他们换了 CDN 但没改域名注册商的 NS 记录。这种问题监控根本看不出来，因为监控探针用的是内网 IP。

DNS 没问题，就看 TCP 层。用 telnet example.com 443 或者 nc -zv example.com 443。连不上，可能是防火墙、安全组、或者服务器本身宕了。连得上但握手慢，那可能是 TLS 证书问题。我见过一个案例：证书链不完整，浏览器能打开，但某些安卓 WebView 直接白屏。用 openssl s_client -connect example.com:443 -showcerts 一看，中间证书没下发。这种问题在桌面 Chrome 上被缓存掩盖了，只有新设备才暴露。

到了 HTTP 层，才是重头戏。状态码 502 和 504 是两码事。502 是网关收到无效响应，通常是后端进程挂了或者端口没监听。504 是网关等后端超时，后端可能还在跑但卡死了。我排查时习惯同时看 Nginx 的 error log 和 upstream 的响应时间。有一次 504 频繁出现，查了半天发现是某个 SQL 查询没走索引，在数据量涨到 200 万行后从 50ms 变成 8 秒。数据库慢查询日志里清清楚楚。

前端问题容易被忽略。用户说“网站挂了”，可能只是某个 JS 文件 404 导致白屏。打开浏览器控制台，看 Network 面板里哪个请求红了。有一次线上页面样式全乱，查到最后是 CDN 回源时把 .css 文件的 MIME 类型返回成了 text/plain，浏览器拒绝解析。这种问题后端日志完全正常，只有从用户视角才能发现。

排查工具不在多，在顺手。curl、dig、tcpdump、strace 这四个我用的最多。strace 尤其适合查进程卡死——strace -p PID -T -tt 看它卡在哪个系统调用上。有次一个 PHP 进程 CPU 100%，strace 显示它在无限循环 read() 一个空文件描述符。原因是代码里 while(!feof($fp)) 但 $fp 打开失败返回了 false，feof(false) 永远为假。

最后说个反直觉的：别急着改配置。我见过运维一遇到 502 就 nginx -s reload，结果把正在处理的请求全断了，错误率反而飙升。先 ps aux | grep 进程名 看进程状态，netstat -tlnp 看端口监听，dmesg | tail 看内核有没有 OOM kill。信息收集够了再动手。网站排查的本质是证据链，不是直觉。你看到的每一个现象，都要能对应到一个具体的日志行、一个系统调用、或者一个网络包。否则就是瞎猜。