数据不差，为什么还是卡：
四类实时场景延迟账本的拆法

曲线图区：三张底图先说清楚延迟、抖动与丢包各长什么样

下面三张图来自同一批探测记录，横轴是 20:00 到 23:00 的三小时，纵轴是往返时延与帧间隔。先看形状再看数字，判断线路好坏才不会被单点读数带偏。

三列数据卡：先记这三条线，剩下的都是例外

判定卡不追求覆盖所有情况，只回答一个问题：现在的读数属于「还能打」「开始难受」还是「换什么都没用」三档里的哪一档。

• 可玩线

  往返 ≤ 60 ms 且抖动 ≤ 10 ms

  60ms

  这一档里换节点收益最大，38 ms 与 55 ms 的差别在 FPS 里能明显感到先手顺序不同。抖动的门槛比延迟更严：中位 40 ms 但抖动 20 ms 的线路，手感比稳定的 60 ms 更差。

• 难受线

  往返 60–120 ms 或抖动 10–30 ms

  120ms

  主机联机与语音会议在这一档仍可用，但 FPS 的交火判定会开始落后。此时换节点有 20–40 ms 的空间，重点挑抖动而不是挑延迟数字最小的那个。

• 无解线

  本地丢包 > 3% 或 ISP 出口拥塞

  3%

  本地 Wi-Fi 干扰、ISP 晚高峰出口排队、服务器侧满员排队，这三类问题换节点只会把同一个等待搬到另一条线上。判断方法是先测本地到首跳的丢包，非零就不必再换。

三地实测总表：900 组采样按场景与线路拆开

同一批探测记录按线路拆开后差异比预想的大：广州移动到 HK-03 的中位 33 ms，成都联通到同一个落地区域要 51 ms，差的 18 ms 全部出在本地出口到省网的那一跳。

表里最值得看的是最后一行：直连的 p95 是 168 ms，而中位只有 92 ms。中位数掩盖了两倍以上的长尾，而游戏的手感恰恰由长尾决定，因为掉帧和回拉都发生在长尾区间里。

为什么还是卡：四类场景的瓶颈根本不在同一处

把「卡」当成一个词是排查的最大障碍。FPS 卡在服务器判定，主机联机卡在 NAT 与端口，语音卡在抖动缓冲，云游戏卡在编码与解码。四者需要的动作完全不同。

FPS：tickrate 决定了判定窗口，而判定窗口比你的延迟更硬

64 tick 的服务器每 15.6 ms 判定一次位置，128 tick 是 7.8 ms。这意味着即使你把往返从 62 ms 压到 38 ms，只要服务器还在 64 tick 上跑，命中判定仍以 15.6 ms 为粒度。实测中把线路从中位 62 ms 换到 38 ms，交火占先率从 41% 升到 52%，而换到 128 tick 房间后同样线路能到 63%，说明 tickrate 与延迟是两个独立乘数。

• 服务器判定：延迟补偿窗口通常给 100–200 ms，超过窗口后客户端预测与服务器真实位置分歧加大，表现为「打中了没伤害」。
• 客户端预测：回拉幅度与丢包率成正比，1% 丢包时每秒约 1–2 次轻微回拉，3% 时每次交火都能看到。
• 帧时间：60 fps 是 16.7 ms 一帧，144 fps 是 6.9 ms；帧时间不稳时，即便延迟很低也会觉得拖影。
• 输入链路：无线鼠标与手柄的轮询率、显示器的响应时间，合计还能差出 10–20 ms，量级与一段加速线路相当。

主机联机：NAT 类型没变，换节点也进不去同一局

PS5、Xbox 与 Switch 的联机多半是点对点，加速能做的是把 UDP 转发到同一公网出口，让两端的 NAT 类型落在可达组合上。开放型与中等型之间可以直连，严格型只能走中继，中继的代价是一次额外的往返。实测中 PS5 从严格型改善到中等型后，组队成功率从 62% 升到 94%，而往返只降了 9 ms，收益主要来自不再走中继。

• PS5：NAT 类型 1/2/3 对应开放、中等、严格，判定依据是 UDP 可达性而非带宽。
• Xbox：开放、中等、严格三档，严格档会看到「无法与部分玩家组队」的提示。
• Switch：P2P 联机对端口更敏感，固定端口转发比换线路更有效。
• 共同点：三类主机的联机流量都是小包高频，带宽从来不是瓶颈，端口才是。

语音会议：缓冲深度是延迟与稳定之间的硬交换

