"网速慢"是一个笼统的说法。实际使用中感受到的延迟，由多个互相独立的环节叠加而成，每个环节的耗时差别很大。理解这些环节，才能判断问题出在哪一段。
一次请求走过的环节
从点击到看到结果，大致经过以下几个阶段：
- DNS 解析：把域名翻译成 IP 地址。如果本地没有缓存，需要向递归服务器查询，通常 20 至 100 毫秒；缓存命中时接近 0。
- TCP 握手：与服务器建立连接。同城通常 10 至 30 毫秒，跨国可能 150 毫秒以上。
- TLS 握手：HTTPS 加密协商。完整握手需要 1 至 2 个往返，即额外的 2 至 4 倍单程延迟，在跨国链路上可能达到数百毫秒。
- 请求发送与首字节：服务端处理请求并返回第一个字节的时间（TTFB）。这一段的耗时取决于服务端逻辑复杂度，与网络关系不大。
- 内容传输：把响应内容完整传回。受带宽和内容大小影响。
- 解析与渲染：浏览器解析 HTML、加载资源、执行脚本、绘制界面。这一段完全是本地计算，但复杂页面的耗时可能超过网络部分。
把这几段加起来的"总延迟"，才是用户实际感受到的等待时间。其中DNS、握手、TLS 三段在首次访问时全部要付，第二次访问时大部分可以省掉——这就是为什么同一个网页第二次打开明显更快。
哪些环节影响最大
在典型的移动网络环境下，各环节的量级估算：
| 环节 | 同城/同省 | 跨国 | 可否优化 |
|---|---|---|---|
| DNS 解析 | 10-30 ms | 50-200 ms | 缓存、更换 DNS |
| TCP 握手 | 10-30 ms | 150-300 ms | 连接复用 |
| TLS 握手 | 20-60 ms | 300-600 ms | 会话复用、TLS 1.3 |
| 服务端处理 | 20-200 ms | 同左 | 服务端优化 |
| 资源传输 | 视大小 | 视大小 | 压缩、CDN |
可以看出，跨国链路上握手环节的代价极高。这也是 CDN 存在的核心原因：把内容缓存到离用户更近的节点，让握手发生在近距离链路上，而不是跨越整个国际链路。
如何定位问题
如果感觉"卡"，可以按以下顺序排查：
- 先测 DNS：如果换一个网络环境（比如从 Wi-Fi 切到移动数据）后明显变快，问题可能出在 DNS 或本地网络。
- 看是否首次访问才慢：如果只有第一次慢、刷新后正常，说明瓶颈在握手或资源加载，不是持续性的网络问题。
- 对比其他站点：如果只有某个站点慢、其他站点正常，问题在服务端或该站点的链路，不在本地网络。
- 检查是否在加载大资源：开发者工具的网络面板可以看到每个资源的耗时和大小，通常能直接看出是哪个文件拖慢了整体。
很多"网络慢"的抱怨，实际原因是大图未压缩、脚本阻塞渲染、或者第三方统计脚本超时。这些都不是网络问题，但表现完全相同。
常见疑问
问：为什么测速软件显示很快，网页还是很慢？
答：测速软件测的是本地到测速节点的带宽，而网页加载速度取决于到目标服务器的往返延迟、丢包率、以及页面本身的复杂度。带宽高但延迟高的情况很常见，尤其在跨运营商访问时。
问：换 DNS 有用吗？
答：只对"DNS 解析慢"这一类问题有用。如果瓶颈在握手或服务端处理，换 DNS 没有效果。而且首次解析之后 DNS 结果会被缓存，影响会持续一段时间。
问：为什么晚上特别慢？
答：晚间是网络使用高峰，运营商出口与国际链路拥塞程度上升，丢包率提高。丢包会触发重传，而重传的代价在长链路上被放大，所以体感下降会比带宽下降更明显。