Tutorial de aceleración BBR para VPS 2025 - Satura el ancho de banda transfronterizo en tres pasos

• Latencia alta + pérdida de paquetes: Las rutas transfronterizas suelen tener 150ms de latencia y 1%-3% de pérdida de paquetes. El TCP tradicional no puede con eso: en cuanto hay pérdida, baja la ventana al mínimo.
• Sitios que se traban: Abrir la biblioteca de medios en el panel de WordPress tarda más de diez segundos, y subir un paquete de 200MB directamente da timeout.
• Streaming/proxy que pierden velocidad: Shadowsocks/Xray con la configuración predeterminada empieza a fallar a los 20Mbps, sobre todo en máquinas de bajos recursos 1C1G, donde la CPU aún no es el cuello de botella pero la red ya se cayó.

La lógica de BBR es medir el RTT y el ancho de banda por sí mismo, sin inferir la congestión a partir de la pérdida de paquetes, así que puede llevar la velocidad al máximo. Mi escenario habitual es WordPress multisitio + Cloudflare Tunnels; tras cambiar a BBR, hacer copia de seguridad de 10GB de datos tarda solo 6 minutos, más del doble de rápido que sin él.

1. Mira el kernel del sistema: uname -r; se recomienda 5.4 o superior.
2. Confirma que el kernel incluye BBR:

   sysctl net.ipv4.tcp_available_congestion_control
   

   La salida debe incluir bbr o bbr2.
3. Si el kernel 4.x del proveedor cloud no cumple, instala directamente un kernel nuevo como linux-image-generic-hwe-22.04 y reinicia una vez.

A continuación, con Ubuntu 22.04 y Debian 12 como ejemplos:

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

Si la última línea devuelve bbr, funcionó. Si un kernel antiguo no tiene la cola fq, puedes cambiar a fq_codel, pero sigue siendo recomendable actualizar el kernel.

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

Después de reiniciar, ejecuta de nuevo sysctl net.ipv4.tcp_congestion_control; debería mostrar bbr. Si sigue en cubic, lo más probable es que el paquete de kernel del proveedor no tenga BBR habilitado, así que tendrás que compilarlo tú mismo o cambiar al kernel mainline de ELRepo.

• BBR2: Viene incluido en el kernel 5.15+ y es más estable en rutas transoceánicas durante la hora pico nocturna. Lo probé en un nodo de Singapur: BBR2 dio un 5%-8% más de rendimiento que BBR, pero con un uso de CPU algo mayor.
• BBR Plus/BBR modificado: Algunos scripts lo instalan; es cierto que es más agresivo, pero también más propenso a que el operador lo marque como tráfico anómalo. Para sitios en producción, la versión oficial sigue siendo la opción más segura.

Cambiar a BBR2 es sencillo:

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr2

Recuerda persistir el cambio en /etc/sysctl.d/90-bbr.conf después de editarlo.

1. Prueba de velocidad local:

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

   Compara el rendimiento medio antes y después de BBR.
2. Prueba con carga real: Usa curl -w"%{time_total}" -o /dev/null https://你的域名/备份.zip para ver el tiempo de descarga.
3. Gráficas de monitorización: Combínalo con Netdata/Prometheus para ver si la curva de ancho de banda es más suave.

Esta es mi comparación en varias máquinas:

• sysctl da error unknown key: Significa que el kernel no soporta fq o bbr; actualízalo primero.
• La latencia se dispara tras activarlo: En el 80% de los casos, el servidor ejecuta varios proxies a la vez y el ancho de banda está agotado. Limita la velocidad de cada proceso o añade QoS.
• Los cambios del panel se sobrescriben: BaoTa/aaPanel genera su propio sysctl, así que recuerda poner la configuración de BBR en /etc/sysctl.d/, no solo en /etc/sysctl.conf.
• El streaming sigue trabándose: BBR solo optimiza TCP; la descarga depende de la red del usuario. Si el usuario está en 4G móvil, seguirá lento; HLS + resolución adaptativa es más fiable.

• El centro de datos ya tiene QoS que limita la velocidad por IP a 50Mbps; activar BBR no lo superará.
• Ejecutar cargas muy sensibles a la latencia (como trading de alta frecuencia); la estrategia de colas de BBR puede añadir 5-10ms de latencia.
• VPS solo IPv6 que sirve a navegadores convencionales por QUIC/HTTP3: BBR no tiene efecto y hay que ajustar los parámetros de quic.

Cada vez que compro un VPS nuevo, registro el proceso "ejecutar referencia → activar BBR → ejecutar de nuevo" en una tabla de Notion. Con BBR activado, la gran mayoría de las rutas internacionales mejora el rendimiento unas 3 veces, sobre todo en copias de seguridad y sincronización de archivos grandes; el tiempo ahorrado no es nada despreciable.

Si tienes problemas al activar BBR, pégame la versión del sistema, el kernel y la salida de sysctl, y te ayudo a diagnosticarlo.