九条变更与它们的边界：更新记录里的影响面与回退判断

变更索引：九条的日期、类型与影响面一览

先看索引再看细节。索引里第三列是影响面，第四列决定你要不要做动作：只有标「需升级」或「需重新核对」的条目才需要动手。

表 1 的第五列是这张表的价值所在：九条里只有五条需要动作，其余四条属于记录性变更。把「有没有动作」标出来，能避免每次更新都被当成必须处理的告警。

逐条记录：影响面、下载判断与回退条件

每条记录包含三段：变更本身、影响面与动作、以及回退条件。回退条件写得比变更原因更细，因为真正需要它的时候往往来不及推演。

2026-11-08 · 客户端 4.8.2 · 修正 21:00 后抖动抬升时的选路回退逻辑

4.8.2 修正了晚高峰抖动抬升时反复切换落地区域的问题：原逻辑在抖动超过 18 ms 时每 90 秒重评一次，导致部分线路在 21:00 后反复切换。新逻辑把重评间隔拉到 300 秒，并要求连续两次超过阈值才切换。

• 影响面：全部场景，晚高峰最明显
• 是否需要重新下载：自动更新，无需手动
• 回退条件：出现选路长时间不切换且抖动持续高于 25 ms
• 相关页面：总览页的判定阈值按 4.8.2 复核过，未变动（前往）

2026-11-02 · 口径变更 · p95 由整段计算改为 5 分钟窗口计算

原口径把三小时样本放在一起取 p95，会掩盖局部时段的尖峰。改为按 5 分钟窗口分别计算后取最大窗口的值，更能反映「最难受的那五分钟」。历史数据已按新口径重算，与旧记录不可直接比较。

• 影响面：全部页面的 p95 读数
• 是否需要重新下载：不涉及客户端
• 回退条件：不适用，口径变更不可回退
• 相关页面：FPS 页的表 1 与表 2 均已按新口径重算（前往）

2026-10-28 · 线路 · 新增落地区域 HK-09（九龙），实测中位 36 ms

HK-09 上线后，上海电信到该区域的中位 36 ms、p95 51 ms、抖动 4.0 ms，比 HK-03 的中位 38 ms 略低。差异在误差范围内，实际选择仍建议按抖动分布而不是中位数字。

• 影响面：FPS 与云游戏场景
• 是否需要重新下载：节点列表自动下发
• 回退条件：可用率低于 99% 时自动摘除
• 相关页面：云游戏页的落地区域对比可参考该条（前往）

2026-10-24 · 客户端 4.8.1 · 语音缓冲默认值由自动改为固定 40 ms

自动缓冲在抖动波动时反复调整，反而制造断续。4.8.1 起默认值改为固定 40 ms，可在设置里手动改回自动。实测显示固定 40 ms 后，SG-05 线路的断续从 0.8 次/10 分钟降到 0.1 次。

• 影响面：语音会议场景
• 是否需要重新下载：需升级到 4.8.1 及以上
• 回退条件：线路抖动长期高于 45 ms 时改回自动
• 相关页面：语音页表 1 的四档缓冲读数基于该默认值（前往）

2026-10-20 · 数据 · 三地实测批次结束，900 组采样归档

10 月 11 日至 20 日的三地采集按计划结束，上海、成都、广州各 300 组，合计 900 组记录归档。归档文件包含原始探测数据、游戏内计分板截图与听感记录三类，供后续复算。

• 影响面：全部页面的基础数据
• 是否需要重新下载：不涉及客户端
• 回退条件：不适用
• 相关页面：丢包页的十二条主观描述取自该批次（前往）

2026-10-16 · 线路 · HK-07 夜间可用率下滑 4 分钟（21:14–21:18）

当晚 21:14 至 21:18，HK-07 出现可用率下滑，主机联机的组队成功率在窗口内从 94% 降到 71%，21:18 后恢复。同一区域的 HK-03 未受影响，切换后组队成功率立即回到 92% 以上。

• 影响面：主机联机场景
• 是否需要重新下载：不涉及
• 回退条件：已恢复，无需回退
• 相关页面：主机联机页表 1 的严格型读数部分取自该窗口（前往）