抖动缓冲的深度直接决定听到的声音是否断续。20 ms 缓冲在抖动 5 ms 的线路上没有代价，抖动一旦到 25 ms 就会出现断续；60 ms 缓冲能吃掉 25 ms 的抖动，代价是所有发言都晚 60 ms。实测里 74 ms 中位延迟、5.1 ms 抖动的 SG-05 线路上，缓冲设 40 ms 几乎没有断续，而直连对照组抖动 22.4 ms，缓冲必须推到 60 ms 以上。

• 丢包隐藏：Opus 的 PLC 能补 20 ms 以内的缺口，超过就会听到金属音。
• 轮流发言：端到端 150 ms 以内不会打断对话节奏，超过 250 ms 才会出现抢话。
• 上行优先：会议是上行敏感型，上行 30M 的线路在摄像头开启时更容易抖。
• 判定顺序：先看抖动，再看丢包，最后才看中位延迟，这一顺序与游戏相反。

云游戏：码率够不够是一回事，解码跟不跟得上是另一回事

云游戏的端到端延迟由输入采集、编码、传输、解码、显示五段相加，1080p 60 fps 的常见分配是 16 + 8 + 33 + 12 + 16 = 85 ms，实测广州移动到 HK-03 的 112 ms 里，传输只占 33 ms，多出来的部分是编解码与显示链路的固定开销。这也解释了为什么把码率从 25 Mbps 提到 35 Mbps，画面清楚了但延迟几乎没动。

• 码率：1080p 60 fps 的可用区间是 15–35 Mbps，超过 35 Mbps 对画质提升有限，对稳定性反而是负担。
• 解码：H.264 硬解约 8–12 ms，AV1 硬解约 14–20 ms，老显卡软解会到 40 ms 以上。
• 帧间隔：解码抖动比平均延迟更影响观感，60 fps 下超过 25 ms 的帧间隔就能被看到。
• 预算：整条链路留 120 ms 是舒适线，超过 150 ms 之后动作类游戏基本无法游玩。

先自我诊断：五步走完再决定要不要换节点

顺序错了会白折腾一晚上：先换节点再看本地，往往换到第五条线才发现问题是家里的 Wi-Fi。下面五步按代价从低到高排。

1. 测本地到首跳的丢包与抖动

   用 ping 网关或路由器地址，跑 200 个包。首跳就丢包，说明是 Wi-Fi、网线或光猫，后面所有测试都白做。本地丢包为 0 才继续下一步。

2. 记录当前线路的 p95 而不是中位

   游戏内计分板或系统工具看 5 分钟以上的读数。中位 38 ms 但 p95 到 168 ms 的线路，说明中间有周期性拥塞，换节点的收益会比预期大。

3. 确认服务器侧状态

   同一局里其他玩家是否都在抱怨，或者换个时段复测。服务器满员排队的表现是所有人同时变慢，与你的线路无关。

4. 按场景换线路类型

   FPS 优先挑抖动低的，语音会议优先挑上行稳的，云游戏优先挑离落地区域近的。同一批线路在不同场景的排名并不一致。

5. 换完复测同一个指标

   换节点后只用同一个指标对比，别把 p95 拿去和上一轮的中位比。900 组采样的经验是：单点读数前后差 10 ms 以内的，多半是噪声。

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

这一节的判断标准只有一条：问题出在「你的流量到服务器的路径上」还是出在「路径之外」。路径之外的六种情形，换节点等于原地转圈。

换节点有效 · 绕开拥塞出口

21:00 之后同城出口排队，p95 明显高于中位。换到另一个落地城市通常能拿回 20–40 ms，实测上海电信从直连 92 ms 换到 HK-03 的 38 ms，属于这一类。

换节点有效 · 避开故障节点

单个落地区域可用率低于 99% 时，换同一区域的另一个节点即可，不必跨区域。三地实测里 HK-07 在 10 月 16 日夜间出现过 4 分钟的可用率下滑。

换节点有效 · 改善 NAT 与中继

主机联机从严格型切到中等型，组队成功率从 62% 到 94%，收益来自不再走中继，与延迟数字关系不大。

换也没用 · 本地 Wi-Fi 丢包

2.4 GHz 频段在电梯间、承重墙附近丢包 2–6%。这一层的丢包换任何节点都带过去，先换 5 GHz 或有线再谈加速。

换也没用 · ISP 晚高峰出口拥塞

本地到省网的第一跳就排队时，加速只能改路径中段。实测中这类情形换节点前后差异常在 5 ms 以内，属于噪声区间。

换也没用 · 服务器侧排队

同一局全员变慢、匹配时间变长，是服务器侧的状态。此时唯一有效动作是换时段或换区服。

测量方法与误差：为什么这些数字可以互相对照

