延迟 80ms 的节点下载速度可能不如延迟 180ms 的节点。原因在于它们测的根本不是同一件事。
节点延迟为什么不能代表实际下载速度
一个常见的场景：你在客户端里测速，节点 A 显示 80ms，节点 B 显示 180ms。你选了 A，结果下载速度还不如 B。
这不是测试出错，也不是节点标错了。延迟和速度本来就是两个不同的指标。
一个类比
把网络想象成一条公路：
- 延迟 相当于一辆车从起点开到终点需要多久
- 带宽 相当于这条路有几车道，单位时间能通过多少辆车
一条限速很高但只有一车道的路，单车通过很快（延迟低），但车流量上不去（带宽小）。一条限速普通但有八车道的路，单车慢一点，总运力却大得多。
延迟测试测的是第一件事，下载速度取决于第二件事。
严格一点的定义
延迟（Latency / RTT）
一个数据包从你的设备到目标再返回所需的时间，单位毫秒。它主要由物理距离和中间跳数决定。
带宽（Bandwidth）
单位时间内能传输的数据量，单位 Mbps。它由链路容量和当前拥塞程度决定。
丢包率（Packet Loss）
传输过程中丢失的数据包比例。丢包会触发重传，严重影响实际吞吐量。
三者相互独立。一个节点可以延迟低但带宽小，也可以延迟高但带宽大。
丢包是被忽略的关键变量
延迟和带宽之外，丢包对实际速度的影响往往最大。
原因在于 TCP 的拥塞控制机制：它把丢包解读为"网络拥塞"的信号，一旦检测到丢包就会主动降低发送速率。
这导致一个反直觉的结果：一条延迟 80ms 但丢包 5% 的链路，实际吞吐量可能远低于延迟 200ms 但零丢包的链路。
而客户端的延迟测试通常只发几个探测包，很难反映真实的丢包情况。
各自影响什么
| 场景 | 主要受什么影响 |
|---|---|
| 网页首屏打开速度 | 延迟 |
| 视频通话的同步感 | 延迟、抖动 |
| 游戏操作手感 | 延迟、丢包 |
| 大文件下载 | 带宽、丢包 |
| 高清视频流畅度 | 带宽 |
| 网页整体加载 | 延迟 + 带宽（多个请求并发） |
所以"哪个节点更好"这个问题本身就不完整。取决于你要做什么。
- 主要是浏览网页 → 延迟更重要
- 主要是下载和看视频 → 带宽更重要
- 视频会议 → 延迟和稳定性都重要
为什么延迟数字仍然有用
虽然它不代表速度，但延迟测试也不是没有价值：
它能判断节点是否可达。 超时说明连不上，这是有用的信息。
它反映物理距离量级。 几十毫秒通常是同区域，两三百毫秒通常是跨洋。这能帮你确认节点位置是否符合标注。
它对交互类场景有直接意义。 网页首屏、实时通话确实受延迟影响。
只是不要用它来判断"下载会不会快"。
怎么判断实际速度
唯一可靠的方法是实测
用你实际会做的事情去测：下载一个你常用的文件、播放一段你常看的视频、打开你常访问的网站。
注意：
- 测速会消耗账号流量，不要频繁做
- 单次结果的参考价值有限，不同时段测几次看趋势
- 测试时关闭其他占用带宽的程序
一个实际的选择顺序
- 1. 先按目标位置选区域这比任何数字都重要，见节点地区与使用场景说明。
- 2. 在该区域内看延迟排除掉明显异常的（超时、延迟异常高的）。
- 3. 在剩下的候选里实测用你实际的使用场景测试。
- 4. 记住结果，不用天天换找到一个够用的就固定下来，除非它出问题。
注意事项
- 客户端的延迟测试会消耗少量流量，批量测速的消耗更明显。
- 速度会随时段、区域和线路状况波动，单次测试不代表长期表现。
- 本站不提供任何节点测速数据或性能排名，这类数据无法核实且很快过时。
常见问题
延迟 300ms 是不是太高了？
跨洋连接的物理延迟本身就在这个量级。北美方向 150–250ms 属于正常范围。这是光速和距离决定的，不是节点质量问题。
为什么同一个节点延迟忽高忽低？
网络状况在变，中间链路的负载也在变。小幅波动正常，剧烈波动可能意味着链路不稳定。
测速显示很快但实际用起来慢？
测速服务器和你实际访问的目标不是同一个。速度是端到端的，测速只覆盖了到测速服务器那条路径。
为什么白天快晚上慢？
晚间是使用高峰，共享链路拥塞更明显。这是普遍现象，见速度慢与延迟高的排查方法。
有没有一个"综合最优"的节点？
没有普适答案。同一个节点在不同地区、运营商、时段的表现差异很大，见为什么同一个节点在不同地区表现不同。