低延迟机场：把"快"拆成可测的三个数字
直接答案：低延迟不是套餐属性，是你的位置、线路路径、时段三者的函数——任何"低延迟机场"标注都替代不了实测。方法很短：圈定近距离地区节点，建连耗时、握手耗时、晚高峰这三个数字各测一轮，十几分钟就能把营销词变成排序表。另外要直说的一点：实时对战游戏不是机场的强项，竞技场景建议专门的游戏加速器。
先分清：延迟、带宽、丢包各管什么
- 延迟（毫秒）：一来一回的时间，决定操作响应——远程桌面、SSH、游戏看它；
- 带宽（Mbps）：单位时间的传输量，决定下载与视频清晰度；
- 丢包/抖动：稳定性指标，决定会不会卡——它对体验的破坏大于高延迟，因为丢包触发重传和断流。
"测速很快但用着卡"的谜底通常在第三项：测速软件的多线程大流量掩盖了丢包，实时应用的小包交互却被它反复打断。原理详见延迟与速度的区别。
地区延迟量级参考
从中国大陆出发的物理量级（非承诺值，用于识别异常）：
| 地区 | 合理量级 | 显著偏高说明 |
|---|---|---|
| 香港 / 台湾 | 数十 ms 内 | 线路绕路（如经美国折返）或拥塞 |
| 日本 / 新加坡 | 50–100 ms | 同上 |
| 美国西岸 | ~150 ms | 物理下限即较高，绕路更甚 |
| 欧洲 | 200 ms+ | 对延迟敏感场景不适用 |
同地区多节点的耗时差异往往比跨地区还大——选地区只是第一步，选节点靠实测。
三个数字的测法
建连耗时（对应延迟的第一层）：
connproof tcp 节点域名 --port 节点端口握手耗时（叠加了线路往返次数，绕路会成倍放大）：
connproof tls 节点域名 --port 443 --verbose晚高峰对照：同两条命令在工作日 21 点重测。耗时翻倍以上或出现超时（对照 TCP-001），该节点的"低延迟"只存在于闲时。线路类型（IPLC/中转/直连）对晚高峰表现的影响与自测特征见线路自测指南。
游戏场景的诚实说明
多数机场协议以 TCP 为承载，而实时对战的 UDP 流量在代理链路里要么被丢弃、要么被封装转发——两种情况的延迟与抖动都劣于专门优化 UDP 的游戏加速器。机场在游戏生态里的合理位置是：商店下载、账号登录、语音聊天；排位竞技请交给加速器。这一段没有推广目的，纯粹为了让你把钱花对地方。
常见问题
低延迟机场推荐怎么选？
延迟由物理距离和线路质量决定，无法从套餐页看出。选法是圈定近距离地区（对多数用户是香港、日本）后，在试用或退款窗口内分时段实测建连与握手耗时，用数据挑节点。
机场延迟低就一定快吗？
不是。延迟决定响应快慢，带宽决定传输快慢，两者独立。打游戏和远程操作看延迟，下载和看视频看带宽与稳定性——先分清自己的场景要哪一个。
节点延迟多少算正常？
参考量级：香港台湾几十毫秒内、日本新加坡约五十到一百、美西一百五上下、欧洲两百以上。显著高于量级说明线路绕路或拥塞，同地区多节点对比能立刻看出异常。
为什么客户端测的延迟很低，用起来还是卡？
客户端延迟测试通常只测到入口服务器或只测一次握手，反映不了完整链路和持续表现。卡顿多来自丢包与抖动，需要分时段的多次实测才能暴露。
丢包率多少算正常？
稳定链路的丢包应接近零；持续百分之几的丢包对实时应用已是明显劣化。丢包比高延迟更伤体验——高延迟只是慢，丢包带来卡顿、重传和断流。
机场晚高峰为什么延迟变高？
跨境公网在晚间拥塞，排队与重传推高延迟和丢包。这是低价直连线路的结构性弱点，专线的价值正是把这段波动压平。晚高峰实测数据比任何白天的测速都有说服力。
游戏用机场还是加速器？
多数代理协议走 TCP 承载，实时对战类游戏的 UDP 流量要么不被转发要么被封装转发，延迟表现通常不如专门的游戏加速器。机场适合下载、登录、语音，竞技对局建议用加速器。
游戏应该选哪个地区节点？
选离游戏服务器近的，而不是离你近的：日服选日本、美服选美西。用建连耗时对比同地区多个节点，把稳定性最好的固定给游戏流量。
晚高峰稳定的机场怎么找？
没有捷径，只有对照：候选节点在工作日下午和晚九点各测三轮，耗时翻倍以内且无超时的才算过关。本站的命令序列十分钟能完成一轮。
低延迟节点为什么倍率经常更高？
低延迟依赖更短的物理路径或专用链路，成本高于绕路的普通线路，服务商用倍率转嫁。是否值得看场景：远程操作和实时协作值得，批量下载不值得。
换了低延迟节点还是卡怎么办？
先定位卡在哪一层：本地 Wi-Fi 与运营商、代理链路、目标服务器。三次对照法十分钟分清责任，避免把本地网络问题误判成机场问题反复换服务。