TL;DR:TUIC 拥塞控制不要按「谁测速高」选。BBR 偏向主动估算带宽,Cubic 更传统、更克制一些。干净链路可以先试 BBR;丢包、共享网络、游戏语音抖动明显时,把 Cubic 也测一遍。

TUIC 走 QUIC/UDP,拥塞控制会直接影响吞吐、延迟和丢包后的恢复。很多配置里只给一个字段,比如 congestion_control: bbrcongestion_control: cubic。字段很短,但影响不小。

BBR 和 Cubic 的差别

简单说:BBR 试图估算链路带宽和最小 RTT,目标是把队列压低;Cubic 根据丢包和窗口增长调整发送速度,行为更接近传统 TCP 拥塞控制思路。

维度BBRCubic
干净链路吞吐通常更积极通常较稳
丢包链路可能继续推流量更容易降速
延迟队列目标是控制队列拥塞时可能形成队列
多人共享有时抢占感更明显有时更温和
游戏和语音要看 P99要看 P99

不要把这张表当绝对结论。运营商路径、服务器网卡、内核、客户端实现、限速策略都会改变结果。

先确认配置字段有没有生效

不同客户端对 TUIC 字段的写法不一样。sing-box、Mihomo、原版 TUIC 客户端都可能有自己的字段名和默认值。排查前先看最终生成配置,而不是只看订阅面板上的节点备注。

Mihomo 类配置可能长这样:

proxies:
  - name: tuic-demo
    type: tuic
    server: example.com
    port: 443
    uuid: redacted-uuid
    password: redacted-password
    congestion-controller: bbr

sing-box 的字段位置则在 outbound 内。重点不是背字段名,而是确认:客户端实际读到了你设置的拥塞控制。

测试方法

一次只改一个变量。

  1. 固定同一台服务器。
  2. 固定同一客户端和同一网络。
  3. 固定 MTU。
  4. 固定测试时段,避开晚高峰和空闲时段混测。
  5. BBR 跑 10 到 15 分钟。
  6. Cubic 跑同样时间。
  7. 记录平均延迟、P95、P99、丢包、吞吐。

如果只跑浏览器测速,结论会偏向吞吐。游戏、语音、远程桌面要看 P95/P99。P99 从 80ms 跳到 600ms,平均值仍可能看起来不错,但体感已经很差。

UDP 路径差会放大差异

TUIC 的外层是 UDP。很多网络对 UDP 的处理和 TCP 不一样:

  • 校园网或公司网可能限制 UDP 长连接。
  • 移动网络基站切换会带来短时丢包。
  • 家用路由器 NAT 表满时,UDP 映射会抖。
  • 部分跨境路径对 QUIC 类流量有独立限速。

这类问题不是 BBR 或 Cubic 能完全修好的。拥塞控制只能决定「发现拥塞后怎么发」,不能改变物理路径。

什么时候先选 BBR

可以先试 BBR 的场景:

  • VPS 到本地 RTT 稳定。
  • 丢包低,长时间低于 1%。
  • 主要用途是下载、同步、网页加载。
  • 单人使用,链路不和多人共享。
  • 服务器 CPU 有余量。

BBR 的优势通常出现在链路相对干净时。它能更快把带宽跑起来,同时避免无意义堆队列。但如果底层 UDP 本来就被限速或丢包很高,BBR 可能只是把问题推得更明显。

什么时候把 Cubic 纳入候选

这些场景建议认真测 Cubic:

  • 晚高峰 P99 明显跳高。
  • 游戏语音偶发卡顿,但下载速度不低。
  • 多个设备共用同一条线路。
  • 移动网络或 Wi-Fi 环境经常切换。
  • BBR 下测速高,但交互体验差。

Cubic 不一定更慢。它可能在拥塞时更早降速,换来更少的尖峰延迟。对游戏和语音来说,这比峰值带宽更重要。

如果要在多客户端里做同一组对比,可以用兼容 Clash / Singbox / V2Ray 的订阅导出对应格式,但测试时要确认 TUIC 字段没有被转换器丢掉。

MTU 不要忽略

TUIC/QUIC 对 MTU 很敏感。包太大导致分片,任何一个分片丢了,应用层看到的就是抖动。常用测试值:

MTU用途
1500局域网和干净链路基线
1350常见保守值
1280IPv6 和复杂路径常用下限附近
1200QUIC 保守起点

测试拥塞控制前先固定 MTU。如果 BBR 用 1350,Cubic 用 1200,结果就不可比。

结论

TUIC 拥塞控制选择没有通用答案。BBR 适合先跑干净链路和吞吐场景,Cubic 值得在丢包、共享网络、游戏语音场景里对照。最终看数据,不看感觉:同一环境下记录 P95/P99、丢包和吞吐,保留尖峰更少的那组。

相关阅读