Super VPN提速上新：单线上行突破1.82Gbps

2026 年 10 月 18 日，Super VPN v6.1.0 面向全平台推送。这一版的核心是把传输栈整体换掉：单条连接的上行实测达到 1.82Gbps、下行 2.36Gbps，跨国线路平均延迟下降 18%，首包时间从 104ms 压到 78ms。对普通用户来说，这些数字落到体验上就是大文件上传不再爬坡、网页首屏更快出来。

上一代传输栈沿用至今已有两年。随着云盘、在线剪辑、远程桌面这类高带宽场景普及，旧栈在长肥管道（高带宽、高延迟链路）上的短板被放大：窗口增长慢、丢包恢复迟钝、单连接跑不满千兆。团队在 7 月启动重写，把拥塞控制、重传策略与前向纠错三块拆开重做，最终在本月完成灰度。

“真正难的不是把峰值做高，而是在 2% 丢包的网络里仍然保持稳定。我们在拥塞控制上做了三版方案，最后选的是对丢包更温和的那一版，峰值略低，但卡顿投诉下降了 62%。”
—— Super VPN 传输协议负责人 陈亦然

技术拆解：三项改动撑起这次提速

第一项是拥塞控制算法切换到 BBRv3 的定制分支，并在客户端侧加入链路探测：连接建立后的前 800 毫秒内，客户端会发送 5 组不同大小的探测包，据此估算带宽与往返时间，避免从零开始慢启动。第二项是重传策略从“等超时”改为“带外快速重传”，在检测到乱序时立即补发，而不必等待三个重复确认。

第三项是前向纠错（FEC）的自适应开关。链路质量好时关闭 FEC，避免 3%—5% 的额外带宽开销；检测到丢包率超过 0.8% 时自动开启轻量级 FEC，用冗余包换稳定。三项改动叠加后，单连接的吞吐利用率从 63% 提升到 91%，多连接并发时的公平性也有改善，不再出现某一条连接长期抢占带宽的情况。

实测数据：延迟、带宽与首包时间

测试在北京、上海、深圳三地各部署一台千兆宽带终端，分别连接新加坡、东京、法兰克福、洛杉矶四个节点，每项测试重复 300 次取中位数，测试时间为 10 月 12 日至 16 日 21:00—23:00。所有数据由第三方测速工具回传，未做任何平滑处理。

与 v6.0 相比，同一线路的上行带宽平均提升 41%，延迟下降 18%，首包时间缩短 25%。在 2% 人工注入丢包的压力测试中，新栈的吞吐保持率为 76%，旧栈为 48%；抖动从 11ms 降到 4ms，视频会议这类对抖动敏感的应用受益最明显。功耗方面，同等流量下客户端 CPU 占用下降 9%，笔记本续航略有改善。

表中数值反映的是传输栈能力，而非家庭宽带的实际上限。测试终端的网卡为 2.5G、线路带宽上限 2.5Gbps，家用千兆宽带下实测通常落在 780—940Mbps 之间，瓶颈在光猫与运营商侧。想复现接近表中的结果，需要终端、网卡、路由器与线路四段都不成为瓶颈，任何一段跑不满，结果都会停在那一档。

移动端的情况略有不同。手机在 5G 网络下的单线上行普遍受限于基站上行容量，实测多在 90—160Mbps 区间，本次优化在移动端的主要收益体现在延迟与功耗上：同样的视频通话时长，v6.1.0 的电量消耗比上一版低 7%。团队已同步公布测试脚本与原始采样数据，第三方可按相同方法复核。

其他更新与已知限制

除传输栈外，本版还调整了连接建立流程：登录态校验与隧道建立并行执行，平均省下 210 毫秒；断线重连从最多 3 次重试改为指数退避，弱网环境下不再频繁弹出重连提示。路由表更新频率从 6 小时缩短到 2 小时，跨区线路调整能更快下发到客户端。

已知限制有两点。其一，部分老旧路由器对 UDP 大包的处理能力不足，开启 FEC 后可能出现反效果，客户端已加入自动降级，但极端情况下仍建议手动关闭 FEC。其二，Linux 命令行版本暂未启用自适应 FEC，将在 v6.1.2 补齐。遇到异常可导出诊断日志，日志中不含任何访问记录。

提速是长期工程，接下来团队会把重点放在弱网与移动网络切换场景，目标是地铁、高铁这类频繁切换基站的环境下，重连中断时间控制在 300 毫秒以内。v6.1.0 已在全平台开放下载，升级后可在客户端“连接详情”里看到实时带宽与首包时间。