同一个 3%，四种听感与手感：丢包为什么不能只看百分比

三档的曲线形状：为什么 3% 是感受的拐点

丢包对体验的影响不是线性的。1% 到 3% 之间感受陡变，3% 到 5% 之后反而不再有新的「类型」出现，只是频率变高。拐点位置由各场景的容错机制决定。

三档乘以四类场景：十二行主观感受

下表由三名记录者分别描述后取交集，只保留三人一致的描述。不一致的描述单独列在备注里，避免把个体差异当成普遍规律。

表 1 里最能说明问题的是语音那一列：1% 档只有一声短促杂音，3% 档变成每几分钟一声金属音。这两档之间的差异不是「更多次同样的声音」，而是从「可忽略」跨到「影响理解」，属于质变。

三列数据卡：三档丢包的处置判断

三张卡片把三档丢包对应的动作写清楚。判断的关键是先分清丢包发生在本地还是路径上，这一步决定后面所有动作是否有效。

• 可接受

  丢包 ≤ 1% · 回拉 ≤ 2.3 次/分

  1%

  多数人会把偶发回拉归因为操作失误。这一档不需要处置，继续压丢包的收益小于压抖动的收益。

• 需处置

  丢包 1%–3% · 回拉 2.3–6.8 次/分

  3%

  交火与对话都能感知到。先分清本地与路径：本地丢包先改无线，路径丢包才换线路，两类动作不能互换。

• 不可用

  丢包 > 5% · 回拉 > 11 次/分

  5%

  四类场景全部失效。此时换线路通常无效，因为 5% 的丢包多半来自本地链路故障或运营商侧问题。

三种容错机制：为什么同一个百分比在四个场景里表现不同

FPS 靠服务端回溯、语音靠插补、云游戏靠帧内插值、主机联机靠重发。四种机制的容错上限完全不同，这才是一个百分比在四个场景里表现迥异的根本原因。

服务端回溯：能补位置，补不了判定

FPS 的服务器会把命中判定回溯到你看到对手的时刻，回溯窗口通常 100–200 ms。丢包造成的输入缺失无法被回溯补偿，因为服务器手上根本没有那段输入。实测 3% 丢包时，每次交火仍有 1–2 次回拉，回溯窗口再宽也救不回。

插补：20 ms 是可补与不可补的分界

Opus 的丢包隐藏用前帧频谱预测，20 ms 以内的缺口几乎听不出来。3% 丢包在语音里产生的是连续缺口，插补退化成噪声填充，听感就是那一声金属音。这也是语音场景对丢包最敏感的原因。

帧内插值：一帧花屏，恢复很快

云游戏的串流按帧解码，丢一个包通常影响一帧的一部分，客户端的帧内插值会在下一帧恢复。因此 1% 档只表现为偶发花屏，观感上比 FPS 的回拉更容易接受。但 5% 档时插值跟不上，画面会持续碎裂。

• 回溯的边界：只能补偿时间差，不能补偿缺失的数据。
• 插补的边界：20 ms 以内有效，超过后退化为噪声。
• 插值的边界：单帧单区域有效，连续丢包时失效。
• 重发的边界：每个丢包至少一个 RTT，92 ms 线路上代价翻倍。
• 共同点：四种机制都只能缓解，不能消除，消除只能靠降低丢包本身。
• 推断：某一档以上的丢包，任何场景都无法通过软件手段掩盖。

先分清本地丢包与路径丢包：两类问题的动作完全不同

这是整页最重要的一节。同样显示 3%，本地无线造成的丢包换任何节点都没用，而路径丢包换落地区域往往立竿见影。区分方法只需要三步。

1. ping 首跳地址 200 个包

   路由器或网关地址。首跳丢包非零，说明问题在 Wi-Fi、网线或光猫，属于本地丢包，后面不必再测。

2. ping 公网目标 200 个包

   首跳为 0 但公网目标丢包，说明问题在运营商或路径上，属于路径丢包，换落地区域有意义。

