客户端里节点延迟明明显示 60ms，绿得发亮，结果一点开视频就转圈，网页半天出不来。你可能已经怀疑：是不是机场骗人？是不是测速有问题？
先说结论：延迟数字低，不代表这个节点“又快又稳”。客户端里那个延迟，通常只是测一次“能不能连通、来回要多久”，既不测下载带宽，也不测高峰期会不会丢包。所以“机场测速延迟很低却很卡”是很常见的情况，多数时候不是谁在造假，而是你拿错了指标。下面咱们把这件事掰开讲，最后给你一套自己就能做的排查流程。
说明一下：本文的依据是 sing-box、Mihomo 的官方文档，以及网络延迟、缓冲膨胀（bufferbloat）方面的公开资料，我们没有做任何自己的测速，文中也不会给出“某某节点实测多少 Mbps”这类数字。
一、先搞清楚：客户端里的“延迟”到底测了什么
以 sing-box 为例，它的 URLTest 官方文档写得很清楚：默认测试地址是 https://www.gstatic.com/generate_204，默认每 3m（3 分钟）测一次，tolerance（容差）默认 50 毫秒。Mihomo（Clash.Meta 内核）的文档里，策略组的健康检查同样有 url、interval、timeout 这些字段，官方示例用的也是 gstatic 的 generate_204 地址，间隔 300 秒。
说白了，这类延迟测试做的事情很简单：让节点去访问一个很小的测试地址，记下从发出请求到收到响应用了多久。它能回答的问题是“这个节点现在能不能通、反应慢不慢”，回答不了的问题有很多：
- 下载速度能跑到多少（带宽）；
- 连续看一小时视频会不会掉速；
- 晚高峰会不会丢包；
- 你要访问的那个具体网站，在这个节点上通不通。
另外，Mihomo 文档里还有一个 expected-status 字段：只有配置了它，才会要求返回特定状态码，默认值是 *，表示对响应状态码没有要求。也就是说，默认情况下“有回应”就算通过，至于回应的内容对不对，并不严格校验。
顺带一提，v2rayN 的 Wiki 里提到，现在测延迟和测速都会分批次进行，目的是提高成功率、降低资源占用。这也从侧面说明：同一批节点一起测，本身就会受你本地网络和测试方式影响，数字只能当参考。
二、延迟低却很卡的 6 个常见原因
1. 延迟是“单次小请求”，带宽是另一回事
你可以把延迟想成“打电话喊一声对方多久回应”，把带宽想成“水管有多粗”。喊一声很快，不代表水管粗。节点出口带宽被很多人共用、或者套餐本身限速，延迟照样很漂亮，但看 1080P 视频就是转圈。
2. 测的是“空闲时”，卡的是“用起来时”
延迟测试发生在你没怎么用网络的时候。可一旦开始下载、看视频，路径上的设备缓冲区被塞满，延迟就会飙升。这在网络领域叫“缓冲膨胀”：bufferbloat.net 的定义是“路由器或其他网络设备缓存了过多数据而产生的不良延迟”，并且指出人们感受到的上网速度，更多取决于延迟，而不是带宽。一家做网络测试的厂商（pong.com）在 2026 年的一篇博客里也举了例子，说空闲 15ms 的连接，在流量变大时可能涨到几百毫秒。注意这是厂商博客、带有自家产品宣传，我们只借它说明“空闲延迟≠负载延迟”这个常识，不引用它的具体数字当结论。
3. 丢包和抖动，延迟平均值看不出来
客户端给你的往往是一个数，比如 80ms。但这个数不告诉你：十次里有几次丢了、每次到达时间差多少（抖动）。打游戏、视频会议特别怕这两样；网页和视频遇到丢包，则会因为重传而变慢。bufferbloat.net 也提到，缓冲区塞满之后，丢包会急剧增加。
4. 测试地址不是你要访问的网站
测试地址只有一个，而你每天访问的是各种网站、各种视频 CDN。节点到测试地址很顺，不代表到你想看的那家服务也顺——线路走法、对方是否限制某类出口 IP，都可能不同。这也是前面我们写过流媒体解锁时强调的：同一个节点，时灵时不灵很正常。
5. TCP 本身的脾气：延迟越高、越难跑满
CellStream 的一篇文章（作者观点类文章，非严谨实验）讨论过 TCP 的几个特点：连接刚建立时有“慢启动”，要逐步把速度爬上去；发生重传会拉低有效吞吐；延迟越高，爬升越慢。放到代理场景里就是：一条线路绕得远、延迟偏高，哪怕没满载，单个下载也很难跑满。这是传输层的通用规律，不是某个机场独有的毛病。
6. 问题可能在你这边：本地网络、客户端设置或规则
你家 Wi-Fi 信号差、手机电脑同时在下大文件、客户端开了不合适的模式或规则，都会让“节点看起来很快，用起来很慢”。比如应该直连的国内网站被绕去走了代理，就会平白变慢。这块可以参考我们另一篇关于Clash 规则模式和全局模式区别的文章。
三、一张表看懂：几个指标分别说明什么
| 指标 | 大白话 | 影响什么 | 客户端里常见的看法 |
|---|---|---|---|
| 延迟（Ping/URL Test） | 喊一声多久有回应 | 网页打开的“起步”速度、游戏响应 | 节点列表里的毫秒数 |
| 带宽/下载速度 | 水管有多粗 | 看视频、下载大文件 | 需要单独测速或实际下载 |
| 丢包率 | 十次里丢几次 | 卡顿、重传、游戏掉线 | 多数客户端不直接显示 |
| 抖动 | 每次回应的时间稳不稳 | 语音、视频会议、游戏 | 需要连续多次测试才能看出 |
| 负载下延迟 | 下载时延迟涨多少 | 多人共用、边下边看时的卡顿 | 基本需要自己对比 |
四、5 步自查：到底是节点、机场还是你自己的问题
- 先看直连。关掉代理，直接访问同一个网站或视频。直连也卡，问题在你的本地网络（路由器、运营商），跟节点无关。
- 换一个节点对比。同一时间点、同一个网站，换另一个地区的节点试一下。只有这个节点卡，就是线路或出口的问题；所有节点都卡，更可能是你本地或机场整体拥塞。
- 错开时间再试。白天、晚高峰各试一次。只有晚上卡，多半是拥塞，可以对照我们的节点延迟高怎么办一文做排查。
- 用“负载下”的方式测。别只看列表里的毫秒数：边下载一个大文件，边观察延迟有没有明显上涨。涨得厉害，就是前面说的缓冲膨胀或线路拥塞。
- 检查客户端设置。确认模式（规则/全局）、分流规则、是否开了 TUN、测试地址和测试间隔是否被改动。不同客户端各有特点，选择思路可以看Clash 客户端怎么选。
如果你是为了打游戏，还要多看一层 UDP 支持、抖动和分流规则，这块我们在打游戏用什么机场延迟低里单独讲过。
五、买机场前，怎么别被“低延迟”四个字忽悠
不少宣传页喜欢强调“延迟低至几十毫秒”。看到这种话，建议你心里默默补一句：是空闲时的单次延迟，还是负载下的稳定表现？买之前可以做这几件事：
- 看有没有明确的试用期或退款规则，试用时在早、中、晚三个时段各用一次；
- 搞清楚套餐写的是“线路类型”还是真实表现，线路标签的含义可以看我们的IEPL、IPLC 是什么意思；
- 别只看别人晒的测速截图，截图只能反映那一刻、那个地点、那条网络；
- 先小额、短周期付费，避免一次性预付过长时间。
另外提醒两点：使用此类工具请遵守你所在地的法律法规；订阅链接等同于你的“账号钥匙”，不要随意发给他人或贴到公开页面，也要留意机场是否保留日志、是否稳定经营。
常见问题（FAQ）
节点延迟显示超时，但网页其实能打开，正常吗？
可能正常。延迟测试有超时时间限制（Mihomo 里是 timeout 字段），而且测试地址和你访问的网站不是同一个。单次超时不一定代表节点坏了，多测几次、换个时间再看。
延迟 30ms 的节点一定比 100ms 的好用吗？
不一定。延迟低对打游戏、刷网页有帮助，但看视频、下载更看带宽和丢包。一个延迟高点却稳定、不丢包的节点，实际体验可能更好。
自动选择（url-test）会不会选错节点？
会有这种可能。它依据的是前面那个测试地址的结果，并且按设定的间隔（sing-box 默认 3 分钟）更新，还有容差设置，延迟差距不超过容差时不会来回切换。它选出来的是“测试时最快”的，不一定是“你现在看视频最稳”的。
测速一直很高，但用的时候很慢，能找机场退款吗？
这取决于机场自己写明的退款条款，我们没法替你判断。建议先按上面的 5 步自查，保留好对比结果，再去看你购买时的条款说明。
我能不能自己改测试地址和间隔？
多数 Clash 系和 sing-box 系客户端的配置里都能改，对应文档里的 url 和 interval。但测得更勤会多消耗一点流量和资源，也未必让体验变好，一般保持默认就行。
总结
客户端里的延迟，是“单次小请求”的结果，说明不了带宽、丢包、抖动和高峰期表现。遇到“延迟很低却很卡”，别急着骂机场，也别急着换，先做 5 步自查：看直连、换节点、错峰、在负载下观察、查客户端设置。买之前则要追问“低延迟”到底是什么条件下测的。
参考来源：sing-box 官方文档：URLTest；Mihomo 文档：Proxy Groups；v2rayN Wiki：界面说明；Bufferbloat.net：Introduction；Cloudflare：What is latency；CellStream：Why TCP Should Never be Used for Speed Tests（观点文章）；pong.com 博客（厂商博客，仅作参考）。以上资料查阅于 2026 年 10 月，文档默认值可能随版本变化，请以你所用客户端的最新文档为准。