VPS 网站打开慢怎么排查：双源实测 TLS 段差 370.499 ms
有人看到浏览器 DevTools 里 Waiting (TTFB) 拖出很长一条，顺手就去给 VPS 加 CPU、加内存。配置换了一档，那条还是那么长。VPS 网站打开慢怎么排查，卡住人的多半不是这个动作，而是以为网站慢只对应一个数字。一次 HTTPS 请求从回车到收完响应，会被切成 DNS、TCP 建连、TLS 握手、服务端处理、响应体传输 5 段，任何一段拖长，页面都慢。把两个中国大陆不同运营商出口对同一批公开目标的请求净拆成这 5 段，能回答一个很具体的问题：同一个网站换个出口，到底哪一段慢、差多少毫秒。
网站打开慢不是一个数，是 5 段
直接答案：一次 HTTPS 请求可净拆成 DNS、TCP、TLS、服务端、传输五段；2026-11-14 双源实测里，example.com 换出口后变化最大的是 TLS 段，差 370.499 ms，服务端段只差 8.533 ms。
表 1 是这批数据的主干。三个目标、两个出口、每源每目标 5 轮取均值，DNS、TCP、TLS、服务端、传输、总耗时六列全摊开，单位是毫秒。
表 1 三个公开目标 × 两个出口的五段净耗时均值（ms）
| 目标 | 出口 | DNS | TCP | TLS | 服务端 | 传输 | 总 |
|---|---|---|---|---|---|---|---|
| example.com | 广东电信 cn-probe-1 | 9.899 | 415.467 | 497.101 | 264.933 | 0.147 | 1187.547 |
| example.com | 北京阿里云 cn-probe-2 | 4.000 | 213.000 | 867.600 | 256.400 | 0.200 | 1341.200 |
| www.baidu.com | 广东电信 cn-probe-1 | 8.694 | 27.758 | 130.310 | 28.797 | 0.490 | 196.049 |
| www.baidu.com | 北京阿里云 cn-probe-2 | 4.000 | 3.600 | 95.400 | 4.400 | 0.200 | 107.600 |
| www.cloudflare.com | 广东电信 cn-probe-1 | 1.558 | 368.427 | 318.307 | 168.765 | 3569.944 | 4427.000 |
| www.cloudflare.com | 北京阿里云 cn-probe-2 | 601.400 | 248.800 | 889.800 | 366.400 | 2031.200 | 4137.600 |
横着读，最扎眼的是传输段。example.com 两源 0.147 与 0.200，www.baidu.com 0.490 与 0.200，都不到 1 毫秒；www.cloudflare.com 却到了 3569.944 与 2031.200。同一个出口，目标换一个，传输段从零点几毫秒跳到几千毫秒。这三次请求拿到的都是 http_code 200，响应体大小、是否压缩、有没有重定向跟随，curl 单请求说不全，这批数据也不负责解释。
再看服务端这一段。它是 TLS 握手完成到收到第一个字节之间的净耗时，对应 DevTools 里 Waiting (TTFB) 的主体，也是不少教程笼统归给服务器慢的地方。表里 example.com 两源 264.933 与 256.400，差得不多；www.baidu.com 28.797 与 4.400；www.cloudflare.com 168.765 与 366.400。同一个目标换出口，这一段也在变。
累计值不是该段耗时，这是读表 1 最容易踩的坑。curl 吐出来的 time_namelookup、time_connect、time_appconnect、time_starttransfer、time_total 都是从请求发起算起的累计秒数，一路只增不减。要拿到每段净耗时，得把相邻两个累计值相减。
表 2 五个累计值怎么相减得到五段净耗时
| 段 | 算法 | 对应含义 |
|---|---|---|
| DNS | time_namelookup |
域名解析到 IP |
| TCP | time_connect − time_namelookup |
与对端建连 |
| TLS | time_appconnect − time_connect |
TLS 握手完成 |
| 服务端（首字节） | time_starttransfer − time_appconnect |
后端处理到吐出首字节 |
| 传输 | time_total − time_starttransfer |
收完响应体 |
表 1 里每个数都是这么减出来的，再乘以 1000 换成毫秒。把 time_total 直接当成传输时间、把 time_starttransfer 当成服务端净耗时，是两种很常见的读错法，后者会把前面 DNS、TCP、TLS 三段全算到服务端头上去。
一条 curl -w 命令把一次 HTTPS 请求拆成 5 段
命令不用长，一股脑把五个累计值打出来就行。命令模板长这样，不是本站某次的输出：
curl -sS -L -o /dev/null --max-time 20 -w 'namelookup=%{time_namelookup} connect=%{time_connect} appconnect=%{time_appconnect} starttransfer=%{time_starttransfer} total=%{time_total} http=%{http_code} ip=%{remote_ip}' https://<目标>/
-o /dev/null 把响应体丢掉，只留计时；-L 跟随重定向；--max-time 20 给单次请求设 20 秒上限。http_code 和 remote_ip 是两个不带计时的字段，用来验这一轮算不算一次正常响应，别把 501 或超时的读数混进对照表。
五个变量里，time_starttransfer 最容易被漏掉。只取 namelookup / connect / appconnect / total 四个值，TLS 握手到首字节这一段就并进了总耗时，服务端处理慢还是响应体大，分不开。补上这一个变量，一次请求才净拆得成 5 段。变量释义可以翻 curl 官方手册，逐个字段的写法在 writeout 变量清单 里也列得全。
每源为什么要跑 5 轮
单跑一次，数字会骗人。表 3 是 example.com 在两个出口各跑 5 轮的总耗时。
表 3 example.com 总耗时 5 轮原始值与 min / 均值 / max（ms）
| 轮次 | 广东电信 cn-probe-1 | 北京阿里云 cn-probe-2 |
|---|---|---|
| 1 | 717.728 | 1301.000 |
| 2 | 630.307 | 2095.000 |
| 3 | 3238.587 | 740.000 |
| 4 | 692.542 | 1323.000 |
| 5 | 658.569 | 1247.000 |
| min | 630.307 | 740.000 |
| 均值 | 1187.547 | 1341.200 |
| max | 3238.587 | 2095.000 |
广东第 3 轮冲到 3238.587，其余四轮都在 630.307 到 717.728 之间；北京第 2 轮 2095.000，第 3 轮又落到 740.000。要是只取第一轮，广东 717.728、北京 1301.000，会得出北京慢得多；只取第三轮，结论整个反过来，广东 3238.587 对北京 740.000。单轮抖动能把两源的快慢关系倒过来，所以每个目标每源都跑 5 轮，取均值进表 1，把 min 和 max 留着看波动。
DNS 缓存也是跑多轮的理由。第一次解析可能冷启动，后面几轮命中缓存，namelookup 会小一截。北京出口对 www.baidu.com 的 DNS 五轮都是 4.000，稳得像钉住的；同一出口对 www.cloudflare.com 的 DNS 却从 124.000 一路跑到 2510.000。这种抖动不摊开五轮，看不出来。
我第一次拉这批数据就被第 3 轮那个 3238.587 带偏过，差点当成目标站常态，回头重跑才确认是单轮抖动。这也是「网站打开慢怎么排查」里最不起眼、却最费时间的一步：先把测量本身稳住，再谈哪一段慢。
双源实测：同一个目标，两个出口各慢在哪一段
表 4 把表 1 里两源同目标的每一段相减，取绝对值。数值大的那一段，就是换出口后变化最大的地方。表 4 只列数据包单列过逐段差值的两个目标。
表 4 example.com 与 www.baidu.com 两源逐段差值绝对值（ms）
| 目标 | DNS | TCP | TLS | 服务端 | 传输 |
|---|---|---|---|---|---|
| example.com | 5.899 | 202.467 | 370.499 | 8.533 | 0.053 |
| www.baidu.com | 4.694 | 24.158 | 34.910 | 24.397 | 0.290 |
example.com 这一行，TLS 段差 370.499，是所有差值里最大的一格，TCP 段 202.467 次之，服务端段只有 8.533。换出口后变得最厉害的是 TLS 握手，不是后端处理。www.baidu.com 那一行小得多，最大的一格还是 TLS 的 34.910，服务端 24.397 紧跟着。
两源各自慢在哪一段，得一个目标一个目标看。拿 example.com 说：广东在 TCP 段 415.467、服务端段 264.933，都比北京的 213.000、256.400 大；TLS 段反过来，广东 497.101 比北京 867.600 小。这一个目标，广东慢在 TCP 和服务端，北京慢在 TLS，段落是错开的。 www.baidu.com 是另一种样子：广东 TLS 130.310 对北京 95.400，两源都是 TLS 段占了大头，只是幅度不同，而且两源解析到的 IP 并不相同，广东是 180.101.49.44，北京是 220.181.111.232。example.com 倒恰好相反，两源都解析到 104.20.23.154。
不看清是哪一段，光说网站打开慢或者这个出口快，两边都对不上。这才是双源对照最有用的一格。
两源结论对不上时怎么分流
只在一个网络里测，最容易把出口问题当成服务器问题。有人从自己办公室拉一条线测出 Waiting (TTFB) 很长，就认定后端该优化，回头加机器、加缓存，钱花了，慢还在。表 4 给了个更省事的分流办法：同一目标换第二个出口复测，服务端段两源都高，才往后端处理上查；服务端段一个高一个低，或者偏高的始终是 DNS、TCP、TLS 这几段，先别动服务器，去看出站链路。
举个更贴表的：example.com 的服务端段 264.933 与 256.400，两源几乎齐平，这种就该往 TLS 段 497.101 与 867.600 上追。www.baidu.com 广东 TLS 130.310、北京 95.400，占各自总耗时 196.049 与 107.600 的主体，这一段两源都高，跟证书链、握手往返有关，和后端代码快慢不是一回事。
拿不准该往哪一层继续，VPS 测评与实测归档 里按层分过类，可以顺着找同一层的其它记录。
cloudflare.com 这一组：传输段大得反常
表 1 最后两行值得单独拎出来。www.cloudflare.com 的传输段，广东 3569.944，北京 2031.200，都是各自六列里最大的一段，比各自的 TLS 段 318.307 和 889.800 还大；两源总耗时 4427.000 与 4137.600，主要就压在这一段上。
北京那一侧还有一处怪：DNS 段 5 轮均值 601.400，min 124.000、max 2510.000，第 5 轮冲到 2510.000 把均值整个抬起来。广东 DNS 段均值 1.558，min 1.176、max 1.769，五轮稳得很。同一个目标，一个出口 DNS 平滑，另一个出口单轮抖出 2510.000，这种差异跟目标站本身快不快无关，是这次从这两个出口看出去的读数。
传输段大，直观看是响应体收得久。为什么久，是响应体本身大、分片多、还是传到一半链路慢，curl 单请求拆不出来，这批数据也没采响应体大小和并发数。能写进结论的只有一句：这个目标在这两个出口上，慢主要落在传输段，不在服务端段。再往下推就出界了。
五段各自慢，分别往哪查
表 5 把五段和优先方向对上号。方向只给个头，具体怎么查不在这篇展开。
表 5 哪一段偏高、往哪个方向查
| 偏高的段 | 大致含义 | 优先方向 |
|---|---|---|
| DNS | 域名解析到 IP 慢 | 解析链路，见 DNS 解析慢怎么排查 |
| TCP | 建连往返慢 | 链路与去程路径，见 延迟怎么测才准、去程路由怎么查 |
| TLS | 握手与证书链慢 | 证书链是否完整、有没有会话复用 |
| 服务端 | TLS 完成到首字节慢 | 后端处理，这台机器有没有在满载，见 负载高怎么排查 |
| 传输 | 首字节到收完慢 | 响应体大小与传输过程 |
TLS 段值得多说一句。example.com 和 www.baidu.com 这四个出口读数里，TLS 都是除总耗时外最大的一段；到了 www.cloudflare.com，两源最大的一段换成了传输。它在 DevTools 的 Waterfall 里常和 Waiting (TTFB) 挤在一块，容易被一并记到服务器慢头上。表 2 那道减法把它单独切出来，才知道这段是握手，不是后端在算。
用这批数据定位，顺序其实很短
VPS 网站打开慢怎么排查，动作都围着这张五段表转：在客户端跑一次带五个累计值的 curl，相邻值相减得到 5 段，找出最大的那一段，照表 5 定方向，再换第二个出口对同一目标复测一遍，看这一段是不是两源都高。确认了才决定动哪里。多数人卡在跳过复测那一步，拿着单出口的读数去改后端。
动手前还有两件更靠前的事：确认目标端口通，确认机器时间没跑偏。端口不通、证书因为时间偏差验不过，五段表根本跑不出正常的 200，读数也就没有意义。这两层分别归 端口不通怎么排查 和 时间不准怎么排查，这里只点一句，不展开。
确认完还慢，问题又落在出口这一侧，按网络与机房归过的商家清单 可以拿来对照。
这批数据给不了的结论
先把最容易混的一条说清：ICMP 往返延迟不等于一次 HTTP 事务耗时。ping 快，网页照样可能慢，因为 ping 不建连、不握手、不取响应体，量的是另一件事。tracepath 只作去程路径旁证，也不保证每一跳都回显。这两样本批只用来标注环境，没进过表 1。
再往下几条，一次性说完。测的是公开目标，不是任何商家在售机器，不能拿它排哪家 VPS 打开快，也不能反推某条线路质量。curl 单请求不等于页面完全加载，浏览器首屏、DOMContentLoaded、并发、p95 这些数字，本批一个都没有。两个出口都在中国大陆，结论只覆盖这两个不同运营商出口，不往更多出口、更多地区上推；机器性能层的 CPU、磁盘、带宽跑分同样没测，不给。
两个没取得正常响应的目标
www.qq.com 两源 5 轮的 http_code 都是 501，没有一次 200。这种响应不是一次正常的页面事务，分段读数不进表 1 的对照，也不拿它反推服务可用性，就写本次未取得可用的正常响应分段数据。www.wikipedia.org 那组更干脆：广东出口连到 20 秒超时，北京出口解析到 IPv6 地址后报网络不可达，两源 5 轮 http_code 都是 0。这两组都记作本次未取得，不补数、不估算、不拿别的目标顶替。
采集口径与留痕
两个源的标签写死，方便逐条回溯：cn-probe-1 是 103.39.226.31，中国广东电信 AS4816 单线；cn-probe-2 是 8.140.30.240，中国北京阿里云 AS37963 BGP 多线，两台都在中国大陆，全程只读。首轮 ping 采样 2026-11-14 15:51:29 +0800，两源 curl 采样的 stamp 是 2026-11-14 15:57:27 +0800。每源每目标 5 轮，命令模板就是前面那条 curl -w，带 --max-time 20，只对公开目标发 GET。原始输出留在 ops/_20261114_http5.json，五段数值都能在这份留痕里逐条对上。
真到排障无果、想换台机器重测那一步，优惠券与在售套餐 按预算挑就行，别急着按某一次 curl 的读数下单。
VPS 网站打开慢怎么排查，说到底就一句：先把一次请求净拆成五段，再换第二个出口复测同一段，两源都高才动对应的那一层。只拿单出口单轮的 TTFB 去加 CPU，多数时候改不到点上。
常见问题
为什么我测网站打开慢，和别人测的结果对不上？
出口不一样。表 3 里 example.com 广东第 3 轮 3238.587、北京第 3 轮 740.000，同一轮两个出口差得很远；换一轮，快慢关系又会翻。别人从哪个出口、哪个时段、单轮还是多轮，都会改结果。把源标签、采集时间、命令一起写进结论，两边才对得上。
TTFB 高，是不是一定服务器慢？
不一定。表 2 把 TLS 握手到首字节这一段单独切出来，才是服务端净耗时；DevTools 里 Waiting (TTFB) 那条常把 TLS 握手也裹进去。表 1 里 example.com 两源服务端段 264.933 与 256.400，差得不多，反倒是 TLS 段 497.101 与 867.600 拉开了距离。先减出五段再下结论。
只有两个出口，够不够给网站打开慢下结论？
只够覆盖这两个出口。够不够看要答什么：回答同一个网站换出口哪一段慢，两个源就成立，表 4 的差值也是这么来的；要推更多出口、更多地区的普遍快慢，这两个源撑不住，照实写覆盖不到，不往外推。
ping 很快，网页还是打开慢，问题在哪？
ping 量的是 ICMP 往返，不建连、不握手、不收响应体。表 1 里 www.baidu.com 北京总耗时 107.600，其中 TLS 段就占 95.400，这段 ping 完全照不见。按五段表看，比盯着 ping 值有用。
换 DNS 能不能解决网站打开慢？
得看慢在哪一段。表 1 里 DNS 段大多是几毫秒：example.com 9.899 与 4.000，www.baidu.com 8.694 与 4.000，www.cloudflare.com 广东 1.558，换 DNS 能省的有限。北京对 www.cloudflare.com 的 DNS 段均值 601.400 是单轮 2510.000 拉起来的个例。TLS、服务端、传输这几段高，换 DNS 不对症。
HTTP 501 和超时的目标，怎么处理？
不进对照表。www.qq.com 两源 5 轮都是 501，www.wikipedia.org 广东 20 秒超时、北京 IPv6 地址网络不可达，都记作本次未取得可用的正常响应分段数据。不补数、不估算、不拿别的目标顶替，也不据此说服务不可用。只有 http_code 全是 200 的三个目标进了表 1 的对照。
