How to Enable BBR on Ubuntu 26.04, 24.04 and 22.04

Enable BBR on Ubuntu when long-distance transfers, VPS traffic, or high-latency links feel slower than the available bandwidth should allow. BBR, short for Bottleneck Bandwidth and Round-trip propagation time, changes Linux TCP congestion control from loss-based behavior to a model that estimates bandwidth and latency. On Ubuntu, the practical change is small: load the BBR kernel module, set the fq queue discipline, select bbr with sysctl, and verify the active TCP setting.

This workflow uses a dedicated file under /etc/sysctl.d/ instead of repeatedly appending lines to /etc/sysctl.conf. That keeps the BBR configuration easy to audit, reapply, or remove later, and it avoids duplicate sysctl lines after repeated maintenance.

Use these commands on Ubuntu 26.04 (Resolute Raccoon), Ubuntu 24.04 (Noble Numbat), and Ubuntu 22.04 (Jammy Jellyfish). All three supported LTS releases ship kernels newer than Linux 4.9, which is the baseline required for BBR support.

When BBR Helps

BBR helps most when the connection has enough bandwidth to fill but enough latency or mild packet loss to make cubic back off too aggressively. It is often worth testing on servers that move large files, stream media, sync backups, or serve users across regions.

Good BBR Candidates

• Cloud servers and VPS instances serving users in other countries or regions
• Backup, object storage, mirror, or file-transfer hosts that push sustained outbound traffic
• Streaming or media servers, including Jellyfin on Ubuntu or Plex on Ubuntu
• Wireless, satellite, or international network paths where packet loss does not always mean true congestion

When Cubic Is Fine

• Local network traffic with low latency and stable links
• Desktop systems used mainly for browsing, office work, or light downloads
• Compatibility-sensitive environments where network behavior must stay unchanged
• Systems where monitoring shows no throughput problem under cubic

Expect the largest differences on high-bandwidth paths with round-trip latency above roughly 50 ms. On low-latency LANs or small home connections, BBR may work correctly but show little visible improvement.

Check BBR Support

Start by checking the running kernel version. The exact version varies by Ubuntu release, hardware enablement stack, and updates, but supported Ubuntu LTS kernels are already new enough for BBR.

uname -r

Expected output is a single kernel release string. Do not try to match this exact number; confirm only that your kernel is newer than Linux 4.9:

7.0.0-14-generic

Next, confirm that the tcp_bbr module exists for the running kernel:

modinfo -F filename tcp_bbr

The path changes with your kernel version. A normal result points to the BBR module under /lib/modules/:

/lib/modules/7.0.0-14-generic/kernel/net/ipv4/tcp_bbr.ko.zst

Now check which congestion control algorithms the running kernel currently exposes:

sysctl net.ipv4.tcp_available_congestion_control

On a fresh Ubuntu system, BBR may not appear until the module is loaded or selected. Ubuntu 24.04 commonly returns the same default list before BBR is enabled:

net.ipv4.tcp_available_congestion_control = reno cubic

That default output is normal on Ubuntu 26.04, 24.04, and 22.04. The next section loads BBR and makes the setting persistent.

Check Current TCP Defaults

Record your current congestion control algorithm before changing it. Most Ubuntu systems use cubic by default.

sysctl net.ipv4.tcp_congestion_control

net.ipv4.tcp_congestion_control = cubic

Also record the current queue discipline. Fresh Ubuntu LTS systems commonly use fq_codel.

sysctl net.core.default_qdisc

net.core.default_qdisc = fq_codel

If your system already uses a custom value, keep a note of it so you can restore the same setting later instead of assuming fq_codel was the original value.

Enable BBR with sysctl

Load the BBR module first so the available algorithm list updates immediately:

sudo modprobe tcp_bbr

Check the available congestion controls again. BBR should now appear beside reno and cubic:

sysctl net.ipv4.tcp_available_congestion_control

net.ipv4.tcp_available_congestion_control = reno cubic bbr

Create a dedicated sysctl file for BBR. The command overwrites only /etc/sysctl.d/99-bbr.conf, not the global /etc/sysctl.conf file:

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

The command prints the two lines it wrote:

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

The fq queue discipline provides packet pacing, which BBR needs for accurate rate control. The second line selects BBR as the TCP congestion control algorithm for new TCP connections.

Apply the dedicated sysctl file without rebooting:

sudo sysctl -p /etc/sysctl.d/99-bbr.conf

Expected output confirms both values were accepted:

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

No reboot is required to start using BBR. Existing TCP connections keep their current behavior, while new TCP connections use the updated settings.

Verify BBR Is Active

Confirm that Ubuntu now uses BBR for TCP congestion control:

sysctl net.ipv4.tcp_congestion_control

net.ipv4.tcp_congestion_control = bbr

Confirm that the queue discipline is now fq:

sysctl net.core.default_qdisc

net.core.default_qdisc = fq

You can also inspect live TCP sockets. Idle systems may not show many entries, and connections opened before the sysctl change may still show cubic. Open a fresh transfer or SSH connection after enabling BBR if you want this command to show the new algorithm in socket details.

ss -tin

If you want to confirm persistence after a restart, reboot during a maintenance window and rerun the two sysctl verification commands above. A reboot is optional for activation, but it is a useful persistence check on production templates or golden images.

BBR2 on Ubuntu

