{"id":934,"date":"2026-08-20T22:50:54","date_gmt":"2026-08-20T22:50:54","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=934"},"modified":"2026-08-20T22:50:54","modified_gmt":"2026-08-20T22:50:54","slug":"tcp-bbr-vps-congestion-control","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/tcp-bbr-vps-congestion-control\/","title":{"rendered":"TCP BBR on a VPS: Enabling Modern Congestion Control for Faster Transfers"},"content":{"rendered":"\n

If your VPS transfers large files slowly, or throughput collapses whenever the network drops a packet, the default TCP congestion control algorithm is a likely culprit. Most Linux distributions still ship CUBIC, which was designed for a world where packet loss meant congestion. On modern high-bandwidth links, BBR \u2014 Google’s Bottleneck Bandwidth and Round-trip propagation time algorithm \u2014 models the actual bottleneck instead of treating every dropped packet as a signal to halve the sending rate. This article explains how to enable BBR on a VPS, how to verify it is active, and what results to expect on real workloads.<\/p>\n\n\n\n

What BBR Changes Under the Hood<\/h2>\n\n\n\n

CUBIC probes for available bandwidth by increasing the send rate until packets drop, then backs off. BBR instead measures the bottleneck bandwidth and the minimum round-trip time continuously, and paces the sender to match. The practical effect: BBR keeps the pipe full without relying on loss as a signal, which produces dramatically better throughput on links with bufferbloat, on long-distance routes, and when other tenants on the same uplink cause occasional drops. The trade-off is slightly more bandwidth consumed by retransmissions in some loss-heavy scenarios, and no benefit at all if your bottleneck is local CPU or disk rather than the network.<\/p>\n\n\n\n

Check Your Kernel First<\/h2>\n\n\n\n

BBR requires kernel 4.9+ as a module and 4.13+ for the fq<\/code> qdisc integration. Almost every VPS image in production in 2026 \u2014 Ubuntu 22.04\/24.04, Debian 12, Rocky 9, AlmaLinux 9 \u2014 ships a kernel well past that. Verify what you have before changing anything:<\/p>\n\n\n\n

uname -r\n# BBR available as a module?\nmodinfo tcp_bbr | head -5\n# current congestion control\nsysctl net.ipv4.tcp_congestion_control<\/code><\/pre>\n\n\n\n
If modinfo tcp_bbr<\/code> returns nothing, your kernel was built without it \u2014 this is rare on mainstream distros but possible on heavily customized provider kernels. In that case the only options are a distro kernel update or a provider change; the kernel and feature details in our provider comparison table<\/a> are worth checking before you commit to a VPS plan if you plan to run network-heavy workloads.<\/p>\n\n\n\n
Enable BBR and the fq Qdisc<\/h2>\n\n\n\n
BBR is designed to work with the fq<\/code> (fair queue) qdisc, which handles pacing. Enable both at runtime first, then make them permanent:<\/p>\n\n\n\n
modprobe tcp_bbr\nsysctl -w net.core.default_qdisc=fq\nsysctl -w net.ipv4.tcp_congestion_control=bbr<\/code><\/pre>\n\n\n\n
To make the change survive a reboot, write it to \/etc\/sysctl.d\/<\/code> and load the module at boot:<\/p>\n\n\n\n
echo \"net.core.default_qdisc=fq\" >> \/etc\/sysctl.d\/99-bbr.conf\necho \"net.ipv4.tcp_congestion_control=bbr\" >> \/etc\/sysctl.d\/99-bbr.conf\necho \"tcp_bbr\" > \/etc\/modules-load.d\/bbr.conf\nsysctl --system<\/code><\/pre>\n\n\n\n
Confirm the change took effect:<\/p>\n\n\n\n
sysctl net.ipv4.tcp_congestion_control\n# expected: net.ipv4.tcp_congestion_control = bbr\nsysctl net.core.default_qdisc\n# expected: net.core.default_qdisc = fq\nss -Tin | head -10   # shows the congestion control in use per connection<\/code><\/pre>\n\n\n\n
The ss -Tin<\/code> output lists cubic<\/code> or bbr<\/code> in the third column for established connections. Existing connections keep their old algorithm; new connections use BBR immediately. If you see bbr<\/code> there, the kernel is using it.<\/p>\n\n\n\n
Measure the Difference with iperf3<\/h2>\n\n\n\n
Never enable a kernel setting on faith \u2014 measure it. iperf3 is the standard tool for this, and you need a second server to test against (any VPS or a cloud instance works; a second VPS from a different provider gives the most honest cross-network numbers):<\/p>\n\n\n\n
# on the remote test server\napt install -y iperf3 && iperf3 -s\n# on your VPS, against CUBIC first\nsysctl -w net.ipv4.tcp_congestion_control=cubic\niperf3 -c REMOTE_IP -t 30 -P 4\n# then against BBR\nsysctl -w net.ipv4.tcp_congestion_control=bbr\niperf3 -c REMOTE_IP -t 30 -P 4<\/code><\/pre>\n\n\n\n
In a typical test on a 1 Gbps VPS with an overseas peer, expect something like:<\/p>\n\n\n\n
Algorithm<\/th>Throughput (4 streams)<\/th>Retransmits<\/th><\/tr><\/thead>
CUBIC<\/td>340-420 Mbps<\/td>2.1%<\/td><\/tr>
BBR<\/td>780-920 Mbps<\/td>3.4%<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The throughput gain of 2-3x on lossy or high-latency paths is typical; on a clean local link with zero loss, CUBIC and BBR are close, and the difference will be small. That is expected \u2014 BBR shines exactly where packet loss or bufferbloat exists, which is most real-world inter-provider traffic. If your test shows no improvement, your bottleneck is not congestion control, and you should look at CPU, disk, or the provider’s bandwidth cap instead.<\/p>\n\n\n\n
Real-World Workloads That Benefit<\/h2>\n\n\n\n
The biggest wins show up in three places:<\/p>\n\n\n\n