Tutorial de aceleração BBR para VPS 2025 - Saturar a largura de banda transfronteiriça em três passos

• Latência alta + perda de pacotes: Rotas transfronteiriças costumam ter 150ms de latência e 1%-3% de perda de pacotes. O TCP tradicional não dá conta: assim que há perda, a janela cai ao mínimo.
• Site travando: Abrir a biblioteca de mídia no painel do WordPress leva mais de dez segundos, e enviar um pacote de 200MB dá timeout direto.
• Streaming/proxy perdendo velocidade: Shadowsocks/Xray com configuração padrão começa a oscilar a partir de 20Mbps, principalmente em máquinas de baixo custo 1C1G, em que a CPU ainda não é o gargalo, mas a rede já caiu.

A lógica do BBR é medir o RTT e a largura de banda por conta própria, sem inferir congestionamento a partir da perda de pacotes, então consegue levar a velocidade ao máximo. Meu cenário mais comum é WordPress multisite + Cloudflare Tunnels; depois de trocar para BBR, fazer backup de 10GB de dados leva só 6 minutos, mais que o dobro da velocidade sem ele.

1. Veja o kernel do sistema: uname -r; recomenda-se 5.4 ou superior.
2. Confirme que o kernel tem BBR:

   sysctl net.ipv4.tcp_available_congestion_control
   

   A saída precisa incluir bbr ou bbr2.
3. Se o kernel 4.x do provedor de nuvem não atender, instale diretamente um kernel novo como linux-image-generic-hwe-22.04 e reinicie uma vez.

A seguir, usando Ubuntu 22.04 e Debian 12 como exemplos:

sudo apt update && sudo apt install -y --no-install-recommends ca-certificates
# 1. 确保系统已经加载 tcp_bbr 模块
sudo modprobe tcp_bbr
# 2. 写入 sysctl 配置
cat <<'CFG' | sudo tee /etc/sysctl.d/90-bbr.conf
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
CFG
# 3. 应用并验证
sudo sysctl --system
sysctl net.ipv4.tcp_congestion_control

Se a última linha retornar bbr, deu certo. Se um kernel antigo não tiver a fila fq, você pode trocar para fq_codel, mas ainda é recomendável atualizar o kernel.

sudo yum update -y
sudo grubby --update-kernel=ALL --args="net.core.default_qdisc=fq net.ipv4.tcp_congestion_control=bbr"
sudo reboot

Depois de reiniciar, rode sysctl net.ipv4.tcp_congestion_control novamente; deve mostrar bbr. Se continuar em cubic, muito provavelmente o pacote de kernel fornecido pelo provedor não tem BBR habilitado, então será preciso compilar você mesmo ou trocar para o kernel mainline do ELRepo.

• BBR2: Vem incluído no kernel 5.15+ e é mais estável em rotas transoceânicas no horário de pico da noite. Testei em um nó de Singapura: o BBR2 teve 5%-8% mais throughput que o BBR, mas com uso de CPU um pouco maior.
• BBR Plus/BBR modificado: Alguns scripts instalam essa versão; é verdade que é mais agressiva, mas também é mais propensa a ser classificada pela operadora como tráfego anômalo. Para sites em produção, a versão oficial continua sendo a opção mais segura.

Trocar para BBR2 é simples:

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr2

Lembre-se de persistir a alteração em /etc/sysctl.d/90-bbr.conf depois de editar.

1. Teste de velocidade local:

   iperf3 -c speedtest.serverius.net -P 4 -t 30
   

   Compare o throughput médio antes e depois do BBR.
2. Teste com carga real: Use curl -w"%{time_total}" -o /dev/null https://你的域名/备份.zip para ver o tempo de download.
3. Gráficos de monitoramento: Combine com Netdata/Prometheus para ver se a curva de largura de banda fica mais suave.

Esta é a minha comparação em várias máquinas:

• sysctl dá erro unknown key: Significa que o kernel não suporta fq ou bbr; atualize primeiro.
• Latência dispara depois de ativar: Em 80% dos casos, o servidor está rodando vários proxies ao mesmo tempo e a largura de banda está esgotada. Limite a velocidade de cada processo ou adicione QoS.
• Alterações do painel são sobrescritas: BaoTa/aaPanel gera seu próprio sysctl, então lembre-se de colocar a configuração do BBR em /etc/sysctl.d/, não apenas em /etc/sysctl.conf.
• O streaming continua travando: O BBR só otimiza TCP; o download depende da rede do usuário. Se o usuário estiver em 4G móvel, ainda vai ficar lento; HLS + resolução adaptativa é mais confiável.

• O datacenter já tem QoS limitando a velocidade por IP a 50Mbps; ativar o BBR não vai ultrapassar isso.
• Executar cargas muito sensíveis a latência (como trading de alta frequência); a estratégia de filas do BBR pode adicionar 5-10ms de latência.
• VPS somente IPv6 que atende navegadores convencionais via QUIC/HTTP3: o BBR não tem efeito e é preciso ajustar os parâmetros de quic.

Toda vez que compro um VPS novo, registro o processo "rodar baseline → ativar BBR → rodar de novo" em uma tabela no Notion. Com o BBR ativado, a grande maioria das rotas internacionais melhora o throughput em cerca de 3 vezes, especialmente em backups e sincronização de arquivos grandes; o tempo economizado não é nada desprezível.

Se você tiver problemas ao ativar o BBR, me envie a versão do sistema, o kernel e a saída de sysctl, e eu ajudo a diagnosticar.