节点测速原理深度解析：延迟、丢包率、单/多线程吞吐与真实体验关系完全解密

不是传统意义上的 ICMP Ping。由于很多现代企业级中转服务器出于安全考虑会直接禁用 ICMP 回显协议，客户端（如 Clash / v2rayN）采用的是「TCP 握手延迟测试」或「HTTP 存活探测（URL-Test）」。它是客户端通过代理通道，向目标网站（如 generate_204 探针）发起一次完整的 HTTP GET 请求并收到响应的真实往返时间（RTT）。由于包含了 TLS 握手与代理内核的转发处理耗时，这个数值通常比纯网络层 Ping 值大 20ms~50ms，但它更真实地反映了建立连接的响应速度。

高延迟只会让你的请求“晚一点开始”，例如点击网页后多等 0.1 秒，但一旦连接建立，数据流依然可以全速传输；而丢包率会导致 TCP 协议触发严重的拥塞控制惩罚。当 TCP 检测到数据包丢失时，会强制进行超时重传（Retransmission），并将当前的传输窗口（CWND）直接削减一半甚至重置为 1。因此哪怕延迟只有 20ms，只要丢包率达到 5%，视频就会出现规律性的大面积卡顿转圈；而一条延迟 150ms 但丢包率为 0% 的美国专线，看 4K 反而丝滑无比。

多线程测速（Multi-connection）是测速软件同时建立十几个或几十个连接并发拉取数据，测试的是节点所能达到的极限总带宽，适合评测大文件多任务下载；单线程测速（Single-connection）则仅使用一条 TCP 连接进行数据传输。在日常看 YouTube、Netflix 等流媒体时，播放器为了降低资源消耗通常仅使用单线程拉取切片视频，因此「单线程下载速度」才是决定 4K/8K 视频是否卡顿的核心指标。单线程能稳定跑满 50Mbps 的节点，体验远好于多线程虚高但单线程萎靡的节点。

这通常是「DNS 解析延迟」或「TLS 证书握手链过长」导致的。虽然代理服务器本身的物理网络延迟很低，但如果客户端配置的远程 DNS 查询响应慢，或者域名解析遭遇了上游反复递归查询，浏览器就必须先花费 1~2 秒等待域名解析完毕，才能开始向代理服务器发送连接请求。开启客户端内置的 Fake-IP 模式或 TUN 模式，可以直接由本地内核秒级伪造 DNS 响应，彻底消除白屏等待感。

传统 TCP 拥塞控制算法（如 Reno、Cubic）以“是否发生丢包”作为降速判断标准，这在远距离跨洋公网上非常脆弱；而 Google 开发的 BBR（Bottleneck Bandwidth and RTT）算法转为以“物理信道最大带宽与最小往返延迟”为建模核心，不再将轻微丢包误判为网络拥塞。服务端部署 BBR 后，跨洋连接即使面对 5%~10% 的轻度丢包，依然能够保持激进的发送速率，这也是现代专线和优质中转节点速度飙升的技术基石。

测速跑图通常只持续 5 到 10 秒的瞬间打流，能够掩盖很多潜在缺陷；而在持续使用中，劣质节点可能存在「内存泄漏」、「连接数耗尽」或「周期性心跳探测被干扰」等问题。此外，测速使用的是标准的 HTTP/TCP 流量，如果节点对 UDP 支持不良，游戏和语音就会立即断连。因此测速跑图只能作为基准参考，长期的 SLA 在线率和真实用户体验才是终极标准。

不同客户端默认的测试地址和测试方式不同，有的只测建立连接，有的要等目标网站返回内容。比较节点时，要在同一个客户端、同一个测试地址下比。

延迟是一次请求来回的时间，抖动是多次测量之间延迟变化的幅度。平均延迟不高但抖动大，游戏和视频通话仍然会忽卡忽好。