海鸥加速器专项优化：晚高峰延迟从 96ms 降至 41ms

2026 年 10 月 27 日，海鸥加速器在 3.4.1 版本中上线新的调度权重，香港 · 03 线路在 21 点至 22 点的平均延迟从 96ms 降到 41ms，抖动从 23ms 收窄到 9ms。同一时段东京 · 02 从 118ms 降到 52ms。改动只涉及服务端的线路评分与客户端排序，用户不需要修改任何设置。

问题的起点是一次用户回访。9 月 30 日的问卷里，有 217 条反馈提到“晚上八点后网页打开变慢”，其中 68% 的用户连接的是标记为低延迟的香港线路。后台抓取同一时段的链路指标却发现，线路本身的往返时延只有 39ms，用户端测到的却是 90ms 以上。差距出在排队与丢包重传上，而不是物理距离。

韩铮（调度算法工程师）：“旧权重里丢包只占 30%，而晚高峰丢包 1.8% 带来的重传，对首屏等待的影响比多 10ms 延迟大得多。丢包权重提上去之后，评分才反映真实体验。”

按丢包加权的调度改动

旧评分公式为延迟占 70%、丢包占 30%，带宽不参与计算。新公式改为延迟 50%、丢包 30%、带宽 20%，三项各自归一化后加权求和，分数越低越优先。改动后，一条延迟 39ms 但丢包 1.8% 的线路，评分会被拉到与延迟 80ms、丢包 0.1% 的线路相近的水平，客户端因此更愿意把新连接分给后者。

评分刷新频率同步从 30 秒缩短到 10 秒。晚高峰的拥塞往往只持续两三分钟，30 秒的刷新间隔意味着一次误判会让用户卡上半分钟。缩短到 10 秒后，单条线路的评分在一个高峰时段内平均更新 18 次，调度能跟上拥塞变化。

为了避免频繁切换导致连接重建，客户端增加了防抖规则：新线路评分必须比当前线路低 15% 以上才触发切换，且两次切换间隔不少于 60 秒。实测中，一个 60 分钟的晚高峰时段，平均切换次数为 1.4 次，低于旧版的 3.1 次。

表 1：四条线路逐小时平均延迟（2026-10-26，单位 ms）

时段	香港 · 03	东京 · 02	新加坡 · 01	洛杉矶 · 05
18:00	42	56	63	151
19:00	58	74	79	158
20:00	77	96	92	166
21:00	41	52	64	149
22:00	39	54	62	147

测试方法与逐小时数据

测试端为上海电信 200Mbps 家宽，测试机为 i5-12400 台式机，客户端 3.4.1，每组线路每小时采样 60 次，取中位数并剔除首次握手。对照数据来自 10 月 18 日同一测试环境、同一版本的旧权重结果。20 点时段的数据仍偏高，原因是该时段上游国际出口整体拥塞，调度只能在可用线路之间择优。

21 点之后延迟回落，是扩容与调度共同作用的结果。旧权重下香港 · 03 在 21 点仍有 96ms，因为新连接被优先塞进这条“低延迟”线路，实际排队严重。新权重把部分连接分流到东京与新加坡后，香港 · 03 的并发从 1180 人降到 860 人，延迟随之回落到 41ms。

丢包率的变化同样明显。香港 · 03 在 20 点时段的丢包为 1.8%，21 点后降到 0.2%，东京 · 02 从 2.4% 降到 0.4%。按每秒 120 个请求估算，1.8% 的丢包意味着每秒约 2 个请求需要重传，叠加 TCP 的退避机制，首屏等待会被放大到 1.2 秒以上。降到 0.2% 后，重传基本不影响加载。

客户端侧的两处配合调整

客户端在 3.4.1 中把测速采样从 1 次改为 3 次取中位数，单次探测的耗时从 0.4 秒增加到 1.1 秒，但误判率从 12% 降到 3%。对于需要立刻连接的场景，用户仍可点“快速连接”跳过三次采样，直接用上一次的线路记录。

另一个改动是节点列表的排序。此前按地区固定排列，现在默认按当前评分排序，延迟高或丢包高的线路自动下沉，仍保留按地区浏览的切换入口。列表里新增了最近 10 分钟的平均延迟，数字每 10 秒刷新一次，静态文本会在首次进入时给出一次快照，不依赖脚本也能看到数值。

苏澜（运营负责人）：“这次优化没有新增节点，纯靠调度把体验拉回来，成本比扩容低。10 月 20 日灰度给 5% 用户后，关于卡顿的工单量下降了 63%。”

灰度期间也发现一个问题：部分老旧路由器对 UDP 443 的限制较严，评分会把这类网络判定为高丢包，导致客户端反复切换。3.4.1 增加了三次连续失败后回退 TCP 的逻辑，切换次数回落到正常水平。该逻辑对不支持 QUIC 的系统同样生效。

后续计划把评分刷新缩短到 5 秒，并把带宽权重从 20% 提到 25%，让大文件下载场景也能受益。测试数据会继续按周更新到资讯中心。想验证自己所在网络的改善幅度，可以下载 3.4.1 客户端，在晚高峰时段查看仪表盘上的实时延迟与丢包。