机场节点延迟多少算正常？各地区参考区间、影响因素与降低延迟的方法
判断延迟高不高，不能只看一个数字，要看它相对于「这个地区的物理下限」高了多少。香港 80 ms 是明显偏高，美西 160 ms 却完全正常。
判断一个节点的延迟是否正常，不能只看数字大小，要看它比这个地区的物理下限高了多少。国内连香港的理论极限大约 10 ms 出头，所以 80 ms 明显偏高；而国内连美国西海岸的物理下限就在 110 ms 左右，160 ms 属于完全正常。
下面先给参考区间，再解释这个数字是怎么来的、被什么拖高、以及能怎么压下去。
各地区节点延迟的参考区间
以下是国内家庭宽带（有线接入、非晚高峰）连接各地区节点的常见延迟范围，单位毫秒。同一地区按线路质量分三档：
| 节点地区 | 专线 / 优质回程 | 优质中转 | 普通直连 | 物理下限约 |
|---|---|---|---|---|
| 香港 | 10–30 | 30–60 | 60–130 | 10 |
| 台湾 | 15–40 | 40–70 | 70–140 | 15 |
| 日本 | 30–55 | 55–90 | 90–170 | 28 |
| 韩国 | 30–55 | 50–90 | 90–160 | 25 |
| 新加坡 | 40–70 | 60–100 | 100–190 | 38 |
| 马来西亚 / 菲律宾 | 45–80 | 70–110 | 110–200 | 42 |
| 美国西海岸 | 120–160 | 150–200 | 200–320 | 110 |
| 美国东海岸 | 180–220 | 210–280 | 280–400 | 165 |
| 英国 / 德国 | 180–250 | 240–320 | 320–450 | 160 |
| 澳大利亚 | 110–150 | 140–200 | 200–320 | 100 |
使用这张表时注意三点：
- 数值随你所在省份浮动。华南用户连港台会比华北用户低 10–20 ms，东北和西北用户普遍再高 10–30 ms。
- 落在「普通直连」列不代表节点坏了，只说明这条线路没有做过优化，晚高峰会更难受。
- 超出最右列上限通常意味着路由绕行（例如连日本却绕经美国）或节点严重超载，值得换节点。
客户端显示的延迟到底测的是什么？
这是最容易产生误解的地方。主流客户端有两种测法：
- ICMP Ping：直接 ping 节点服务器 IP，只反映你到节点入口的往返时间，不包含节点到目标网站那一段。数字最低，参考价值有限。
- 真连接延迟（URL Test / HTTP 延迟）：客户端通过节点对一个测试地址（常见的是
gstatic.com/generate_204或cp.cloudflare.com）发起一次完整请求并计时。它包含 TCP 握手、TLS 握手和落地到目标的距离，所以比 ICMP 高，但更接近真实体验。
所以看到「Clash 里 120 ms，命令行 ping 只有 45 ms」不用奇怪，两者本来就不该相等。横向比较节点时，务必统一测试方式和测试地址，否则数据没有可比性。
另外提醒一点：如果测试地址选的是国内无法直接访问的域名，而你的规则又把这次探测放行到直连，就会出现全部节点 Timeout 的假象。
哪些因素会把延迟拉高？
物理距离与路由绕行
距离是硬底线，但绕行更常见也更隐蔽。一条标称「日本」的线路，如果落地机房的回程要先到美国再回国内，延迟能从 60 ms 变成 250 ms。用 traceroute 或 mtr 看中间跳的城市代码（如 lax、sjc）就能发现绕路。
国际出口拥塞
这是晚高峰延迟翻倍的直接原因，属于运营商侧的排队问题。不同线路等级的抗压能力差别很大，具体对照可以看 CN2、CMI、中转、直连是什么意思。
中转的额外跳数
中转节点把路径拆成「你→国内入口→落地」，多出一次转发和一次加解密，通常增加 5–20 ms。如果机场做了链式中转（两跳甚至三跳），叠加会更明显。用不到中转的场景就不要开。
本地接入质量
经常被忽略但影响很大：
- Wi-Fi 2.4 GHz 频段拥挤时额外增加 20–80 ms 抖动，换 5 GHz 或有线可立刻改善。
- 家用路由器开启 QoS、IPv6 隧道、旁路由二次转发，都会叠加延迟。
- 蜂窝网络本身基础延迟就比宽带高 20–50 ms。
节点负载与超售
同一个节点被几百人同时使用时，服务器 CPU 处理加解密会排队，表现为延迟上升且抖动加剧。节点列表里那些「延迟很低但一用就卡」的，多半是这个原因。
客户端与系统配置
TUN 模式下的路由处理、MTU 设置不当导致的分片、DNS 解析走了慢路径，都会让首字节时间变长，感受上像是延迟高。这类问题的完整排查流程见 代理延迟过高怎么排查。
比平均延迟更重要的两个指标
抖动（Jitter）
延迟的波动幅度。判断标准可以简单一点：抖动超过平均延迟的 20% 就算不稳。一个「平均 50 ms、抖动 5 ms」的节点，比「平均 40 ms、抖动 60 ms」的节点好用得多，尤其是视频会议和游戏。
丢包率
| 丢包率 | 体感 |
|---|---|
| < 0.5% | 感觉不到 |
| 0.5%–2% | 网页偶尔卡一下，游戏轻微回弹 |
| 2%–5% | 视频降画质，SSH 顿挫，语音断续 |
| > 5% | 基本不可用 |
丢包和延迟往往同时恶化，因为两者的成因都是队列拥塞。
怎么降低节点延迟？按优先级排列
- 换更近的地区。收益最大的一步。日常浏览把默认节点从美国换成香港、台湾，延迟能直接砍掉三分之二。哪个地区适合哪种用途，见 机场节点怎么选。
- 换线路等级。同一地区内优先挑标注了 GIA、9929、CMIN2、IEPL 的节点，晚高峰差距最明显。
- 改用有线接入。把笔记本插网线、或者至少切到 5 GHz，很多人能立刻少 20–40 ms 抖动。
- 减少转发层数。关掉链式代理、旁路由二次转发、以及不必要的全局模式，让流量路径尽量短。
- 换协议应对丢包。线路丢包高时，Hysteria2、TUIC 这类基于 UDP 的协议体感提升明显；丢包本来就低时换协议没有意义。
- 调整 MTU。频繁出现大文件传输卡死但小请求正常，多半是 MTU 过大导致分片，逐步下调到 1400 左右测试。
- 避开晚高峰。大文件下载、镜像拉取这类不着急的任务放到深夜，既快也不占用高峰带宽。
什么时候该判定「这个节点不正常」？
同时满足以下任意两条，就可以考虑换节点或换机场：
- 延迟持续高于上表对应地区「普通直连」列的上限。
- 抖动长期超过平均延迟的 30%。
- 非晚高峰时段丢包仍高于 2%。
- traceroute 显示明显绕行到与目标地区无关的第三国。
- 白天正常、晚高峰延迟翻三倍以上，且连续多天如此。
单次测试不作数，至少在两个不同时段各测一轮。