2026-10-14 · 文档 · 补充 Switch 的 UDP 45000–45099 端口段说明

按实测复现结果补充了 Switch 的端口范围说明，并明确该范围是各平台支持页与社区记录的并集，用于排序开放顺序，不作为单一权威清单。同时补充了「先开主端口再补辅助端口」的验证顺序。

• 影响面：主机联机场景
• 是否需要重新下载：不涉及
• 回退条件：不适用
• 相关页面：主机联机页的端口表已同步（前往）

2026-10-12 · 客户端 · 新增硬解检测显示，可查看当前解码路径

客户端新增解码路径显示：走硬解时标注「硬件解码」，走软解时标注「软件解码」并提示 CPU 占用。该功能对应云游戏页表 3 的三种解码路径，便于用户自行核对而非依赖延迟读数。

• 影响面：云游戏场景
• 是否需要重新下载：4.8.2 起可用
• 回退条件：显示异常时可关闭该项
• 相关页面：云游戏页的解码表按该功能口径编写（前往）

2026-10-11 · 数据 · 三地采集点上线，开始本批实测

上海（电信 1000M）、成都（联通 500M）、广州（移动 600M）三个采集点同日开始运行，每地每日 20:00–23:00 各 30 分钟，探测间隔 200 ms。首批读数已与游戏内计分板交叉核对。

• 影响面：全部场景
• 是否需要重新下载：不涉及
• 回退条件：不适用
• 相关页面：总览页的方法一节描述了该口径（前往）

什么条件下应当回退：三条硬判据

回退不是「感觉变差了」就做，而是要有可比对的读数。三条判据都要求改动前后的同一指标对照，单次读数不构成回退理由。

判据一 · 指标劣化超过误差范围

中位差异超过 ±3 ms、p95 差异超过 ±9 ms 才算超出误差。小于这个区间的变化不应触发回退，实测中这类「感觉变差」多数在复测后消失。

判据二 · 劣化持续三个时段

连续三个采集时段（每段 30 分钟）都劣化才成立。单时段劣化可能来自出口拥塞或线路临时故障，与版本无关。

判据三 · 回退后指标恢复

回退一次并复测，指标回到改动前的水平才算确认因果。若回退后仍劣化，问题不在这次变更上。

不值得回退 · 主观不适

没有读数支撑的主观不适，回退只会增加变量。先复测，再判断。

不值得回退 · 单局异常

一局之内的异常可能是对端、服务器或本地设备，单局样本不足以判断。

不值得回退 · 口径变更

口径变更改变的是计算方式而不是事实，无法回退，只能重新比对历史数据。

三列数据卡：三类变更的处理优先级

九条记录按处理优先级分成三类。优先级由「是否改变可比性」决定，而不是由「看起来是否严重」决定。

• 最高 · 改变可比性

  口径变更：旧数据不可直接比较

  2条

  两条口径变更都要求把历史数据重算。对照旧记录得出的结论必须重新验证，这是最容易被忽略的一类影响。

• 次高 · 改变默认行为

  客户端默认值：影响所有新装用户

  1条

  语音缓冲默认值改为固定 40 ms，影响所有新装与升级用户。老用户的既有设置不会被覆盖，因此两类用户的表现会不同。

• 常规 · 只记录

  文档与线路记录：供核对

  6条

  六条属于记录性变更，包括一次 4 分钟的线路中断与端口说明补充。它们不需要动作，但排查时需要它们解释现象。

三条自检：怎么确认自己的版本没被这些变更影响

更新记录的价值在于事后可查。下面三步能在五分钟内确认自己是否落在某条变更的影响面里。

1. 看客户端版本号

   设置页读版本号。4.8.2 表示已包含 11-08 的选路修正，4.8.1 表示已包含 10-24 的缓冲默认值变更。

2. 看语音缓冲是自动还是固定

   4.8.1 之后新装默认固定 40 ms。老用户若仍是自动，说明设置未被覆盖，需要手动改一次。

3. 对照变更日期看读数

   若某段时期的读数与更新记录里的口径变更重叠，那段时间的数据不可与之前直接比较。

影响面与页面对照：哪条记录改了哪一页的读数

