机场延迟低为什么速度还是慢？延迟、带宽与丢包的关系

先说结论

延迟低、速度慢并不矛盾。延迟说的是“多快能得到回应”，速度说的是“每秒能搬多少数据”，两者由不同的因素决定。 客户端里的延迟测试只通过节点请求一次测试地址，拿回一个几乎没有数据量的响应，所以它测不出带宽。真正决定下载速度的，是代理链路上最窄那一段的可用带宽，以及丢包率。

举个例子：一个显示 50ms 的节点，如果晚高峰跨境带宽被挤满，或者链路持续丢包，速度照样上不去；反过来，一个 150ms 但稳定不丢包的节点，下载可能反而更快。下文先讲清延迟测试测了什么，再分析让速度变慢的常见原因，最后给出排查步骤和对照表。代理链路由哪几段组成，可以先看专题主文章 代理上网的原理。

客户端里的“延迟”到底测了什么

Clash 系客户端（mihomo 内核）做延迟测试时，会通过节点去请求一个测试地址，记录从发起请求到收到响应的耗时。测试地址可以自己设置，mihomo 文档示例配置里用的是 https://www.gstatic.com/generate_204：这类地址只返回 HTTP 204 状态码，没有任何正文内容。

所以这个数字包含：

• 客户端与节点建立连接、完成代理协议握手的时间；
• 节点连接测试地址、拿回 204 响应的往返时间。

它不包含任何带宽信息：整个测试只传输了很少的数据，一条只剩一点点余量的拥挤线路，也能很快完成这次请求。

mihomo 有一个“统一延迟”选项（unified-delay）。文档的解释是，开启后会计算 RTT，以消除连接握手等带来的不同类型节点的延迟差异；Clash Verge Rev 的界面提示也写明，开启后会进行两次延迟测试。开启后数字通常会变小，网络本身并没有变化。

三种常见的“测延迟”方式，测的东西并不相同：

延迟、带宽、丢包：三个指标各管什么

可以把代理链路想象成一条公路：延迟是路程的长短，带宽是车道的数量，丢包则像路上不时有车抛锚，后面的车只好减速、重新排队。

关键在“最窄的一段”。一次代理访问至少经过四段：你的本地网络、你到入口、入口到出口（跨境段）、出口到目标网站。速度上限由其中最窄的一段决定。延迟测试数字低，只能说明每一段都“通”，不能说明每一段都“宽”。

还有一个常见的单位误会：宽带和测速网站多用 Mbps（兆比特每秒），下载软件多显示 MB/s（兆字节每秒），两者相差 8 倍。100Mbps 的带宽跑满，下载软件里大约显示 12.5MB/s，这是正常的。

丢包为什么会让速度断崖式下降

网页、视频、文件下载大多基于 TCP。TCP 会根据确认情况调整一次能发送多少数据，并把丢包当作“网络拥塞”的信号，一旦发现丢包就主动降速。RFC 3649 给出了经典 TCP 的响应函数：平均拥塞窗口约等于 1.2 除以丢包率的平方根（以报文段计）。而速度大致等于“窗口大小 ÷ 往返时间”，于是有两个直接推论：

• 丢包率变成原来的 4 倍，速度上限大约降到一半；
• 往返时间越长，同样的丢包造成的速度损失越大，跨境链路对丢包格外敏感。

IETF 关于 BBR 拥塞控制的草案里给过一个更具体的例子：在往返时延 100ms 的路径上，即使丢包率只有 1%，基于丢包的 CUBIC 算法最多也只能维持约 3Mbps。按上面的公式、以每个报文段 1460 字节粗略估算（单个 TCP 连接的理论上限，仅作举例）：延迟 50ms、丢包 3% 的连接，上限不到 2Mbps；延迟 150ms、丢包 0.01% 的连接，上限约 9Mbps。延迟低但丢包的节点，跑不过延迟稍高但干净的节点，原因就在这里。

在代理链路里，下载方向的数据是由节点服务器发给你的，所以服务器使用哪种拥塞控制算法也有影响。同一份草案提到，在浅缓冲或存在随机丢包的瓶颈上，BBR 能提供明显更高的吞吐。这属于机场的服务器配置，用户无法自己调整。基于 QUIC 的协议（如 Hysteria2）有自己的拥塞控制方式，表现与 TCP 类协议不同，见 代理协议怎么选。

速度慢的六类常见原因

晚高峰拥塞

每天 20:00–23:00 前后，跨境出口的使用量最大。直连和普通中转节点经过公共国际出口，这一段一拥堵，就会同时出现延迟升高和丢包。专线节点不经过公共国际出口，晚高峰通常更稳，原理见 IEPL 是什么。

机场带宽不足、超售或限速