3. 换一台设备复测一次

   同一网络下另一台设备也丢包，排除本机网卡与驱动；只有一台丢包，先查该设备的网卡与 USB 网卡。

4. 再看时段分布

   只在 21:00 之后出现是出口拥塞，全天均匀出现更可能是线路质量或无线干扰。

5. 最后才动线路

   前三步都确认是路径丢包，再换落地区域。顺序反了会在错误的层面上调很久，实测里这类无效折腾占相当比例。

什么时候换节点有效，什么时候换也没用

丢包是所有场景里最容易误判的一项，因为它同时受本地、路径与服务器三处影响。下面六种情形按「换节点是否有效」分开写。

有效 · 路径丢包

首跳 0、公网目标 1%–3% 丢包时，换落地区域通常能把丢包压到 1% 以内，实测 HK-07 的 0.9% 换成 HK-03 的 0.3%。

有效 · 单节点故障

同区域另一个节点正常时，换邻居节点即可。10 月 16 日夜间 HK-07 出现过 4 分钟中断。

部分有效 · 出口拥塞

只在晚高峰出现的丢包，换落地区域能缓解但不能消除，因为拥塞在本地出口一侧。

无效 · 本地无线丢包

2.4 GHz 频段在承重墙与电梯间附近丢包 2–6%，换任何节点都被原样带过去。

无效 · 光猫或网线故障

首跳就丢包时，问题在物理层。实测里有 1.8% 的丢包来自一根老化网线。

无效 · 服务器侧丢包

同一局全员都出现丢包与瞬移时，是服务端或对端的问题，换线只会增加一次握手。

判定表：从读数直接跳到动作

下表把上面几节的判断压缩成六行，第一列是可以直接测到的读数，后面三列是由此推出的结论。用于十分钟内完成定位。

表 2 的第三列是最省时间的一列：看到「无效」就直接跳过换节点这一步，能避免一整晚的无效尝试。实测里六种情形中有三种换线无效，比例相当高。

为什么「换节点观察 30 分钟」是最后一行的写法

伴随大幅延迟跳变的丢包，可能是路由临时异常，也可能是节点故障。这类问题的特征是持续时间短、症状剧烈，换节点后需要观察一段时间才能确认是否真的恢复，而不是看一次读数就下结论。

三地实测的丢包分布：0.3% 与 2.1% 的差别在哪

下表是四类场景在两条代表性线路上的丢包读数。注意直连对照在四类场景里的丢包都比加速线路高一个量级，这是整站数据里最稳定的一条结论。

同样是 2.1% 丢包，在 FPS 里是「需处置」，在云游戏里已经接近「不可用」。这行差异来自容错机制的不同，也说明判断档位时必须带上场景，不能只报一个百分比。

三张补图：故障、拓扑与分层

补图把丢包的三种典型来源分开画：本地物理层、路径中段与链路分层。看懂形状之后，读数与图能对上号。

• 来源分布图：用于判断该先动本地还是动线路，占比最高的一项优先。
• 路径中段图：用于解释为什么换落地区域比换同城节点更有效。
• 分层图：用于划清责任边界，避免把物理层问题当成线路问题。
• 共用口径：三张图与表 1、表 3 共用同一批采样。
• 复查：丢包分布随时段变化，跨月对比需重测。
• 记录：把丢包率与回拉次数写在一起，档位判断才准确。

一页速记：丢包处理的六条判断

把整页压成六条，用于实测读数出来后的快速判断。每条都对应上表里的具体行。

一 · 先看首跳

首跳丢包非零就是本地问题，换什么节点都没用，动作只有改无线或改有线。

二 · 1% 是可接受线

回拉约 2.3 次/分，多数人会误判成操作失误，不必处置。

三 · 3% 是质变点

交火与对话都能感知，且各场景的容错机制在此全部失效。

四 · 5% 以上救不回来

四类场景全部失效，多半是本地链路故障或运营商侧问题。

