哪种协议速度最快?先搞清速度由什么决定

"我把 Trojan 换成 Hysteria2,速度直接翻倍。" 这句话本身可能是真的,但它证明的东西和说话人以为的往往不是一回事。绝大多数这类经历里,换协议的同时也换了节点——换了落地机器,换了跨境路径,换了同时在线的人数。协议只是那几个同时变动的变量里最显眼的一个。

把一次下载想象成搬东西:路有多宽(带宽上限)、走哪条路线(跨境路径)、终点仓库有多少人在同时卸货(落地负载),这三件事决定了绝大部分结果。协议相当于打包方式,它会影响一点效率,但不会让一条堵死的路变通畅。

所以"哪种协议最快"这个问题,严格说是问错了层。更有用的问法是:我这次变慢,是四块里的哪一块出了问题。下面先把权重排清楚,再给一套你自己就能跑的验证流程。

先说结论:协议在最终速度里占多大权重#

下面这张表不是实测数据,而是一份用于排查的权重排序——按各因素能造成的波动量级从大到小排列,帮你决定先查哪里。实际比例随网络环境差异很大。

顺序本身就是排查顺序。协议排在最后一位,不是因为它不重要,而是因为在它前面还有四道更容易出问题、影响也更大的关卡。

带宽上限、线路路径、落地负载各自贡献了什么#

三者的失效表现完全不同,分清楚可以省掉大量无效尝试。

带宽上限是一条硬线。很多套餐对单个连接或整个账号设了速率阈值,到了阈值就削平,曲线看上去异常平整——测速跑到某个数字后纹丝不动,反复几次都是同一个值,这基本就是限速而不是拥堵。

跨境路径决定的是这条线在晚上还剩多少。白天二三十毫秒、晚上八点后飙到两三百毫秒并伴随丢包,是国际出口段拥堵的经典形态,和落地机房本身没关系。这一段的结构差异,中转与直连的路段拆解里讲得更细。

落地负载表现为"时快时慢但延迟不涨"。延迟稳定、丢包也低,下载速度却在几兆到几十兆之间来回跳,通常是同一台落地机器上人太多。换同地区的另一个节点编号往往立刻改善。

这三种表现有可能同时出现。判断时优先看延迟曲线是否随时间恶化:恶化的是路径问题,平稳但速度上不去的是限速或负载问题。

为什么换协议之后的"变快"多半是错觉#

因为几乎没有人是在控制变量的条件下换的。常见的混淆有四种:

• 换协议时顺手换了节点,落地机器和线路都变了;
• 前后两次测试隔了几小时,跨过了高峰时段;
• 新协议节点是机场新上的,在线人数还少;
• 客户端切换后重建了连接,恰好避开了原来那条已经劣化的 TCP 连接。

第四种最隐蔽。长时间运行的连接一旦经历过严重丢包,拥塞窗口会缩得很小,即使链路恢复也不会立刻涨回来。这时候你哪怕换回原来的协议、只是重连一次,速度也会"变快"。

怎么做一次真正控制变量的对比测试#

要让协议对比有意义,必须把其余变量钉死。做法如下:

1. 找同一台落地服务器上的两个协议入口。 在节点列表里找地区、编号完全相同、只有协议标记不同的两条,例如同一组香港节点分别提供 Trojan 与 Hysteria2 入口。找不到就说明这次对比做不了,不要用不同编号的节点凑合。
2. 固定时间窗口。 两次测试间隔控制在十分钟以内,且都不跨越 20:00 这类流量拐点。理想做法是 A、B、A 交替各测一次,用第三次验证第一次的结果没有漂移。
3. 固定测试对象和方式。 用同一个下载源、同样的并发数、同样的时长,不要一次用测速网站一次用下载文件。
4. 同时记录延迟与丢包。 只记下载速度会漏掉最关键的信息——如果两次测试的丢包率本身就不同,那链路状态已经变了,速度差不能归给协议。
5. 重复三轮取中位数。 单次结果的随机波动经常大于协议之间的真实差异,不重复就等于在测噪声。

配合一个简单的记录格式,比凭印象可靠得多:

# 结构示例,地址与节点名均为占位符
# 每轮记录:协议 / 时间 / 平均延迟 / 丢包率 / 下载速率
ping -n 100 example.invalid            # 采样延迟与丢包
curl -o NUL -w "%{speed_download}\n" https://example.invalid/testfile

轮次  协议        时间     平均延迟  丢包率  速率
1     Trojan      21:02    ___ms     ___%    ___MB/s
2     Hysteria2   21:09    ___ms     ___%    ___MB/s
3     Trojan      21:16    ___ms     ___%    ___MB/s

第三行的意义在于:如果它和第一行差很多,这轮数据整体作废,说明链路状态在测试期间就变了。

哪些场景下协议确实会带来肉眼可见的差异#

协议不是永远不重要,它在特定链路条件下会成为主导因素:

前两种情形的取舍,Hysteria2 与 TUIC 的拥塞控制对比有更具体的展开;最后一种情形下,把时间花在挑线路上收益更高。

测速数值和实际体验为什么经常对不上#

测速工具默认开多条并发、只跑十几秒,量的是短时峰值吞吐。而你真正在意的体验,大多由另外三个量决定:首包时间决定网页"跟手不跟手",持续吞吐决定高码率视频卡不卡,连接存活时长决定长任务会不会中途断掉。

这就是为什么会出现"测速两百兆但视频一直缓冲":并发拉满时总带宽很高,单条连接的持续速率却撑不住一个 4K 码流。想更贴近真实体验,直接用目标场景本身当测试——播一段高码率视频看有没有缓冲,比看测速数字有效。

遇到速度慢,应该按什么顺序往下排查#

按代价从低到高走,不要一上来就折腾协议:

1. 换同地区的另一个节点编号,排除单台落地机负载;
2. 对比白天与晚高峰的同一节点,判断是不是国际出口段拥堵;
3. 关掉客户端的额外功能(全局 TUN、复杂分流规则)再测一次;
4. 用手机流量替换家庭宽带测同一节点,分离本地接入问题;
5. 确认套餐是否已触发限速阈值或流量倍率扣减;
6. 最后才换协议,并且按上面的控制变量流程做。

走完前五步仍然定位不到的,问题往往在入口侧而不是落地侧,可以接着看多入口与 BGP 接入那一篇。

小结#

协议在速度构成里的权重,排在带宽上限、跨境路径和落地负载之后。绝大多数"换协议变快"的经历都没有控制变量,变的其实是节点或时段。要让对比成立,必须在同一台落地服务器上找两个协议入口,交替测三轮并同时记录丢包。协议真正起决定作用的场景是高丢包链路、移动网络切换和有主动探测的严格环境。速度排查的正确顺序,是从换节点开始,把协议放在最后一步。