2026 年 10 月 21 日，爱加速 UDP 加速通道结束灰度并全量开放。所有节点改为原生 UDP 转发，QUIC 与 UDP 流量统一进入实时队列调度，语音通话、联机对战、直播推流三类业务不再被 TCP 队头阻塞拖累。上线首周数据显示，实时业务抖动下降 41%，语音断音次数从每 10 分钟 1.9 次降到 0.4 次。
问题出在转发方式上。旧架构把 UDP 数据包封装进 TCP 隧道传输，虽然实现简单，但 TCP 的可靠传输机制会带来队头阻塞：只要一个包丢失，后续所有包都要等在缓冲区里，直到重传完成。对战游戏里这表现为角色瞬移，语音通话里表现为连续的断音，直播里表现为画面卡住再突然跳过一段。
新架构改为原生 UDP 转发，每个包独立寻址，丢包只影响自己。同时引入独立的拥塞控制算法，参考 BBR 的思路按带宽与往返时延建模，而不是把丢包一律当作拥塞信号——这在跨境链路上尤其重要，因为公网丢包很多时候与拥塞无关。
为什么实时业务必须走原生 UDP
三类业务对网络的诉求各不相同。对战游戏最怕抖动，1% 的丢包率在 TCP 隧道里可能被放大成 200 ms 的卡顿；语音通话最怕连续丢包，编码器能容忍单包丢失，但无法处理 5 个以上连续包丢失；直播推流最怕上行拥塞，码率一旦被迫下调，画面清晰度要几十秒才能恢复。
原生 UDP 转发配合丢包补偿，可以针对性处理这三种情况：对战流量开启 1:0.15 的冗余发送，语音流量开启前向纠错，推流流量则优先保障上行并限制其他业务占用。三类流量在客户端就已分类标记，进入节点后各走各的队列，互不挤占。
QUIC 与 UDP 统一调度
越来越多的应用把 HTTP 流量放到 QUIC 上，而 QUIC 本身跑在 UDP 之上。如果只识别端口，很容易把 QUIC 当成普通 UDP 流量处理，导致网页加载反而变慢。新版本在客户端增加了协议指纹识别，把 QUIC 流量单独归入交互队列，与视频下载队列分离。
- 实时队列：对战、语音、视频通话，优先级最高，独占 35% 带宽上限
- 交互队列：QUIC 网页请求、SSH、远程桌面，保证小包优先转发
- 批量队列：文件下载、镜像拉取、视频分片，可被前两类抢占带宽
- 分类依据：协议指纹 + 端口 + 进程名三重判断，识别准确率 98.6%
- 队列切换：每秒重算一次，业务变化后 1 秒内完成重新归类
全量开放后的观测数据
灰度期覆盖 96,400 名用户，全量开放后首周采集 1,860 万次实时会话。所有指标均取自客户端埋点与节点侧日志的交叉校验结果，采样时段包含工作日晚高峰与周末全天。
- 实时业务抖动：从 12.6 ms 降到 7.4 ms，降幅 41.3%
- 语音通话断音：每 10 分钟从 1.9 次降到 0.4 次，降幅 78.9%
- 对战类业务丢包：从 0.9% 降到 0.3%
- 30 分钟直播推流：断流 0 次，码率波动小于 4%
- UDP 转发成功率：99.97%，失败集中在企业网关禁用 UDP 的环境
- 额外带宽开销：冗余发送带来 6.2% 的流量增长，未超出套餐额度
对于少数企业网络封锁 UDP 的情况，客户端会自动回退到 TCP 隧道，并在面板上给出提示。回退后延迟会增加 15 至 30 ms，但仍能保证连接可用。用户也可以手动锁定转发方式，位置在设置页的高级选项里，切换后 3 秒内生效。
本次升级随 3.0.1 版客户端推送，全部节点已支持。下一步团队会把前向纠错参数做成可调档位，让用户在弱网环境下自行权衡带宽与稳定性；同时计划把实时队列的调度策略同步到路由器插件，让客厅里的游戏主机也享受到同样的转发优先级。
用户评论
语音会议终于不卡了，之前每十分钟要断三四次，现在一次都没有，MOS 感觉明显上来了。
推流两小时没断过，码率曲线很平，以前一到高峰就自己降码率。
公司网络禁 UDP，客户端自动回退了，面板上有提示这点做得挺细。