五 · 场景决定档位

同样 2.1%，FPS 是需处置，云游戏已接近不可用。

六 · 补发代价随 RTT 翻倍

38 ms 线路补一次 76 ms，92 ms 线路补一次 184 ms。

• 对应数据：表 1 的十二行感受、表 2 的六行判定、表 3 的八行读数。
• 使用顺序：先按速记分本地与路径，再回表核对具体档位与动作。
• 交叉页：抖动的分档见语音页，判定的粒度见 FPS 页。
• 时效：线路的丢包水平随时段变化，2026-10 的记录需在晚高峰复测。
• 边界：本页覆盖实时场景的 UDP 丢包，下载类 TCP 重传不在范围内。
• 记录：每个时段的丢包率与首跳结果一起记，判断才不会被单点误导。

为什么实时场景宁可丢包也不重传

实时流量走 UDP，丢包不重传，代价是画面或声音缺一块，收益是不必等待补发。理解这个取舍，才知道为什么「换个能纠错的线路」这类说法不成立。

表 4 最后一行解释了为什么「下载很慢」和「游戏很卡」可以同时出现在一条线路上，也可以只出现其中一个。两者的丢包敏感性完全不同，用下载速度判断线路质量，对实时场景几乎没有参考价值。

应用层的三种补偿：都不改变丢包本身

插补、冗余发送与前向纠错都是应用层的补偿手段，它们让丢包的后果变轻，却不减少丢包。实测里 3% 丢包在开启冗余发送后主观感受接近 2%，代价是上行占用增加约 30%。这也说明为什么换节点对本地丢包无效：补偿手段与路径无关。

怎么自己复现三档丢包：四种可控方法

本节写给想自己验证的读者。四种方法按可控性从高到低排，都能复现出表 1 里描述的感受，其中前两种不需要额外设备。

四种方法里第三种最接近真实生活：把手机或笔记本移到 Wi-Fi 信号边缘，丢包会自然落在 2%–6% 区间，症状与表 1 的 3% 档高度一致。这也是为什么「换个房间就卡」这类描述如此常见。

复现时的三个注意点

第一，只改一个变量；第二，每种条件至少跑十分钟；第三，记录要落在同一张表里。三点看起来琐碎，但实测里多数「复现不出来」的记录都违反了其中一条。

• 样本量：每种条件至少 10 分钟，短于此的读数波动大于档位差异。
• 单变量：同时改丢包与延迟，无法判断症状来自哪一项。
• 同场景：同一张地图、同一时段、同一设备，三者都要固定。
• 记录格式：时间、丢包率、回拉次数、主观描述，四列就够。
• 复核：换一天再跑一次，两次结论一致才写进结论。
• 边界：注入工具本身会引入额外处理延迟，读数需扣除这部分。

相邻场景：换一个角度核对同一组数据

四类场景的瓶颈不在同一处：FPS 卡在服务器判定，主机联机卡在 NAT，语音卡在抖动缓冲，云游戏卡在解码与码率。下面六个入口按排查顺序排好，从一个场景读进另一个场景最快。

快喵VPN 在三档丢包下各跑了 30 分钟，主观描述只保留三名记录者一致的部分，个体差异单独备注。

• FPSFPS 竞技：tickrate 与服务器判定64 tick 与 128 tick 的判定窗口差 7.8 ms，比你换节点省下的还多。
• Console主机联机：NAT 类型与端口PS5、Xbox、Switch 三类 NAT 判定，先看类型再谈加速。
• Voice语音会议：抖动缓冲的深度取舍缓冲 20 ms 省延迟但吃抖动，60 ms 稳却吃掉轮流发言的间隙。
• Cloud云游戏：码率与解码延迟端到端 120 ms 预算怎么分到编码、传输、解码三段。
• Updates线路与客户端更新记录每条标注影响面与是否可以回退，9 条按日期倒序。
• FAQ判定问答：换节点有没有用42 问按延迟、抖动、丢包、主机四组分开答。