一台服务器的带宽由所有连在上面的用户共享。用户数远超带宽承载能力，就是常说的“超售”。超售的节点有一个典型特征：延迟测试照样很低（测试几乎不占带宽），但下载速度明显偏低，晚上更明显。另外，有的套餐会在说明里写明单用户限速，购买前值得留意。

节点服务器负载过高

加密、解密和转发都要消耗服务器的 CPU。某个节点连接数过多时，速度会忽快忽慢，同地区的其他节点却正常。这种情况换一个同地区节点就能验证。

本地网络与 Wi-Fi

很多“机场慢”其实是本地网络慢：宽带本身带宽有限、路由器性能不足、2.4GHz Wi-Fi 受干扰、隔墙信号衰减、同时有其他设备在大量下载。手机开启省电模式时，网络性能也可能受到限制。判断方法很简单：关掉代理测一次速度，如果本来就慢，问题不在机场。

协议开销与设备性能

代理协议给每个数据包加上额外的头部和认证信息，加密解密也要占用 CPU。在近几年的电脑和手机上，这部分开销通常可以忽略；但在老旧手机、性能较弱的路由器上运行代理，或者同时开着两层代理时，设备本身就可能成为瓶颈。开启 TUN 后变慢，也可以先排查这一点，TUN 的设置要点见 TUN 模式和系统代理有什么区别。

目标网站和测速方式本身

速度还取决于你访问的服务器：目标网站离出口很远，或者在本地解析域名、拿到了不适合出口位置的 CDN 地址，都会拖慢速度。此外，测速网站常用多个连接同时下载，单个连接的视频或文件下载更容易受丢包影响，两者的数字不能直接比较。

自己动手排查：六个步骤

1. 先测不开代理时的本地速度

   完全退出代理客户端（或关闭系统代理和 TUN），用国内的测速服务测一次下载速度，并顺手对比有线和 Wi-Fi。这个数字就是上限：节点再好，也不会超过你自己的宽带。

2. 用大文件实测节点速度

   选定一个节点，下载一个几百 MB 的文件，看速度稳定后的数值，而不是开头几秒的峰值。命令行的做法见下方示例。

3. 换同地区的其他节点对比

   只有一个节点慢，多半是该节点负载高或超售；同一机场所有节点都慢，再往本地网络或机场整体带宽上找原因。

4. 换时段重测

   下午测一轮作为基准，再在 20:00–23:00 之间测几天。只有晚上慢，多半是高峰期拥塞：可能在跨境段，也可能在你到入口这一段，下一步用丢包检查来区分。

5. 检查丢包

   关闭代理，对节点的入口地址连续 ping 100 次，看丢包比例。你到入口这一段不丢包、晚上却依然很慢，说明问题在入口之后的跨境段。入口地址怎么找，见 机场线路怎么判断。

6. 检查设备和客户端

   关掉其他代理或 VPN 软件，对比只开系统代理和开启 TUN 的速度，留意 CPU 占用，并把客户端更新到官方最新版本。

用 curl 通过本机代理端口下载测试文件，可以同时看到握手耗时和平均速度。下面以 Clash Verge Rev 的默认端口 7897 为例，端口请以你的客户端设置为准，下载地址换成任意一个体积较大的官方文件：

# macOS / Linux：经代理下载并丢弃文件，最后输出耗时与平均速度（字节/秒）
curl -x http://127.0.0.1:7897 -o /dev/null -s \
  -w "TLS 完成: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n平均速度: %{speed_download} B/s\n" \
  https://example.com/large-file.zip

# Windows：PowerShell 里请输入 curl.exe，避免调用同名的内置命令
curl.exe -x http://127.0.0.1:7897 -o NUL -s -w "平均速度: %{speed_download} B/s\n" https://example.com/large-file.zip

# 关闭代理后检查到入口的丢包（203.0.113.10 为示例地址，换成你的入口 IP）
ping -n 100 203.0.113.10

macOS 和 Linux 检查丢包用 ping -c 100 加入口地址。“首字节”时间明显偏长、平均速度却正常，说明问题更多在握手和响应环节；首字节很快、平均速度很低，则是带宽或丢包的问题。

对照表：现象、原因与处理

如果排查下来确认是机场的带宽或线路问题，换节点只能缓解。判断一家机场晚高峰是否稳定的方法，见 稳定机场推荐与判断标准。

总结

延迟测试只证明节点“通”且“回应快”，不证明它“宽”。速度由链路上最窄的一段和丢包率决定，晚高峰拥塞、超售限速、本地 Wi-Fi 和设备性能是最常见的瓶颈。遇到“延迟低速度慢”，按本地带宽、实测下载、换节点换时段、检查丢包的顺序排查，就能定位问题出在哪一段。