BBR (Bottleneck Bandwidth and Round-trip propagation time) is Google’s TCP congestion control algorithm, built into the Linux kernel since version 4.9. Where the default CUBIC algorithm probes for bandwidth by filling the network buffer and watching for loss, BBR builds a model of the bottleneck link and paces packets against it. On a typical VPS connection \u2014 a long-distance path with real latency and bufferbloat \u2014 the practical result is higher throughput and noticeably lower latency. This guide covers the prerequisites, the exact sysctl changes, verification commands, and a clean rollback path.<\/p>\n\n\n\n
BBR shines on high-bandwidth, high-latency paths: a US-based VPS reached from Europe or Asia, large file downloads, rsync of big datasets, and media streaming. Tests on such links commonly show 2\u20133x throughput gains and a 40\u201360% drop in latency spikes compared with CUBIC. It does little for very short transfers of a few hundred kilobytes, because those connections never leave slow-start, and it cannot overcome a provider that shapes your uplink with a hard cap. Measure with iperf3 before and after the change rather than trusting a gut feeling.<\/p>\n\n\n\n
You need kernel 4.9 or newer. Check what you are running:<\/p>\n\n\n\n
uname -r<\/code><\/pre>\n\n\n\nDebian 10\/11\/12, Ubuntu 18.04 and newer, and current AlmaLinux or Rocky Linux images all ship kernels that include BBR. Confirm the module is actually available:<\/p>\n\n\n\n
sysctl net.ipv4.tcp_available_congestion_control<\/code><\/pre>\n\n\n\nThe output should include bbr<\/code>. If your kernel is older, run a full distro upgrade or reinstall with a current cloud image \u2014 there is no supported way to backport BBR to a 3.x kernel.<\/p>\n\n\n\nEnable BBR Persistently<\/h2>\n\n\n\n
Create a sysctl drop-in file so the setting survives reboots:<\/p>\n\n\n\n
sudo tee \/etc\/sysctl.d\/99-bbr.conf <<'EOF'\nnet.core.default_qdisc = fq\nnet.ipv4.tcp_congestion_control = bbr\nEOF<\/code><\/pre>\n\n\n\nApply it immediately:<\/p>\n\n\n\n
sudo sysctl --system<\/code><\/pre>\n\n\n\nThe fq<\/code> (fair queueing) qdisc matters: BBR was designed to work with it, and it smooths bursty senders. On older systems you can use sudo sysctl -p \/etc\/sysctl.d\/99-bbr.conf<\/code> instead.<\/p>\n\n\n\nVerify BBR Is Actually Active<\/h2>\n\n\n\n
Three quick checks. First, the global default:<\/p>\n\n\n\n
sysctl net.ipv4.tcp_congestion_control<\/code><\/pre>\n\n\n\nIt should print bbr<\/code>. Next, look at a live connection \u2014 the congestion control field appears on the right side of the ss<\/code> output:<\/p>\n\n\n\nss -tin | head<\/code><\/pre>\n\n\n\nFinally, confirm the qdisc on your main interface (cloud VPS interfaces are often named ens3<\/code>, enp1s0<\/code>, or eth0<\/code>):<\/p>\n\n\n\ntc qdisc show dev eth0<\/code><\/pre>\n\n\n\nYou should see fq<\/code>. Note that new connections pick up BBR immediately, but long-lived existing connections may keep CUBIC until they are re-established.<\/p>\n\n\n\nQuick Bufferbloat Check<\/h2>\n\n\n\n
Bufferbloat \u2014 the latency inflation that happens when a full queue delays packets \u2014 is the main symptom BBR fixes, so it is worth measuring it directly. Open a second terminal and ping your gateway continuously while downloading a large file with wget or curl:<\/p>\n\n\n\n
ping -c 100 192.0.2.1<\/code><\/pre>\n\n\n\nWith CUBIC, the round-trip time typically inflates by 50\u2013150 ms while the download saturates the link; with BBR and the fq qdisc, latency stays flat because the sender never overfills the queue. If you see no difference on your path, your bottleneck is probably elsewhere \u2014 the host’s uplink cap, the provider’s shaping, or the remote server itself \u2014 and no congestion algorithm will change that.<\/p>\n\n\n\n
Optional Tuning Notes<\/h2>\n\n\n\n
Leave the rest of the network defaults alone unless you have a specific problem. One safe tweak for busy web servers is lowering net.ipv4.tcp_notsent_lowat<\/code> to 16384<\/code>, which cuts latency for small responses \u2014 but test it under load first. On kernels where tcp_bbr2<\/code> is available, the BBRv2 variant can be enabled the same way if you prefer the loss-aware behavior.<\/p>\n\n\n\nRollback<\/h2>\n\n\n\n
If a provider or workload misbehaves \u2014 some very small plans with aggressive shaping see higher loss under BBR \u2014 reverting takes one file edit:<\/p>\n\n\n\n
sudo tee \/etc\/sysctl.d\/99-bbr.conf <<'EOF'\nnet.ipv4.tcp_congestion_control = cubic\nnet.core.default_qdisc = fq_codel\nEOF\nsudo sysctl --system<\/code><\/pre>\n\n\n\nThe change applies immediately and needs no reboot in either direction.<\/p>\n\n\n\n
Measure Before and After<\/h2>\n\n\n\n
Run iperf3 against a distant endpoint before and after the change to quantify the gain:<\/p>\n\n\n\n
iperf3 -c iperf.he.net -R<\/code><\/pre>\n\n\n\nAlso watch ping latency under load for bufferbloat. BBR is one piece of the performance puzzle \u2014 CPU allocation, disk I\/O, and memory sizing matter just as much. If you are still choosing a host, compare providers side by side in our VPS comparison table<\/a> before committing, and check the FAQ section<\/a> for questions about oversubscription and network caps.<\/p>\n\n\n\nBottom Line<\/h2>\n\n\n\n
BBR is a ten-minute change with measurable upside on long-distance paths and no downside for typical web workloads. Enable it, verify with ss<\/code> and tc<\/code>, keep the rollback snippet handy, and re-test with iperf3. Then make sure the rest of the stack \u2014 see the full specs and pricing on the main site<\/a> \u2014 is sized for what you are actually serving.<\/p>\n\n\n\n