How to Enable TCP BBR on a Linux VPS (Debian, Ubuntu, CentOS, Rocky Linux)

TCP BBR is a congestion control algorithm developed by Google and included in the Linux kernel since version 4.9. On routes with high latency, such as traffic from a JUSTG VPS in Johannesburg or Moscow to users in Asia, the default CUBIC algorithm often slows down after small amounts of packet loss. BBR estimates the real bandwidth and round-trip time of the path instead, which usually gives noticeably better TCP throughput for websites, downloads, APIs and file transfers. This guide shows how to enable TCP BBR natively with sysctl on Debian, Ubuntu, CentOS, Rocky Linux and AlmaLinux, and how to verify it.

Why TCP BBR helps on long-distance routes

Loss-based algorithms such as CUBIC treat every lost packet as a sign of congestion and cut the sending rate. On an intercontinental path with 150-300 ms of latency, recovering from each cut takes a long time, so a single transfer rarely reaches the bandwidth your server actually has. BBR models the bottleneck bandwidth and the minimum round-trip time and paces packets accordingly. It only changes how your server sends data, so the visitors do not need to install anything.

Step 1: Check the kernel version and virtualization type

Log in to your VPS as root (or a sudo user) and check the kernel. BBR needs kernel 4.9 or newer. Current releases such as Debian 11/12, Ubuntu 20.04/22.04/24.04, Rocky Linux 8/9 and AlmaLinux 8/9 all qualify.

uname -r
systemd-detect-virt

If systemd-detect-virt returns kvm, xen or vmware, you control your own kernel and can continue. On OpenVZ or LXC containers the kernel belongs to the host node, so BBR cannot be enabled from inside the container.

Step 2: Confirm that the BBR module is available

List the congestion control algorithms the kernel offers, and load the module if bbr is not in the list yet:

sysctl net.ipv4.tcp_available_congestion_control
modprobe tcp_bbr
sysctl net.ipv4.tcp_available_congestion_control

A typical result is net.ipv4.tcp_available_congestion_control = reno cubic bbr. If modprobe reports that the module is not found, your kernel is too old; see Step 5.

Step 3: Enable TCP BBR with sysctl

BBR works best together with the fq (Fair Queue) packet scheduler. Create a dedicated configuration file so the setting survives reboots and is easy to remove later. The commands are identical on Debian/Ubuntu and on CentOS/Rocky/AlmaLinux:

printf 'net.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr\n' | sudo tee /etc/sysctl.d/99-bbr.conf
sudo sysctl --system

The change takes effect immediately for new connections; no reboot is required. Existing connections keep their old algorithm until they are reopened.

Step 4: Verify that BBR is active

Run the following checks:

sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
lsmod | grep bbr

You should see net.ipv4.tcp_congestion_control = bbr and net.core.default_qdisc = fq. The lsmod command normally prints a line containing tcp_bbr. On some kernels BBR is compiled in rather than loaded as a module, so an empty lsmod result is normal as long as the sysctl value shows bbr. To see BBR on live connections, run ss -ti and look for bbr in the output.

Step 5: Measure the result

Compare throughput before and after the change from a client far away from the server, for example a machine in Asia testing a VPS in Johannesburg. A simple method is iperf3:

# Debian / Ubuntu
apt install -y iperf3
# CentOS / Rocky / AlmaLinux
dnf install -y iperf3

# On the server
iperf3 -s
# On the client (replace with your server IP)
iperf3 -c 203.0.113.10 -t 30 -R

Remember to open TCP port 5201 in your firewall only for the duration of the test. Results vary with the time of day and the client network, so run several tests.

Step 6: Very old kernels (legacy method)

Older systems such as CentOS 6/7 (kernel 2.6/3.10) or Debian 8 do not include BBR. In the past a community one-click script by Teddysun was popular for these systems: it installed a newer mainline kernel and enabled BBR in one go, and it never supported OpenVZ. Today we treat that approach as legacy only. Replacing the kernel on an end-of-life distribution can leave the VPS unbootable and receives no security updates. The safer path is to back up your data and reinstall the VPS with a current release from the client area, then follow Steps 1-4.

FAQ

Does TCP BBR work on OpenVZ?

No. OpenVZ and other container platforms share the host kernel, so congestion control cannot be changed inside the guest. JUSTG cloud servers use full virtualization, where Steps 1-4 work normally.

Does BBR speed up UDP traffic?

No. BBR only affects TCP connections that your server sends. UDP-based services and traffic that the server receives are not changed.

Do I need to enable BBR on the client side as well?

No. Enabling BBR on the sending side is enough. For a web server or download server, that is the VPS.

If you still have problems after following this guide, submit a ticket and the JUSTG technical support team will help you.