开启 TCP BBR 实测：代理隧道发送端才有收益

八月 21, 2026 更新: 八月 24, 2026 [网络与安全] #sing-box #网络 #代理与科学上网

背景

sing-box 代理链路（本机客户端 → 服务端 → 目标站）部署完成后，常听说「服务端开 TCP BBR 可以提速」。是否属实、在哪个环节有效，用内网测试拓扑实测一把：

机制：BBR 是发送端拥塞控制

TCP 拥塞控制由数据发送方决定。下载场景下发送方是目标站（如镜像站），本机/代理服务端是接收方——接收方内核开不开 BBR，对下载吞吐没有直接影响。BBR 的收益体现在：

  1. 发送方（你自己）→ 接收方的路径：如代理服务端把数据发给客户端（VPS → 本机）
  2. 高带宽时延积 + 有丢包的路径：cubic 遇丢包就线性退避，BBR 不因丢包降速

实测数据

1. 直连国内站点（发送方 = 镜像站）

轮次cubicbbr
13.82 MB/s0.43 MB/s
23.50 MB/s4.88 MB/s
30.21 MB/s0.38 MB/s

两者无稳定差异（第三轮是路径整体拥塞，双双掉底）。本机是接收方，本地开 BBR 与直连下载速度无关。

2. 服务端 → 镜像站（服务端为接收方）

cubic 0.5~3.4 MB/s，bbr 0.3~3.7 MB/s，同样无差异——再次印证接收方 CC 无关。

3. 经链全链路（本机 → 服务端 → 镜像站）

轮次cubic（两端）bbr（两端）
12.23 MB/s3.01 MB/s
21.22 MB/s4.14 MB/s
31.33 MB/s3.42 MB/s

bbr 稳定 3.0~4.1 MB/s 不掉底，cubic 掉底到 1.2~1.8 MB/s。进一步拆分确认：只有服务端（隧道发送端）开 BBR 有效——

配置结果
本机 cubic + 服务端 bbr（发送端 BBR）3.86 / 4.18 / 2.78 MB/s，稳定
本机 bbr + 服务端 cubic（接收端 BBR）0.26 / 4.01 / 1.77 MB/s，掉底

4. 纯内网隧道段对照

服务端本地起 HTTP 服务（1GB 文件）走隧道下载：cubic 与 bbr 均为 117 MB/s 满速——内网段本身无丢包，CC 无差异，问题出在跨网路径。

结论

  1. 直连国内站点：本机（接收方）开 BBR 没有收益，开启与否不影响下载速度
  2. 经链场景：服务端（隧道发送端）开 BBR 有收益——实测吞吐更稳、不掉底；这正是境外 VPS 部署的对应位置：VPS 是隧道发送端，跨境链路丢包率高，是 BBR 的典型受益场景，建议开启
  3. 本机开 BBR 无副作用；唯一的本机受益场景是上传（本机为发送方时）
  4. 内网测试无法完全复现跨境长路径的丢包特征，收益方向明确，幅度随路径而异

实际部署（VPS）

按上述结论在 VPS（隧道发送端）上实际开启并持久化：

sudo modprobe tcp_bbr
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr net.core.default_qdisc=fq
printf "net.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr\n" | sudo tee /etc/sysctl.d/99-bbr.conf

验证输出：net.ipv4.tcp_congestion_control = bbr、net.core.default_qdisc = fq，/sys/module/tcp_bbr 存在。

两点注意：

开启命令

modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr net.core.default_qdisc=fq

持久化（/etc/sysctl.d/99-bbr.conf）：

net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr

验证：

sysctl net.ipv4.tcp_congestion_control   # 应输出 bbr
ls /sys/module/tcp_bbr                   # 模块已加载
索引
背景
机制：BBR 是发送端拥塞控制
实测数据
- 1. 直连国内站点（发送方 = 镜像站）
- 2. 服务端 → 镜像站（服务端为接收方）
- 3. 经链全链路（本机 → 服务端 → 镜像站）
- 4. 纯内网隧道段对照
结论
实际部署（VPS）
开启命令