把 38 ms 打进 15.6 ms 的格子里：FPS 延迟为什么压不到你预期的位置

tickrate 决定了判定窗口，而判定窗口比延迟更硬

服务器每隔一个 tick 结算一次位置与命中，64 tick 是 15.625 ms，128 tick 是 7.8125 ms。这个数字与你的线路无关，是服务端固定的节拍，也是 FPS 里最容易被忽略的那一层开销。

三地实测：两条线路的占先率与回拉频率

占先率的定义是同一局中先看到对手且先完成命中的比例，由录屏逐帧核对，与游戏内计分板交叉验证。它不是主观感受，而是可以复算的计数。

两行同线路不同房间的对比是这张表里最重要的部分：同样的 38 ms 与 0.3% 丢包，占先率相差 11 个百分点，回拉次数相差 0.3 次/分。把这段差距换算成可感知的量，大约等于把往返延迟再压 18 ms 才能追平。

客户端预测与延迟补偿：两个机制决定你看到的是谁的位置

客户端预测让你按下移动立刻有反馈，延迟补偿让服务器回溯判定。两者同时生效时，屏幕上的对手位置与服务器上记录的位置并不相同，差多少取决于你的上行延迟与丢包率。

客户端预测：本地先走，再被服务器纠正

按下移动键的瞬间，客户端立刻让自己动起来，同时把输入报文发给服务器。服务器按 tick 结算后把真实位置发回来，两者不一致时客户端做一次插值纠正。丢包率越高，纠正的幅度越大，视觉上就是角色被拉回原位。实测 0.3% 丢包下每分钟 0.6–0.9 次轻微回拉，2.1% 时升到 6.1 次。

延迟补偿：服务器回溯，但窗口有限

服务器会把命中判定回溯到你看到对手的那个时刻，回溯窗口通常给 100–200 ms。窗口之内，高延迟玩家反而占一点便宜，因为服务器要照顾他的视角；窗口之外，回溯被截断，你的命中就按服务器当前的位置算，于是出现「明明打中却不掉血」。

两者的交点：38 ms 为什么是港服的实用下限

38 ms 的线路上，一次完整的输入到反馈约 38 + 16.7（一帧）= 55 ms，落在补偿窗口内绰绰有余。继续把线路压到 30 ms，只减少 8 ms，占先率提升不到 3 个百分点；而把 64 tick 房间换成 128 tick，一次就吃掉 7.8 ms 的判定粒度，收益相当于多压 18 ms。这就是排序的依据。

• 先换房间：能在 64 tick 与 128 tick 之间选择时，换房间的收益高于换线路。
• 再压抖动：抖动 4.2 ms 与 22.4 ms 的差别，体现在回拉的频率上而不是平均延迟上。
• 最后压中位：中位延迟从 62 ms 压到 38 ms 有效，从 38 ms 压到 33 ms 基本无感。
• 帧时间优先：60 fps 的 16.7 ms 帧间隔比一段加速线路的收益更大，先把帧率锁稳。
• 输入链路：125 Hz 无线鼠标的轮询是 8 ms，换 1000 Hz 直接省掉 7 ms，量级与换线路相当。
• 别同时动：一次只改一个变量，改完复测三局以上，单局数据不足以判断。

三列数据卡：FPS 场景的三条手感线

下表把 FPS 的判定压成三个数字，超过就进入下一档。三档之间没有平滑过渡，实际体验是阶跃的：跨过某条线之后，同一局里的表现会突然稳定下来。

• 舒适

  中位 ≤ 45 ms 且抖动 ≤ 6 ms

  45ms

  港服 38 ms 与广州移动 33 ms 都在这一档，占先率 52%–66%。这一档里继续优化帧时间与输入链路，收益比继续压延迟大。

• 可打

  中位 45–75 ms 或抖动 6–12 ms

  75ms

  日服 62 ms 与成都联通 51 ms 落在这一档，占先率 41%–47%。换线路通常能进上一档，重点挑抖动低的组合。

• 吃亏

  中位 > 75 ms 或丢包 > 1.5%

  1.5%

  直连对照的 92 ms 与 2.1% 丢包就在这一档，占先率 29%、每分钟 6 次以上回拉。此时换线是唯一有效动作，且必须换落地城市。

三张卡片的阈值来自 900 组采样的分位统计，不是拍出来的：45 ms 对应 p75 的分界，75 ms 对应 p95 的分界，丢包 1.5% 对应回拉次数从每分钟个位数跳到两位数的位置。

按代价排序的五步排查：先做零成本的那一步

