网站超时是什么；服务器和线路谁背锅

页面转圈转到浏览器自己放弃，蹦出个 ERR_TIMED_OUT。这时候客户甩过来一句「网站又打不开了」，你回一句「我这边看是好的」，对话基本就僵在那儿了。网站超时是服务器线路谁背锅，这事在电话里吵不出来，得把时间分段摆出来看，谁都不服的时候，数据比嗓门管用。

网站超时是什么，先把它拆成几段

一个网页请求走完，中间至少四段：DNS 把域名翻成 IP，TCP 三次握手（走 HTTPS 还得多一段 TLS），服务器算完把第一个字节吐回来，最后才是整页内容传完。任何一段卡住，浏览器统一报超时。所以超时不是一个病，是一堆病共用一个名字，你拿这个名字去对症状，永远对不上。

浏览器 F12 的 Network 面板其实已经把答卷递到手上了。看 Timing 那一栏，Stalled、Waiting(TTFB)、Content Download 各自占多久，一眼就能分出是排队等、是服务器憋着不出声、还是内容传得慢。麻烦在于很多人一着急就去翻服务器日志，答案明明在浏览器里。

网站超时是服务器线路谁背锅，用 curl 分段计时说话

命令行更干脆。找台能上网的机器，跑一句：

curl -o /dev/null -s -w “dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n” https://你的域名

几个数字互相减一下，各段问题就分出来了。time_namelookup 大，DNS 那头有问题；time_connect 减去 time_namelookup 大，握手慢，多半在链路、防火墙或者目标端口上；time_starttransfer 减去 time_connect 大，是服务器在憋，程序、数据库、后端接口挨个查；time_total 减去 time_starttransfer 大，才是传输慢，页面太重或者出口带宽吃紧。还有一点容易被忽略：从哪台机器跑很关键，你在机房内部跑出来的漂亮成绩，不代表用户那边也漂亮。

同一条命令多跑几次、换两三个不同网络再跑，比只跑一次准得多。偶尔超时和每次超时，是两种完全不同的病。

ping 通不代表线路干净

ping 这东西只能证明 ICMP 能过去，说明不了网页请求的体验。不少机房对 ICMP 优先级压得很低，ping 好看得很，TCP 照样排队。要看丢包落在哪一跳，上 mtr：

mtr -n –report 目标IP

报告里如果从某一跳开始出现稳定丢包、后面几跳也是同样的丢包率，那一段基本可以怀疑；只有单独一跳掉、后面干净，通常只是那台路由懒得搭理探测包，别抓着它不放。晚高峰丢包、白天没事，这种规律性基本指向运营商出口或者跨境链路拥塞，不是你的 CPU 不行。跨境业务尤其明显，出海线路的波动跟本地机房完全是两码事，具体绕路和出口情况以运营商和云服务商的线路说明为准。

服务器这头的锅，通常是这几种

真落到服务器上，常见的就那几个：CPU 被爬虫或者没优化的循环打满；内存不够开始用 swap，一 swap 全站跟着打摆子；磁盘 IO 排队，小配置机器上数据库和日志抢同一块盘最难受；数据库慢查询，一条没走索引的 SQL 能把连接池占死；定时任务扎堆，备份、统计、推送全挤在同一分钟。还有种最阴的——磁盘写满，日志文件悄悄长到把分区撑爆，表现也是超时，你会往网络方向查上半天。

这类问题有个共同特点：有规律。某个时段必卡、某种操作必卡、访问量一上来就卡。以前碰过一个站，白天一切正常，晚上固定某个点开始超时，查了半天线路，最后发现是备份脚本和全量爬虫撞在一起，IO 直接被压住，把时间错开就没事了。

线路这头的锅，往往不在你这台机器上

线路出问题的花样更多。跨网访问，运营商出口拥塞，国际链路波动，CDN 回源超时，源站被 CC 打满带宽。CDN 这块特别容易背错锅：缓存规则把动态页面也缓存了，或者缓存时间设得极短，边缘节点几乎每个请求都回源，源站慢一点，边缘节点等不到就直接给用户报错。各家对这种回源超时的状态码编号不一样，看到 5xx 先去翻服务商的官方文档，别照着网上随手搜的对照表下结论。

还有一种锅在域名解析服务商那边。解析服务本身响应慢，或者线路调度把你指到了一个又远又堵的节点，用户那头就是转圈。DNS 那一段迟迟不返回，curl 的 time_namelookup 会很诚实地告诉你。

几个特别容易误判的场景

换手机流量马上就正常——大概率是本地宽带、路由器或者本地 DNS 的问题，别急着迁服务器。只有后台慢、前台好好的——多半是后台程序或者数据库，不是线路。只有带 www 的地址超时、不带的好好的——去查解析记录，别去查防火墙。只有某个接口超时、页面框架照常出来——那是接口依赖的后端服务或者第三方 API 出了问题。只有移动网络用户报超时——先怀疑运营商侧和 CDN 节点覆盖。

这些场景的共同点是：现象越局部，越说明问题不在全局。很多人一看到「超时」两个字就直接给服务器升配置，钱花了，问题还在。

一套能照着走的排查顺序

顺序别乱：先在浏览器 F12 看 Timing，确定卡在哪一段；再换网络、换设备、换地区复测，判断是不是局部问题；然后 curl 分段计时，量化到毫秒级；接着 mtr 看链路丢包落在哪一跳；再登服务器看负载、内存、IO 和慢查询；最后对一遍 CDN 回源日志和源站访问日志，看请求到底有没有到源站。请求压根没到源站，锅在线路或者 CDN；请求到了源站却迟迟不响应，锅在服务器和应用。

顺带提一句，带宽和 TTFB 基本是两码事。首字节慢是处理慢，加带宽解决不了；内容下载慢才是带宽和页面体积的事。这两件事被混为一谈的次数，比想象中多得多。

真出问题的时候，先截个图、留一份 curl 输出和 mtr 报告，再动手重启。等一切恢复正常了再回头找证据，往往什么都抓不到。把时间分段这件事做扎实，网站超时是服务器线路谁背锅，答案基本自己就浮出来了。