网站访问慢四段定位：DNS、TCP、TLS、首字节，一段一段量

“网站慢”是站长收到过的最模糊的报障。慢在哪一段？用户网络慢、DNS 慢、服务器慢、还是资源大？不拆开量，优化就是瞎蒙。本篇给你一条 curl 命令，把打开一个网页的全过程切成四段，每段各多少毫秒一目了然，慢在哪就查哪。

四段分别对应：time_namelookup 是 DNS 解析耗时；time_connect 是 TCP 三次握手（含 DNS 之后的网络往返）；time_appconnect 是 TLS 握手完成；time_starttransfer 是发出请求到收到首字节，也就是 TTFB，这一段主要反映服务器处理慢不慢；最后 time_total 收整个响应体。curl 的 -w 变量正好一一对应。

# 保存为 slow_check.sh，用法：./slow_check.sh https://你的域名/
#!/bin/bash
for i in 1 2 3; do
 curl -o /dev/null -s -w \
 "DNS:%{time_namelookup}s TCP:%{time_connect}s TLS:%{time_appconnect}s TTFB:%{time_starttransfer}s TOTAL:%{time_total}s HTTP:%{http_code}
" \
 "$1"
done

跑三次取平均是为了滤掉网络抖动。拿到数据对照判读：DNS 超过 0.1 秒，说明解析链路慢，本地运营商 DNS 或者你配置的权威 DNS 有问题；TCP 段长但 DNS 快，是网络线路问题，离机房远或者绕路；TLS 段超过 0.3 秒，查证书链是否完整（多下发的中间证书会多一次往返）、有没有开 TLS 1.3 和 session 复用；TTFB 段最长，责任在服务端，数据库慢查询、接口串行调用都藏在里面。

TTFB 长了怎么继续钻？在服务器上分头量：Nginx 的日志加 $request_time 和 $upstream_response_time 两个字段，前者是 Nginx 总耗时，后者是等后端应用的时间。upstream_response_time 大，问题在应用和数据库；两者都小但 curl 量出来大，问题在传输路径，回头看 TCP 段。

# Nginx 日志格式加耗时字段
log_format timing '$remote_addr "$request" $status '
 'req:$request_time up:$upstream_response_time';
access_log /var/log/nginx/timing.log timing;
 
# 抓最慢的 20 个请求看看都是谁
awk -F'up:' '{print $2, $0}' /var/log/nginx/timing.log | sort -rn | head -20

判读口诀总结：DNS 慢换解析，TCP 慢看线路，TLS 慢查证书链和握手版本，TTFB 慢钻后端，资源本身大上压缩和 CDN。四段各管一段，别把线路的锅让代码背，也别拿 CDN 优化去救慢查询。每次改动后重跑一遍脚本对比数字，优化效果用数据说话。

相关阅读：访问慢是横跨四段的综合症。《服务器故障排查总纲：按现象反查的五层定位法》的分段量测法是总纲方法论的源头，本篇是这套方法最完整的实战演示，总纲建议收藏。