所有数值来自同一套探测脚本与同一批客户端版本，误差范围在图注里逐张标出。跨页比较时可以放心，因为口径没有变过。

• 采样密度：每 200 ms 一个 32 字节 UDP 包，单点连续 30 分钟，三地各 300 组，合计 900 组记录。
• 交叉核对：系统侧探测结果与游戏内计分板读数互校，两者差异超过 15 ms 的记录单独标注不计入中位。
• 版本一致：Windows 与 macOS 端分别固定 4.8.2 与 4.8.1，避免版本差异混进读数。
• 时段固定：统一在 20:00–23:00 采集，这个时段的出口压力最大，也最接近真实使用情况。
• 异常剔除：单次超过 500 ms 的读数按丢包处理，不参与分位计算，避免一条极端记录拉偏 p95。
• 误差范围：同线路同日复测的中位差异通常在 ±3 ms，p95 差异在 ±9 ms，小于这个区间的变化不宜当作结论。

症状对照表：十二种「卡」分别落在哪一段链路上

这张表是整站的索引：先把症状对到链路段，再去对应的内页看完整数据。表格里的「换节点有效性」一列是最常被忽略的判据，标「无效」的六种情形换多少条线都不会好转。

十二行里有六行标「无效」，这不是保守，而是三地 900 组采样的结论：本地无线、ISP 出口、服务器排队、解码能力、帧间隔、无线上行这六类问题，与加速节点之间没有因果关系。把它们误判成线路问题，是最常见的白折腾。

误判的源头：把「卡」和「延迟高」当成同一件事

延迟是数字，卡是体验。数字低的线路照样能卡，因为卡来自帧间隔、丢包回拉与判定窗口这三件事，任何一件都不是中位延迟能表达的。表 2 里「镜头突然拉不回」这一行最典型：线路读数 38 ms 完全正常，问题出在 60 fps 下 48 ms 的帧间隔上。

读表的正确顺序：先看有效性，再看处置

很多人从上往下读，看到第一条就开始改设置，改完发现没用。正确顺序是先看第四列「换节点有效性」，如果写着无效，第三列的处置动作才是唯一入口。这样读能把绝大多数排查压到十分钟以内。

• 有效性为「有效」：换节点或换出口是主要动作，期望收益 20–40 ms 或成功率提升 30 个百分点以上。
• 有效性为「部分有效」：换线只解决一半，另一半在本地或服务器侧，两边都要动。
• 有效性为「无效」：换线只会把同一个等待搬到另一条路径上，读数差异通常在 5 ms 以内，属于噪声。
• 判断依据：症状是否与「同一局其他玩家」同步出现，同步就是服务器侧，不同步才是你的链路。
• 记录方式：每次只改一个变量，改完用同一个指标复测五分钟以上，避免把单点波动当成结论。
• 回到表 1：确认方向后再回总表核对同一线路的 p95 与抖动，两个数字都改善才算真的改善。
• 别叠加改动：同时换节点又改缓冲深度，出问题后无法归因，等于把排查重做一遍。
• 季节因素：10 月的读数不能直接外推到春节前后的晚高峰，出口压力峰值不在同一时段。

上行带宽与并发：四类场景里只有两类真的吃带宽

FPS 与主机联机的报文速率常年在 100 Kbps 以下，带宽再小也够；语音会议开摄像头后上行会瞬间打满，云游戏则同时吃下行码率与上行输入。把四类场景的带宽画像分开，才知道该不该升套餐。

表 3 的结论有点反直觉：同为实时场景，FPS 与主机联机的带宽占用低到可以忽略，真正需要关注的是报文速率与时延一致性；云游戏与开摄像头的会议才需要按 Mbps 计算。这也解释了为什么把宽带从 500M 升到 1000M 对 FPS 毫无帮助，而对 4K 串流立竿见影。

采样补图：分层、落地区域与 tick 刻度的三张读图

首页最后三张图补的是判断所需的背景：分层结构决定开销落在哪一段，落地区域决定物理下限，tick 刻度决定判定粒度。看图不追细节，记住形状就够。

• 分层图的用处：判断某个问题是否可能被加速改善时，先定位它落在哪一层，传输层以下的问题加速管不到。
• 落地区域图的用处：选了离自己最远的落地，再加多少优化也追不上物理下限，这是硬件约束不是配置问题。
• 刻度图的用处：把延迟换算成判定格数，比直接比毫秒更容易判断「这点差距值不值得折腾」。

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

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

快喵VPN 把 900 组采样按场景、线路与时段拆成三张表，任何一条结论都能回到原始记录里逐行核对。

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