排查顺序错了，一晚上就白折腾。下面五步按「改动代价」从低到高排，前三步不需要换任何线路，却能解释相当大比例的「卡」。

1. 确认房间的 tickrate

   进游戏前看服务器信息或社区记录。64 tick 与 128 tick 的手感差异相当于 18 ms 的线路收益，且零成本。

2. 锁稳帧率与帧时间

   把帧率上限设成显示器刷新率的整数倍，观察帧时间曲线是否平直。60 fps 下 48 ms 的帧间隔抖动，比 40 ms 延迟更难忍。

3. 量一次本地到首跳的丢包

   ping 路由器 200 个包。首跳丢包非零时，后面所有测试都不必做，先把 Wi-Fi 换 5 GHz 或改有线。

4. 换落地城市而不是换同城节点

   同城出口在 21:00 之后普遍排队，换落地城市的收益通常是 20–40 ms，换同城邻居节点常常只有个位数。

5. 最后才动输入链路与显示器

   鼠标轮询率、键盘扫描率、显示器响应时间合计还能差 10–20 ms，量级与一段加速线路相当，但不属于线路问题。

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

FPS 场景里，换节点解决的是「你的流量在路上」这一段的问题。剩下三段——本地无线、服务器判定、自己的帧时间与输入链路——换什么都没用。

有效 · 出口拥塞

本地到省网第一跳不丢包，但 21:00 之后 p95 抬升超过中位的两倍。换落地城市可拿回 20–40 ms，实测上海 92 ms 直连换到 38 ms 属于此类。

有效 · 单节点可用率下滑

同一落地区域的另一个节点仍正常时，换邻居节点即可，不必跨区域。10 月 16 日夜间 HK-07 曾出现 4 分钟的可用率下滑。

部分有效 · 抖动而非延迟

中位 38 ms 但抖动 20 ms 的线路，换线能改善回拉频率，但改善幅度取决于新线路的抖动分布，不看延迟数字挑不出来，必须看 p95 与 p50 的比值。

无效 · 房间 tickrate 低

64 tick 房间的判定粒度是 15.6 ms，换任何线路都改不了这个节拍，只有换房间有效。

无效 · 本地无线丢包

2.4 GHz 频段在承重墙与电梯间附近丢包 2–6%，这类丢包会原样带到新节点上，表现为换线后回拉次数不变。

无效 · 服务器满员排队

同一局所有玩家同时变慢、匹配时间变长，是服务端状态。此时换线只会增加一次握手，读数反而更差。

怎么自己复算一次：占先率与回拉次数的记法

本页所有结论都能用一局录屏复算，不需要专业设备。方法写出来是为了让读数可以被质疑，而不是只能被相信。

六个指标里，只有「上行丢包」与「服务器状态」两项能在五分钟内得出结论，其余都需要累计样本。经验做法是先量这两项，任一项异常就直接处置，不必再跑完整套。

丢包与回拉：把百分比换算成每秒几次失误

丢包率是个抽象数字，回拉次数是能看见的现象。两者的换算关系取决于报文速率与补发策略，FPS 的报文速率大约每秒 90 包，这个数字决定了 1% 丢包意味着什么。

同一行里两列回拉次数的差距，说明丢包的实际影响与延迟是乘数关系：92 ms 的线路上每丢一个包要等 184 ms，回拉幅度是 38 ms 线路的两倍多。这也解释了为什么直连在丢包升到 2.1% 时，体验会比读数看起来差得多。

为什么 1% 是个心理分界

1% 丢包对应每分钟约 2.3 次回拉（38 ms 线路），如果一局交火 8 次，命中被纠正的概率已经超过一半。玩家在这个水平上会把偶发失误归因为「枪法问题」，开始怀疑设备与灵敏度，而真正的变量是丢包。

• 先看方向：只有上行丢包会造成回拉，下行丢包表现为画面卡一下但角色不乱移动。
• 再看时段：丢包只在 21:00 之后出现，多半是出口拥塞；全天均匀出现，多半是本地无线。
• 三看设备：同一局里换一台机器测一次，能排除网卡驱动与 USB 网卡的干扰。
• 补发策略：游戏内的补发不经过应用层，重传代价由传输层决定，因此换加速线路不会改变单次回拉的幅度。
• 阈值：0.9% 以内可以继续打，1.5% 以上就该处置，3% 以上换线也救不回来。
• 核对方式：路由器侧看发送失败计数，比游戏内感觉靠谱得多。

帧时间、刷新率与输入链路：与线路无关的那 20 ms

