2026 年 10 月 27 日，海鸥加速器完成游戏模式的线路重排，版本号 5.4.2。重排后游戏流量不再与下载、视频共用公共出口，而是走单独的中转队列。运维组在 10 月 20 日至 26 日的晚高峰做了 420 次采样，往返时间中位数从 61ms 降到 46ms，丢包率从 0.6% 降到 0.03%，抖动区间从 ±21ms 收窄到 ±7ms。
这次调整针对的是一个具体现象：晚八点之后，同一台机器上只要有人在下载，游戏内的技能释放延迟就会明显变长。原因不在带宽大小，而在队列调度。公共出口的队列对每条流一视同仁，下载流持续占满缓冲，游戏的小包只能排在后面，单次排队 40ms 到 80ms 并不罕见。重排要解决的是排队顺序，而不是把总带宽做大。
重排思路与分流规则
具体做法分三层。第一层是识别，客户端按进程名与目标端口把流量分为实时对战、语音、下载与网页四类，识别规则内置 240 条，可手动追加。第二层是分队列，实时对战与语音进入独立的中转队列，队列长度上限设为 32 个包，超出即丢弃旧包而不是排队等待，这样排队时间被硬性压在 20ms 以内。第三层是选出口，游戏流量优先走中转到东亚的三条低延迟出口，出口拥塞度超过 70% 时自动换下一条。
分流规则默认开启但不强制。如果玩家同时开着直播推流，可以把推流进程手动划进游戏队列，代价是画面码率会随网络波动；也可以把游戏划进大吞吐队列，用更高的吞吐换稍高的延迟。设置改动立即生效，不需要重连，规则保存在本地配置里，换设备时需要重新设置。
「排队顺序比带宽数字更能决定手感。在测试机上把下载压到 200Mbps，游戏延迟只增加了 4ms，这在重排之前是做不到的。」许文清，海鸥加速器协议研发负责人
420 次采样的结果
采样方式是每 10 分钟对目标服务器发起一次 60 秒的连续探测，统计往返时间、丢包与抖动，时间段固定为 20:00 至 23:00，连续 7 天共 420 次有效采样。重排前的数据取自 10 月 13 日至 19 日，重排后的数据取自 10 月 20 日至 26 日，两次测试使用同一台测试机、同一家宽带、同一目标服务器。
关键数据
- 往返时间中位数：61ms 降至 46ms
- 90 分位：89ms 降至 58ms
- 丢包率：0.6% 降至 0.03%
- 抖动区间：±21ms 收窄至 ±7ms
- 同机下载 200Mbps 时延迟增量：31ms 降至 4ms
- 采样次数：420 次，每次 60 秒
分时段看，改善集中在 21:00 到 22:30 这一段。20:00 至 21:00 的中位数从 54ms 降到 45ms，21:00 至 22:30 从 74ms 降到 48ms，22:30 之后从 58ms 降到 44ms。也就是说，越拥挤的时段收益越大，这与排队模型一致：队列越满，优先级调度节省的时间越多。凌晨时段的差异只有 3ms 左右，符合预期。
自行复测的三步
第一步，在客户端里开启游戏模式并锁定一条线路，避免自动切换掩盖对比结果。第二步，打开客户端底部的实时延迟面板，先记录空闲状态下的 10 个数值，再开始下载一个大文件，记录下载期间的 10 个数值。第三步，把两组数值分别取中位数，差值在 10ms 以内说明分流生效；差值超过 30ms 说明有进程没有被正确识别，可在分流规则里手动添加进程名。
需要说明的是，46ms 是中位数而不是每一次的结果，Wi-Fi 信号弱、所在城市出口拥塞、跨境路由临时调整都会让单次数值偏离。客户端里的实时数值才是个体真实体验，建议以自己设备上的读数为准。若长期高于 80ms，可以换同地区另一条线路，或在支持渠道提交诊断码，运维组会按线路排查。
下一个版本计划把分流规则的匹配范围从进程名扩展到窗口标题，减少对同一进程内多开的情况误判。线路重排的完整规则表会随客户端更新推送，安装后无需额外配置即可使用。
读者评论
7 条评论
昨晚试了下，边下载边打游戏确实不卡了，以前技能会延迟半秒。
测了三次中位数 47ms，跟文章里的 46 很接近，坐标广州。
直播推流那个设置没找到，能出个截图教程吗？
按三步复测了一遍，空闲 44ms，下载期间 51ms，差 7ms，分流是开了。
主机上用着不错，手机热点的时候会飘到 70 多，属于网络问题吧。
建议把规则表开放导出，自己维护方便些。
22 点之后确实稳，之前那会儿经常丢包。