一句话答案：遇到首字节时间偏高，先别急着换机器、也别急着上 CDN。顺序是：第一步核对状态码和跳转次数，把多余的跳转摘掉；第二步逐段看握手耗时（依次是 DNS、TCP、TLS），确认这一段有没有拖后腿；前两步都干净，问题才落在服务端，去查应用执行、数据库查询和缓存命中。
首字节时间（TTFB，Time To First Byte），说的是浏览器发出请求后，到收到服务端第一个字节为止所花的时间。这篇拿宝塔拨测的网站测速（HTTP 检测）对 www.bt.cn 做过的一次实测（2026-10-29，392 个成功节点）当例子，把三步排查走一遍。
一、先明确：首字节高和整页慢不是一回事
这两个概念经常被混着说。首字节只统计到「第一个字节到达」为止，整页加载却要把 HTML、CSS、JS、图片统统下完。粗略地讲，前者约等于请求总耗时减去内容下载耗时：首字节这一项高，说明卡在服务端开始吐数据之前；而传输段高，才是内容体积大、带宽吃紧。
所以这篇不讨论怎么拆段（那是另一篇的活儿），只回答一个问题：首字节已经确认偏高，接下来按什么顺序找原因。
二、第一步：核对状态码与跳转次数
重定向是第一个要排除的嫌疑。探测节点一旦收到 301/302，就得朝新地址再发一次请求，等于把解析、建连、等响应整套流程重跑一遍。跳转越多，往返越多，首字节自然被顶上去。
结果页里盯两个字段：状态码、重定向次数。
- 状态码是 301 或 302，又或者跳转次数不为零，就说明目标地址存在跳转。常见的有 http 强制收敛到 https、首页指向 /index.html、裸域跳到带 www 的域名。
- 合理跳转（比如 http 统一收敛到 https）没必要删，但心里要有数：这次往返会计入首字节。至于那些叠了好几层的跳转链（http → https → 补尾斜杠 → 首页），每砍一层就少一次往返，值得动手。
这次实测 www.bt.cn，392 个成功节点最终状态码都是 200，可每个节点都记了 1 次重定向：响应头返回 302，Location 指向 https://www.bt.cn/new/index.html。这属于把首页导向真实入口的正常配置，不算故障，但那一次往返确实被算进了后面的首字节里。
三、第二步：看分段耗时，先排除网络握手
跳转排除完，接着看分段耗时里靠前的三项：域名解析（DNS）、建连（TCP）、握手（TLS）。它们合起来构成建连阶段的网络开销。
- DNS 解析偏慢：多半是域名解析服务响应不及时，可以考虑换解析服务商，或者精简记录。
- TCP 连接偏慢：通常是探测点到源站距离远、路由绕，或者链路拥塞。
- TLS 握手偏慢：正常数值很小，一旦异常拉高，回头查证书链和 HTTPS 配置。
www.bt.cn 这次的中位数如下：
阶段
| 中位数耗时
| DNS 解析
| 17.6 毫秒
| TCP 连接
| 46.4 毫秒
| TLS 握手
| 67.4 毫秒
| 首字节
| 302.8 毫秒
| 传输（下载）
| 0.1 毫秒
|
三段握手都停在几十毫秒，加起来还不到首字节的四成，可见网络侧不是主因；真正的大头是 302.8 毫秒的首字节。既然握手没问题，就该往第三步走了。
四、第三步：服务端处理慢，按应用、数据库、缓存顺序查
跳转没有多余、握手也正常，首字节仍然下不来，那就只能怀疑服务端处理慢：请求早到了，机器却迟迟不吐第一个字节。建议照下面这个顺序过一遍。
- 应用执行慢：后端程序、脚本或者接口拿到请求后算了太久。
- 数据库慢查询：程序卡在等数据库返回，整条响应被拖住。
- 缓存未命中：页面缓存过期或者压根没配，每次请求都现算一遍，而不是直接吐缓存。
对应的优化手段是上页面缓存、优化慢查询，而不是加机器、加带宽。带宽改善的是下载段，对首字节帮不上忙。
五、再补一招：用地区汇总区分「源站慢」还是「线路远」
如果拿不准是服务器不行还是线路太远，去看地区/运营商汇总。www.bt.cn 这次的差异相当直观：
- 国内四大运营商全部压在 400 毫秒以内：联通 252.7 毫秒；移动 269.2 毫秒；广电 346 毫秒；电信 375.5 毫秒。
- 港澳台地区均值 707.2 毫秒，海外节点 1358.7 毫秒，差距一眼就看得出。
把节点排个序，垫底的是泰国，3757.4 毫秒；再往后依次排到荷兰、马来西亚、印度、南非。跑得最快的五个则集中在广东和香港。同城同网快、一跨境就慢，这种分布说明卡在距离和跨境链路上，源站本身大概率没事。反过来说，若各运营商是一起慢的，那才该认真查源站性能。
六、三句话收个尾- 定位顺序是固定的：重定向 → 网络握手 → 服务端处理，前一步不排除就不进下一步。
- 每步只盯一个字段：先看状态码和重定向次数，再对比三段握手耗时，最后看地区汇总。
- 这次实测的结论：1 次 302 跳转，握手三项加起来几十毫秒，首字节却要 302.8 毫秒——锅在服务端响应和那次跳转，不在线路上。
档位怎么划分，以宝塔网站统计为准：优秀档 ≤400 毫秒、良好档 ≤800 毫秒、一般档 ≤1.8 秒，越过 1.8 秒就落到较差（详见官方文档《宝塔网站统计》）。上面的数值取自 2026-10-29 的真实拨测，节点池和线路随时在变，请只当作当时的快照。
常见问题
TTFB 高就一定是服务器不行吗？
不见得。常见的坑有三个方向：一是链路上多了一次或几次跳转，每次跳转都得重新走一遍完整往返；二是握手阶段拖沓，DNS、TCP、TLS 里有一段数值偏高；三是服务端自己算得慢。三类要按顺序排除，前两类排掉了，才能把责任归到服务器。
为什么一次跳转就能把首字节拉高？
探测端拿到 301/302 之后不能直接沿用原结果，必须照 Location 再请求一次，解析、建连、等待响应全部重来。这一次额外往返会实打实叠进「发起请求到收到首字节」的时间里，跳几层就叠几次。
网络慢和服务器慢怎么分开看？
抓手是分段耗时。解析、建连、握手这三项里只要有一项明显偏高，说明问题在握手或线路；反过来三项都很干净、唯独首字节那一项高，就说明包已经顺利送到，慢在服务端出数据。
首字节多少毫秒算高？
按宝塔网站统计的四档标准：优秀线 400 毫秒，良好线 800 毫秒，一般线 1.8 秒，越过 1.8 秒就算较差。
海外节点的 TTFB 高，就说明网站出毛病了吗？
多数情况不是。海外节点要经跨境链路回源，路途远、中转节点多，首字节本来就比国内高。判断方法是看地区汇总：同城访问快、跨省跨境就慢，基本可以归到线路和距离上；只有各运营商一起变慢，才需要怀疑源站。
以上就是 TTFB 偏高的三步定位思路。想看一次请求怎么拆段、每段指标怎么读，可以翻本系列《网站测速怎么做》那篇；确认问题出在服务端之后，优先动缓存和慢查询，别急着加带宽。排查过程中有拿不准的地方，欢迎回帖一起看。
|
|
运维要高效，装宝塔