把线路压到 38 ms 之后，机箱到眼睛这一段还藏着 20 ms 左右的可优化空间。它不体现在延迟数字里，却实实在在影响你按下的那一刻到画面变化的那一帧。

表 3 里最能说明问题的是垂直同步那一行：一开一关就是 16.7 ms，比从 62 ms 换到 38 ms 省下的 24 ms 只差一点，而这件事不需要换任何线路。三地实测里占先率差 11 个百分点的那批记录，有相当一部分来自参与者的设备配置不同。

先测再改：把「感觉」变成可比的数

改设备之前先量一次基线，否则改完只能靠感觉判断。方法是手机慢动作 240 帧拍摄，看按下按键的瞬间到画面出现变化的帧数，一帧约 4.2 ms；重复 20 次取中位，前后各拍一次即可对比。

• 优先级：垂直同步与显示器刷新率的收益最大，鼠标轮询次之，其余收益在 1–3 ms 量级。
• 不要叠加：同时改动四项，出问题后无法归因，也看不出哪一项真的有效。
• 稳定性优先：帧时间抖 8 ms 比平均多 3 ms 更影响手感，先锁帧再谈优化。
• 手柄用户：主机侧的手柄有线连接能省 6 ms，与换线路的收益同量级。
• 记录：把每次改动与复测结果写在同一个表格里，跨周对比时才有意义。

三张补图：把判定、线路与设备放在同一个坐标里看

主图的横轴是三小时，这三张补图换了个角度：判定节拍、线路拓扑与设备矩阵。同一份数据换轴之后，优先级顺序会看得更清楚。

• 联合会话图：解释为什么同一局里不同玩家对手感的描述差异很大，补偿窗口对所有人一视同仁。
• 分层图：解释为什么 tickrate 与帧时间这两件事换线路都改不了。
• 拓扑图：解释为什么最短的路径不一定最快，出口拥塞会吃掉物理优势。
• 用法：排查时先定位落在哪张图上，再决定下一步动手的位置。
• 复查频率：线路拓扑每月变一次，判定节拍随游戏版本变，设备矩阵只在自己换硬件时变。
• 记录口径：三张图共用表 1 的同一批采样，跨图数字可以直接相加。

六个常见误区：FPS 玩家最容易踩的判断坑

这些说法在社区里流传很广，三地实测里都能找到反例。列出来不是为了纠正谁，而是为了在排查时少绕两圈。

误区一 · 延迟越低越好

延迟从 62 ms 压到 38 ms 有效，从 38 ms 再压到 33 ms 几乎无感。边际收益在 40 ms 附近开始扁平，剩下的空间在帧时间与输入链路上。

误区二 · 带宽越大越顺

FPS 的报文速率约 90 包/秒，下行占用不到 40 Kbps。把 500M 升到 1000M 对占先率没有可测出的影响。

误区三 · 换节点能修判定

判定粒度由服务端 tickrate 决定，客户端改不了。64 tick 房间换任何线路仍是 15.6 ms 一格。

误区四 · 丢包和延迟是两件事

在传输层它们通过补发耦合在一起：92 ms 线路每丢一包要等 184 ms，回拉幅度是 38 ms 线路的两倍多。

误区五 · 夜里的卡是节点坏了

21:00 之后同城出口普遍排队，症状是所有人的 p95 一起抬升。看单节点可用率往往仍是 99% 以上。

误区六 · 手感玄学没法量化

占先率、回拉次数、帧时间、输入延迟四项都能用录屏与计时复算，一局样本就能看出方向。

误区背后的同一个错误：把三个数字当成一个

延迟、抖动、丢包在排查里经常被合并成「网络不好」四个字。实测里三个数字的影响路径完全不同：延迟决定你先看到还是后看到，抖动决定你每秒看到的画面是否一致，丢包决定你的输入是否需要重来。混在一起谈，就永远找不到该动哪一处。

• 延迟的作用：决定交火时的先后顺序，可感知的分界大约在 15 ms 附近。
• 抖动的作用：决定回拉的分布，比平均值更能预测一局里最差的那几秒。
• 丢包的作用：决定输入是否需要重发，一次重发至少一个 RTT。
• 结论一：三个数字里，抖动的改善最能被稳定感知。
• 结论二：丢包超过 1.5% 时，前两项的改善都被抵消。
• 结论三：三项都正常却仍然卡，问题一定在链路之外。

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

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

快喵VPN 在同一批采样里额外记录了房间 tickrate，这一列是解释「同一条线路不同手感」的关键变量。

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