BBR (Bottleneck Bandwidth and Round-trip propagation time) is a TCP congestion control algorithm developed by Google. On paths with long distances or some packet loss, such as a server in Los Angeles serving users in Asia, or downloads over mobile networks, BBR can deliver much higher throughput than Linux’s default, CUBIC. Enabling it takes two lines of configuration on the sending side, which is usually your server.

What congestion control does

TCP must decide how fast to send without overwhelming the network. The congestion control algorithm adjusts the sending rate based on what it observes:

  • CUBIC (the Linux default) is loss-based. It increases speed until packets are lost, then backs off sharply. On long, slightly lossy paths, random loss that isn’t caused by congestion keeps it from ever reaching full speed.
  • BBR is model-based. It continuously estimates the path’s bottleneck bandwidth and minimum round-trip time, and paces sending to match. Random loss doesn’t make it back off nearly as much.

When BBR helps most

  • High-latency routes: cross-continent and trans-Pacific traffic.
  • Lossy links: mobile users, congested international links, Wi-Fi.
  • Large transfers: downloads, video, backups to remote storage, and proxy or VPN servers.

On short, clean paths (same city, same data centre), the difference is small.

Check what you’re using

sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control
uname -r

BBR needs kernel 4.9+, and every current distribution qualifies. If bbr isn’t in the available list, load the module:

sudo modprobe tcp_bbr
echo tcp_bbr | sudo tee /etc/modules-load.d/bbr.conf

Enable BBR

sudo tee /etc/sysctl.d/99-bbr.conf > /dev/null <<'EOF'
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sudo sysctl --system
  • tcp_congestion_control = bbr switches the algorithm for new connections.
  • default_qdisc = fq sets the Fair Queue packet scheduler, which provides pacing. Modern kernels can pace internally without fq, but fq remains the recommended pairing.

Verify:

sysctl net.ipv4.tcp_congestion_control       # bbr
sysctl net.core.default_qdisc                 # fq
ss -ti | grep -m3 bbr                         # active connections using bbr

No reboot is needed, but existing connections keep their old algorithm. Restart long-lived services, or just let connections cycle. On a KVM VPS, such as any VPS.DO VPS, you control the kernel, so this works out of the box. Container-based virtualization often doesn’t allow changing it.

Measure the effect

Compare before and after, from a client far away:

# on a distant machine: download a test file from your server
curl -o /dev/null -w 'speed: %{speed_download} bytes/s\n' https://your-server.example.com/testfile.bin

# or iperf3 between servers, with the server side sending (-R)
iperf3 -c your-server -R -t 30

Create a test file with fallocate -l 500M /var/www/html/testfile.bin, and delete it afterwards. See iperf3.

Run tests several times. Internet paths vary through the day.

BBR versions

  • BBRv1 is in the mainline kernel, and is what you get with bbr.
  • BBRv2 / BBRv3 improve fairness alongside CUBIC flows and how loss is handled. They’re used inside Google, and available as out-of-tree patches or in some custom kernels. Stick with mainline bbr on production servers unless you have a reason to change.

Is BBR “unfair”?

BBRv1 can take more than its share of bandwidth from CUBIC flows on shared bottlenecks. For your own server’s outbound traffic to users, that’s generally fine. Large providers like Google and many CDNs use BBR widely.

Other tuning that matters more for some workloads

  • HTTP/2 and HTTP/3: fewer connections, and QUIC uses its own congestion control (often BBR or CUBIC in user space). See HTTP/2 and HTTP/3 in Nginx.
  • Server location: no algorithm beats physics. Choose a location close to your users. See choosing a VPS location and latency vs bandwidth.
  • A CDN for static assets. See CDN for your website.
  • Routes optimised for your audience: for mainland China, CN2 routes (VPS.DO Hong Kong plans use CN2 + BGP, and Japan plans include CN2 GIA) improve latency and stability far more than any TCP tweak.

Revert

sudo rm /etc/sysctl.d/99-bbr.conf
sudo sysctl -w net.ipv4.tcp_congestion_control=cubic net.core.default_qdisc=fq_codel

Quick reference

Task Command
Current algorithm sysctl net.ipv4.tcp_congestion_control
Available sysctl net.ipv4.tcp_available_congestion_control
Enable default_qdisc=fq + tcp_congestion_control=bbr in /etc/sysctl.d/
Apply sysctl --system
See per connection ss -ti

Related: sysctl tuning and MTU explained.

  • Networking
  • Performance
  • Linux