这张表把九条记录与站内页面对起来，方便在读到某个数字时回查它的口径来源。

表 2 里出现次数最多的是主机联机页与云游戏页，各三条。这两页的读数受线路与客户端变更影响最大，回查时优先从这两页的图注看口径。

为什么口径变更比版本变更更需要留意

版本变更影响的是行为，口径变更影响的是数字的含义。前者的后果当场可见，后者的后果会在几周后对照旧数据时突然出现：同样的线路，读数看起来变好了，其实只是换了算法。

三张补图：脉冲、拓扑与矩阵

补图用于理解变更的传播路径：一次线路变更如何影响某一局，一次口径变更如何影响一整页表格。

• 传播图：用于判断一次变更会影响多大范围，范围越大越需要重算。
• 影响矩阵：用于回查某个读数来自哪条记录，比通读九条记录更快。
• 线路图：用于解释为什么同区域切换能立即恢复，而跨区域切换代价更高。
• 共用口径：三张图与表 1、表 2 共用同一批记录。
• 复查：本页在每次新记录发布时整体复核一次。
• 记录：新增记录同时更新表 1、表 2 与 RSS 三处，保持唯一来源。

一页速记：更新记录的六条判断

把整页压成六条，用于看到一条新记录时的快速判断。每条都对应上表里的具体行。

一 · 先看是否需要动作

九条里只有五条需要动作，其余是记录性的，不必处理。

二 · 口径变更最需要留意

数字的含义变了，旧数据不可直接比较，结论要重新验证。

三 · 版本变更看默认值

默认值变更只影响新装与升级用户，老用户的设置不会被覆盖。

四 · 回退要有三条判据

超出误差、持续三个时段、回退后恢复，三条都满足才回退。

五 · 线路中断通常自愈

4 分钟的可用率下滑靠同区域切换即可恢复，不必跨区域。

六 · 记录集中在一处

表 1、表 2 与 RSS 同步更新，避免三处口径不一致。

• 对应数据：表 1 的九行索引、表 2 的六行对照、卡片的三类优先级。
• 使用顺序：先看索引里的「需要动作」列，再回逐条记录看回退条件。
• 交叉页：判定阈值见总览页，语音默认值见语音页，端口说明见主机联机页。
• 时效：本页随每次变更追加，最新条目在最上方。
• 边界：本页只记录影响实测读数的变更，纯营销类更新不列入。
• 记录：每条新增记录必须带日期、影响面与回退条件三项，缺一项不发。

变更窗口与时段对照：哪些读数落在变更前后

读历史数据时最容易出错的地方，是把变更前后的读数放在同一行比较。下表按日期把九个采集日与变更对齐，标出哪几天跨了变更窗口。

表 3 里只有两天是「不可比」与「部分不可比」，其余七天可以直接放在一起看。这个比例说明多数变更并不破坏数据的可比性，真正需要小心的是口径变更那一天，以及一次 4 分钟的中断窗口。

剔除窗口的写法

剔除不是把数据删掉，而是在图上标出窗口并在文字里说明。实测里 10 月 16 日那 4 分钟的读数保留在原始归档里，只是在统计 p95 时排除，这样既保留了证据，又不让异常值污染分位。

三张变更补图：脉冲、刻度与落地区域

补图把变更的时间维度画出来：一次修正在不同时段的表现不同，一次新增落地区域改变了抖动分布，一次口径变更改变了数字的含义。

• 采集窗口图：用于定位某一天的读数是否跨了变更，避免误比较。
• 落地区域图：用于判断新增节点的取舍，不看中位看抖动。
• 版本对照图：用于确认一次修正是否真的改善了稳定性，看切换次数比看延迟更准。
• 共用口径：三张图与表 1、表 3 共用同一批记录。
• 复查：每次新增记录时同步复核这三张图。
• 记录：图注必须写明采样日期与版本，否则无法回查。

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

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

快喵VPN 把每条变更与受影响页面、受影响读数逐一对齐，回查某个数字时不必通读九条记录。

• 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 里是回拉，语音里是一声金属音。
• FAQ判定问答：换节点有没有用42 问按延迟、抖动、丢包、主机四组分开答。