搜索 K
Appearance
AirPick 实验室 · 跨境链路诊断组 · 2026 年 3 月修订版
白天 4K 秒开、晚上 480p 转圈,这种「潮汐式降速」大概率不是你的节点坏了,也不是机场跑路了,而是同一根国际出口路由在 20:00 之后被几百万个并发连接挤爆了。
三条核心结论:
下面按「物理机理 → 量化矩阵 → 选型 → 实操 → 排障 → 避坑」的顺序逐层展开。
中国大陆的国际互联网出口是总量受限资源。公开的骨干互联数据显示,全国国际出口总带宽长期停留在「数十 Tbps 量级��,而晚高峰时段的跨境并发需求会达到日间均值的 3-5 倍。更关键的是:这几十 Tbps 里,真正能低延迟直连北美/欧洲的比例还要再打个折,因为大量带宽被用于东南亚、日韩等近距离方向。
物理层面,一条中美国际海缆(如跨太平洋光缆系统)的设计容量通常是十几到几十 Tbps,但实际承载的是多国共享。当欧洲、东南亚的流量因为自身故障或路由策略回退到同一条海缆时,你所在的那条 TCP 连接就被动分摊到了更少的可用切片。
这是「晚高峰 QoS 限速原理」的核心。运营商在省网出口和骨干互联点普遍部署两类策略:
(1)CAR + 令牌桶(Token Bucket)整形
令牌桶按固定速率(比如 10 Mbps)往桶里放令牌,每个数据包消耗一个令牌。桶深(Burst Size)通常只有几百 KB 到 2MB。这意味着:
这就解释了为什么测速软件经常能跑出很高分数,但实际看视频仍卡——测速只跑了 10 秒,还没触及令牌桶的天花板;而看一部两小时的电影,第 30 秒就被打回原形。
(2)WRED / RED 主动队列丢弃
出口队列满了以后,路由器不会等缓冲区彻底撑爆,而是按概率提前丢弃一部分包。被丢弃的包在 TCP 层触发重传,重传又加重拥塞,形成正反馈。这就是为什么你看到的丢包率会从 0% 直接跳到 20%-30%,而不是平滑上升。
公网国际路由由 BGP 对等互联(Peering)与转接(Transit)决定。晚高峰时,便宜的 Peering 链路先被塞满,BGP 会自动切换到更贵的 Transit 或更绕的路径。
典型表现:一条本该「上海 → 洛杉矶 → 落地」的 12 跳路径,晚高峰变成「上海 → 香港 → 新加坡 → 洛杉矶 → 纽约 → 洛杉矶 → 落地」的 20+ 跳。RTT 从 150ms 暴涨到 320ms,且每一跳都增加一次丢包概率。
识别方法:用 mtr 看 AS 号(Autonomous System Number)跳变。正常跨境路径的 AS 跳变通常在 6-9 个自治域内;若超过 12 个自治域,基本可以确认存在绕路。
IPLC(International Private Leased Circuit)和 IEPL(International Ethernet Private Line)是物理/二层专线,流量完全绕开公网 BGP 和运营商 QoS 策略。
关键差异:专线的队列调度在运营商内网完成,不与公网流量争抢。你的 100 Mbps 就是 100 Mbps,晚高峰不会掉到 3 Mbps。
代价是成本:一条中港 IEPL 专线的月成本是同等公网中转带宽的 20-50 倍。所以正规专线机场的定价通常不会低到离谱——如果某家标称「全 IPLC 专线」但月付只要 5 块钱,那它八成是公网中转伪装。
TCP 的拥塞控制算法决定了「丢包之后降多少、恢复多快」。
cwnd 乘以 0.7,恢复靠时间函数缓慢爬升。在 10% 丢包的链路上,CUBIC 的有效吞吐可能只剩理论值的 5%。这就是为什么 2026 年主流优质机场的服务端普遍启用了 BBRv3 或自研的拥塞控制优化。这不是玄学,是实打实的数学差异。
跨境链路的 QoS 策略部分依赖流量特征识别。传统的 VMess/Trojan 流量在深度包检测(DPI)下有一定特征暴露风险,可能被额外降级。
2026 年主流方案是 TLS Reality(借用真实网站的证书握手)配合 uTLS 指纹伪装(模拟 Chrome/Firefox 的 ClientHello),让代理流量在握手阶段与正常 HTTPS 无法区分。这对规避「针对性 QoS 降级」有实际意义,但它无法解决物理带宽拥塞——专线和公网的差距仍然存在。
把 20:00-23:00 拆成四个阶段,你会看到拥堵是「叠加」而非「突现」的:
| 时间窗 | 链路状态 | 典型丢包率 | 用户感知 |
|---|---|---|---|
| 19:30-20:00 | 城域网出口队列开始积压 | 0.5% - 2% | 网页加载稍慢 |
| 20:00-21:00 | 骨干互联点接近满载,BGP 开始漂移 | 3% - 8% | 1080p 频繁缓冲 |
| 21:00-22:30 | 海缆切片争抢最激烈 + QoS 令牌桶全面生效 | 10% - 30% | 掉到 480p / 720p |
| 22:30-23:30 | 流量回落,队列排空,BGP 回归 | 2% - 5% | 逐步恢复 |
注意:你所在的地区、ISP、落地机房三者叠加,会让这个曲线前后平移 30-60 分钟。南方电信用户通常在 20:15 就感受到明显劣化,而联通用户在 21:00 之后才开始。
这是 AirPick 实验室长期采集的跨境链路典型值,供你对照自查:
| 指标 | 白天平峰 (10:00-17:00) | 晚高峰 (20:30-23:00) | 恶化倍数 | 判定阈值 |
|---|---|---|---|---|
| 端到端丢包率 | 0% - 0.3% | 5% - 30% | 50x+ | > 2% 即影响体验 |
| 往返时延 RTT(中→美西) | 140 - 165 ms | 180 - 320 ms | 1.5 - 2x | > 250 ms 视频卡顿 |
| 抖动 Jitter | 5 ms 以内 | 30 - 120 ms | 10x+ | > 30 ms 语音破裂 |
| TCP 重传率 | 0.1% 以内 | 8% - 25% | 100x | > 3% 明显降速 |
| 单线程有效带宽 | 80 - 200 Mbps | 2 - 15 Mbps | 10 - 40x | < 10 Mbps 只能标清 |
| HTTP 首字节 TTFB | 180 - 350 ms | 800 - 3000 ms | 5 - 10x | > 1 s 感知明显 |
| BGP 跳数 / AS 跳变 | 8-12 跳 / 6-9 AS | 14-22 跳 / 10-14 AS | 1.5x | > 16 跳 警惕绕路 |
| 单流 QoS 令牌桶速率 | 通常不限速 | 限 5 - 20 Mbps | — | 单流骤降即命中 |
| 峰值/谷值带宽比 | — | — | 20 - 50x | > 10x 判定公网拥堵 |
| 多线程并发达标率 | 90% - 100% | 15% - 45% | — | < 50% 疑似超售 |
这张表怎么用:如果你晚高峰测出来的数据符合「单线程崩、多线程也崩、跳数暴增」,那大概率是公网拥堵;如果符合「单线程崩、多线程能跑满」,那就是运营商 QoS 单流限速;如果「多线程只有标称值的 20%」且白天也跑不满,那是机场侧超售。
| 人群 / 场景 | 核心痛点 | 链路建议 | 配置要点 |
|---|---|---|---|
| 4K/8K 流媒体重度用户 | 晚高峰带宽塌��� | IEPL/IPLC 专线 + 大带宽落地 | 单节点 ≥ 500 Mbps,启用多路复用 |
| 跨境远程办公 / 会议 | 抖动与丢包导致音画不同步 | 低抖动专线,优先日/新/港节点 | 走 UDP 优先协议,开启 FEC |
| ChatGPT / Claude 重度使用者 | 首字节延迟与连接重置 | 原生 IP + 稳定落地 | 关闭 IPv6 泄漏,固定出口 IP |
| 游戏加速 | 延迟抖动 | 近距离境外节点(港/日/韩) | 启用 UDP 转发,禁用 TCP 多路复用 |
| 大文件下载 / 备份 | 长时间满速触发令牌桶 | 专线 + 多线程分片 | 8-16 并发连接,避开 20:00-23:00 |
| 移动端随时用 | 网络频繁切换 | 支持多协议回退的订阅 | 开启自动选路与快速重连 |
一句话总结:晚高峰焦虑的本质是「带宽确定性」问题。公网中转给不了确定性,只有专线能给。
sniffer 中的 force-dns-mapping(会引入额外解析延迟)。profile 中把 tcp-concurrent: true 打开,提升多线程并发能力。unified-delay,它在高丢包链路上会误判最优节点。Proxy Group 建议按「地区 + 用途」双维度分组,例如 US-Streaming、JP-Game。TLS 1.3 与 Hybrid 拥塞控制(部分版本支持)。REJECT-DROP 用错会让某些 App 无限重试,反而加剧流量消耗。sing-box 内核,对 BBR 与多路复用支持更好。UDP Relay 打开,QUIC 流量才不会被打回 TCP。TUN Only 模式,避免 HTTP 代理模式下的连接复用问题。FullCone NAT,游戏与 P2P 场景收益明显。Turbo ACC 中的 BBR 加速模块,能显著改善高丢包下的吞吐。以下命令请在本地终端运行,用于定位丢包发生的具体位置。
# 100 个包,显示 AS 号,报告模式输出
mtr -rwzbc 100 1.1.1.1怎么看:
# 探测 443 端口的 TCP 建连时延
tcping -t 5 -p 443 your-node.example.comICMP 经常被运营商限速,tcping 走 TCP SYN,更能反映真实体验。
curl -o /dev/null -s -w "dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n" https://www.google.comconnect 高 → 路由绕远或丢包严重tls 高 → 握手被干扰或证书链验证慢ttfb 高但 connect 正常 → 服务端或落地带宽问题# Linux 查看当前连接的重