Searches for enable tcp bbr2 usually come from custom-kernel or forum instructions. Do not set net.ipv4.tcp_congestion_control=bbr2 unless your running kernel lists bbr2 as an available congestion control algorithm.

sysctl net.ipv4.tcp_available_congestion_control

Stock Ubuntu LTS kernels list bbr, not bbr2, after the BBR module is available:

net.ipv4.tcp_available_congestion_control = reno cubic bbr

If a custom kernel such as a performance-focused build lists another algorithm, use the exact value shown by that command. If the list does not include bbr2, the correct Ubuntu value remains bbr.

Test BBR Performance

Performance testing needs a before-and-after comparison from the same server, to the same remote endpoint, under similar network conditions. A simple curl command download test can show whether throughput changes, but it is not a benchmark by itself.

curl -L -o /dev/null -w 'Download speed: %{speed_download} bytes/sec\nTime total: %{time_total}s\n' https://speedtest.fremont.linode.com/100MB-fremont.bin

Run the test once under cubic, enable BBR, then run it again against the same file. The Linode Fremont endpoint above returns a 100 MB test file, which is large enough for a quick comparison without forcing a 1 GB download. For production systems, compare application logs, bandwidth graphs, or transfer-job timings over a longer window before deciding whether BBR improves the workload.

Latency also matters. Use ping against a relevant remote endpoint rather than only a nearby public service:

ping -c 10 speedtest.fremont.linode.com

If average latency is low, BBR may make little difference even when it is configured correctly. The clearest improvements usually appear on longer network paths or under sustained transfer load.

Firewall and Service Notes

BBR does not open ports, bypass packet filtering, or require UFW changes. It changes how the kernel paces TCP traffic after a connection exists. If the service itself needs inbound access, configure UFW firewall rules on Ubuntu separately.

The same separation applies to Nginx, SSH, media servers, and application stacks. BBR can change TCP behavior for their traffic, but it does not replace listener configuration, reverse-proxy tuning, TLS setup, or firewall policy.

Revert to Cubic

If BBR causes compatibility problems or does not help your workload, remove the dedicated sysctl file and restore Ubuntu’s common defaults. If you recorded a different original queue discipline earlier, substitute that value for fq_codel.

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

The sysctl commands confirm the active runtime values:

net.ipv4.tcp_congestion_control = cubic
net.core.default_qdisc = fq_codel

Verify the final state:

sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc

net.ipv4.tcp_congestion_control = cubic
net.core.default_qdisc = fq_codel

Troubleshooting BBR

BBR Is Missing After Applying sysctl

If sudo sysctl -p /etc/sysctl.d/99-bbr.conf does not activate BBR, load the module manually and apply the file again:

sudo modprobe tcp_bbr
sudo sysctl -p /etc/sysctl.d/99-bbr.conf

If a reboot later loses the module before sysctl applies, create a small modules-load file:

printf '%s\n' 'tcp_bbr' | sudo tee /etc/modules-load.d/bbr.conf

tcp_bbr

tcp_bbr Module Is Not Found

If modinfo -F filename tcp_bbr returns nothing or reports that the module is missing, update the system kernel through the normal Ubuntu package path:

sudo apt update
sudo apt upgrade

After rebooting into the updated kernel, check modinfo -F filename tcp_bbr again. If you are using a custom kernel that omits BBR, switch back to an Ubuntu kernel or use a kernel build that exposes BBR. Ubuntu users who need a newer packaged kernel can review the Ubuntu HWE kernel, XanMod kernel on Ubuntu, Liquorix kernel on Ubuntu, or Zabbly kernel on Ubuntu guides, but BBR itself does not require an alternate kernel on current Ubuntu LTS releases.

Settings Revert After Reboot

Check that the dedicated sysctl file still contains the two BBR lines:

cat /etc/sysctl.d/99-bbr.conf

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

If the file is missing, recreate it with the earlier printf command and rerun sudo sysctl -p /etc/sysctl.d/99-bbr.conf. If another sysctl file later overrides the same keys, search for duplicate settings with the grep command:

grep -R -E 'tcp_congestion_control|default_qdisc' /etc/sysctl.d/ /etc/sysctl.conf 2>/dev/null

Keep one intentional setting for each key. Multiple files that set the same sysctl can make the last-loaded file win and hide why BBR reverted.

No Noticeable Performance Gain

First confirm BBR is active, then compare the workload that matters. A nearby speed test, cached CDN response, or low-latency LAN transfer may show no difference. BBR is most useful when the bottleneck is a real wide-area TCP path, not a local disk, application limit, reverse proxy, or remote server cap.

Connection Problems After Enabling BBR

If an older appliance, middlebox, or application path behaves worse after enabling BBR, check recent kernel warnings and network errors before deciding whether to revert:

sudo journalctl -k --since "1 hour ago" | grep -Ei 'bbr|tcp_bbr|connection reset|connection timed out|timeout.*connection'

Temporarily switch back to cubic, repeat the affected transfer or application test, and compare the result. If cubic is more stable for that specific path, keep cubic on that system and reserve BBR for hosts where it improves real traffic.

Conclusion

Ubuntu enables BBR cleanly through a small sysctl configuration: net.core.default_qdisc=fq for pacing and net.ipv4.tcp_congestion_control=bbr for the TCP algorithm. After applying the file, verify both values, test only against comparable network paths, and keep the revert command nearby if a specific workload behaves better under cubic. For stock Ubuntu LTS kernels, use bbr; only use BBR2 if your running kernel explicitly lists bbr2 as available.