服务器异常请稍后：先分清是网络还是负载

页面上跳出「服务器异常请稍后」这行字，第一反应多半是机器挂了，接着就是重启、翻配置、找客服。可这句提示本身什么也没说清，它的真实含义只是这次请求没走通。没走通的原因可能在你家宽带的出口，可能在中间那道 CDN 的回源，也可能在源站那边一堆请求堵着门排队。三种情况处理方式完全两样，所以第一步不是修，是分。分错方向，折腾一整晚也未必有结果。

先分清是压根没连上，还是连上了没回来

这两种在浏览器里长得不一样。连 TCP 都没握上手的时候，浏览器给的通常是无法访问此网站、连接已重置这类话；而要是拿到了 HTTP 状态码、内容却是 5xx，那说明链路是通的，毛病在服务端。5xx 里 502 和 504 也不是一回事：502 是上游给了个无效响应，504 是等上游等到超时。别小看这个区分，它直接把排查范围砍掉一半。至于页面自己弹的那句提示，往往是后端程序把异常吞掉之后统一吐出来的一句话，或者前面那道网关替你兜的底，具体是谁吐的，看响应头里的 Server 和 X-Cache 大致能猜出来。

服务器异常请稍后，先把链路拆成三段

本地一段、中间一段、源站一段。本地这段最好排除，换个手机热点、换台不同网络的机器试一下，一分钟的事，能省掉后面九成的怀疑。中间这段包含 DNS 解析、CDN 回源、运营商互联，每一环都可能出问题。ping 看的是丢包和延迟，mtr（Windows 上一般用 tracert 或 winmtr）看的是从哪一跳开始变差；不过要记住 ping 通不等于服务通，很多机器 ICMP 是关着的，反过来也一样，ping 不通不代表端口不通。想知道 HTTP 这一层通不通，用 curl 更直接：curl -o /dev/null -s -w ‘%{http_code} %{time_total}\n’ https://你的域名/ ，状态码和耗时一目了然。

负载这头，看的是排队长度不是 CPU 百分比

监控面板上 CPU 才跑百分之三十几，很多人的结论就是机器闲得很，肯定不是负载问题，这个判断经常错。负载高不高，看的是 load average 和运行队列长度，不是 CPU 占用率。CPU 不高但大量线程卡在等磁盘 IO、等数据库锁、等外部接口返回，照样能把请求拖到超时。常用的是 uptime 里那三个数字（1 分钟、5 分钟、15 分钟的平均负载），拿它跟核数比；iostat -x 1 里看 %util 和 await；ss -s 看连接状态里有多少在 TIME_WAIT、多少在 ESTABLISHED。还得分得清是持续高还是尖峰，尖峰往往跟定时任务、备份、爬虫一起出现，找准时间点比盯着平均值有用。

慢和挂，处理思路完全是两回事

有些情况页面是能打开的，只是慢到超时，用户看到的那句异常是等不及了。这时候别研究为什么挂，研究时间花在哪。curl -w 后面跟一串变量就能拆：time_namelookup 是 DNS，time_connect 是 TCP 握手，time_appconnect 是 TLS，time_starttransfer 是首字节时间。首字节大，问题在源站或后端应用；connect 大，多半是网络或防火墙策略；namelookup 大，回去查 DNS。拆开之后方向就明确了，比在那儿猜强得多。

日志里最先露馅的常常是时间戳

nginx 的 access log 里加上 $request_time 和 $upstream_response_time 之后，很多事情一看就明白。upstream 时间远小于 request 时间，说明慢在客户端或者链路上；反过来 upstream 占大头，那就是后端应用自己慢。还有几个状态码值得留意：499 是客户端先断开，往往意味着用户等不及关了页面；500 出现得很有规律的话，翻应用日志里的堆栈通常能对上。日志的价值在于它带时间，把异常发生的时刻和负载曲线、发布记录、定时任务时间一对比，答案经常自己就浮出来了。

还有几个土办法，成本低但管用

找几个不同地方的人帮忙打开页面，看是不是只有某个区域反馈，这一步能很快把全局问题和局部问题分开。用在线拨测工具从多个节点跑一遍，比你一个人在那儿反复刷新强。再就是看是不是刚发过版、刚改过配置、刚换过证书，很多突然异常都是变更引起的，回滚一下就能验证。最后别忘了 DNS 和 CDN 这两层，解析生效有延迟，CDN 节点也有缓存没刷干净的时候，这类问题往往自己会好，但会让人白折腾半天。

平时留一份能对比的底稿

正常的时候记几个数：ping 的延迟和丢包、TTFB、load average、连接数。不用多精确，有个大概的基线就够了。等真出事的那一刻，你手里有以前是多少，判断起来快得多；没有基线，只能凭感觉说好像变慢了。这件事成本很低，关键时候很值。

顺序大概是这样：先确认是连不上还是没回来，再把链路拆成本地、中间、源站三段各查一遍，然后看负载和排队情况，最后翻日志时间戳对时间线。一上来就重装系统、换机器、加配置，看着挺果断，实际上是把问题往后推。真拿不准的时候，把现象、时间点、影响范围记清楚再去找服务商，也比一句服务器异常过去问要有效得多。具体排查项以服务商或官方页面说明为准。