ping -i 0.01有人卖一条隧道：哪怕用快速洪水 ping 打，丢包也是 0，而底下那条明显拥塞的链路丢着 15%。这不是「线路干净」，而是 一个可靠传输层在偷偷把链路扔掉的包补回来 —— 而你只要十分钟就能验证它到底是哪一种。
这条 trace 走某 Tier-1 国际骨干网（伦敦 → 阿姆斯特丹 → 法兰克福），最后落到 境内运营商·上海。表里有两行标红 —— 但只有一行是真丢包。
丢包和抖动同时出现，又恰好卡在峰值时段的拥塞互联点。这是隧道必须面对的那部分丢包。
不往后传递的丢包，是路由器在保护自己的控制面。端到端的真实流量照样通过。
这类 QUIC 系隧道协议的官方文档自己就讲得很直白：
那 15% 还在链路上照丢。被包装成 隧道内不丢包 的，其实是隧道的可靠传输层坐在链路之上，在你的内层流看到缺口之前就把每个丢掉的包补好。三层叠在一起 —— 只有最底下那层真的在丢东西：
那第②层是怎么把缺口补得够快，连 ping -c100 -i 0.01 都察觉不到的？两种机制 —— 一个个看。
QUIC 的可靠流（如 Hysteria2、TUIC）给每个包编号。丢一个，接收端发现缺口、再要一次。你的内层 ping 只是多等了几毫秒 —— 然后报告 0% 丢包。代价不是丢包，而是延迟尾部的一根尖刺。
只有真丢的包才重发。链路大体良好时很省。
每次恢复 = 多一个往返。丢包读数是 0%，但 ping 的 max/抖动会跳。这就是认出 ARQ 的方法。
kcptun、UDPspeeder、Hysteria v1 会在数据旁边多发冗余包（比如 8 个数据 + 3 个冗余）。丢掉几个，接收端直接用冗余把它们重建出来 —— 完全不需要往返。延迟平滑，但要付一笔固定的带宽税；而且一旦丢包超过你预留的冗余量，它就崩。
这里最容易被话术带偏。Hysteria 的 Brutal 和 Linux 的 BBR 是拥塞控制算法，它们不把丢包当成「慢下来」的信号。普通 TCP（CUBIC/Reno）每丢一次就砍速 30–50%，在 15% 丢包的链路上直接崩。Brutal/BBR 则照推不误 —— 所以隧道仍然快。
把丢包当拥塞，使劲退避。15% 丢包下基本爬行。这是「之前」。
不把丢包当信号，硬撑速率。快 —— 但包还是在丢。15% 已经超过 BBR 约 2% 的舒适区；它在劣化，不是免疫。
关键：拥塞控制是发送端的速率控制。它能在丢包下保住你的速度，但单凭它做不到让 ping 读数变成 0%。如果卖家把「不丢包」归功于 BBR，那正说明他把快和不丢混为一谈了。
前面每种机制都是把丢包藏起来。只有一个选项能让底层链路真的干净：一条专用 IPLC / CN2-GIA 专线，它干脆不走那个拥塞的国际互联点。这时候 隧道内不丢包 才是字面意义上的真 —— 没有什么需要恢复，因为根本没丢。
预留的专用带宽，不和公网骨干抢路。这才是真正值得花钱的那部分 —— 也是最该重点验证的一条声明。
同一个包走两条路各发一份，对端去重（如 ZeroTier「broadcast」模式）。能抗丢包、零延迟代价 —— 但零吞吐增益。纯粹拿带宽换可靠。
光看丢包率分不出来 —— 它们都显示 0%。延迟尾部和一次双向 MTR 对比才会露馅：
| 机制 | 丢包率 | 延迟特征 | 本质是 |
|---|---|---|---|
| ARQ 重传 | 0% | 尾部发尖 —— 每次恢复 max/抖动跳一下 | 藏丢包 |
| FEC 冗余 | 0% | 平滑 —— 但多 ~15–30% 带宽开销 | 藏丢包 |
| Brutal / BBR | 仍在丢 | 快，但丢包持续存在 | 只是快 |
| 专用 IPLC 专线 | 0% | 平滑，而且裸链路本身也干净 | 真的干净 |
ping -c1000 -i 0.01 穿隧道，看 max/mdev。平滑 = FEC/专线；发尖 = ARQ。ping -i 0.01 显示真实丢包丢包没消失，只是不再是你的问题了。