Nginx con HTTP/3 y QUIC en 2026: cuándo activarlo y cuándo no merece la pena

El protocolo que llevaba años en "experimental"

Hace dos años, cuando un cliente preguntaba si podíamos activar HTTP/3 en su Nginx, la respuesta honesta era "podemos, pero no lo recomendamos para producción". El módulo ngx_http_v3_module aterrizó en Nginx 1.25.0 en junio de 2023 marcado como experimental, y eso quería decir lo que solía querer decir: funciona en demos y rompe en cosas concretas que no te apetece descubrir un martes por la tarde.

En 2026 la conversación ha cambiado. Con Nginx 1.26.x y OpenSSL 3.5.x o BoringSSL/quiche, HTTP/3 sobre QUIC se considera production-ready en el sentido en el que se usa la palabra entre administradores de sistemas: lo activas, lo monitorizas un par de semanas y dejas de pensar en ello.

Vamos a ver cuándo merece la pena la mudanza, cómo se hace y qué cosas siguen pinchando.

Qué te llevas con HTTP/3 (en una página)

QUIC reemplaza a TCP por debajo y reescribe el contrato con la red:

• Conexión en 1-RTT (o 0-RTT en reconexión). Frente a TCP + TLS, que pide tres apretones de mano para servir el primer byte.
• Sin head-of-line blocking entre streams: si se pierde un paquete que afecta a la imagen del logo, el HTML del artículo no se queda esperando.
• Migración de conexión transparente: el móvil cambia de Wi-Fi a 4G y la sesión TLS no se rompe. Igual que pasaba con HTTP/2 corriendo sobre TCP… excepto que con TCP esa migración nunca funcionó del todo.
• Cifrado por defecto: QUIC no permite tráfico en claro. Suena obvio en 2026, pero impone una higiene de certificados que muchos servidores no tienen.

Lo que no te lleva HTTP/3:

• No es magia para sites lentos en backend. Si el cuello de botella está en PHP-FPM o en la base de datos, HTTP/3 no toca esa parte.
• No te quita HTTP/2. De hecho, lo recomendable es servir los dos: HTTP/2 sobre TCP/443 y HTTP/3 sobre UDP/443, y dejar que el cliente negocie.

Cuándo activarlo (y cuándo seguir con HTTP/2)

Activarlo sí merece la pena cuando:

• Tienes tráfico móvil significativo. Es el escenario donde QUIC marca diferencia visible en métricas reales.
• Sirves un sitio internacional con clientes en redes inestables.
• Tu Core Web Vitals está justo al borde y necesitas arañar décimas en LCP/INP.

Activarlo NO merece la pena si:

• El servidor es una VPS chiquita con poco margen de CPU. QUIC saca trabajo del kernel (TCP) y lo mete en espacio de usuario (QUIC). La factura computacional es real: en cargas altas, Nginx hace más trabajo sirviendo HTTP/3 que HTTP/2 para el mismo número de peticiones.
• Tienes un firewall corporativo intermedio que filtra UDP/443. Sí, pasa más de lo que parece — sobre todo en redes empresariales con SD-WAN sin actualizar.
• Tu CDN delante ya hace HTTP/3 hasta el cliente. En ese caso el HTTP/2 origen-CDN no necesita upgrade.

Activarlo paso a paso

1. Verificar versiones

nginx -V 2>&1 | grep -oE 'OpenSSL [0-9.]+'   # OpenSSL 3.5.1 o superior
nginx -V 2>&1 | grep ngx_http_v3              # debe aparecer

Si no aparece ngx_http_v3_module, tu paquete no se compiló con HTTP/3. En Debian 13 viene desde el paquete oficial; en Ubuntu 24.04 LTS hay que tirar de PPA oficial de Nginx (nginx.org/packages/ubuntu) o recompilar. Ojo: la versión que viene en apt de Ubuntu 22.04 todavía no incluye el módulo en muchos repos derivados.

2. Configurar el server block

Bloque mínimo funcional para un dominio con TLS ya servido:

server {
    # HTTP/2 sobre TCP (mantener)
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    # HTTP/3 sobre QUIC
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;
    http3 on;
    http3_hq off;

    # Anunciar disponibilidad de HTTP/3 al cliente
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    server_name www.miweb.es miweb.es;

    ssl_certificate     /etc/letsencrypt/live/miweb.es/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/miweb.es/privkey.pem;
    ssl_protocols       TLSv1.3;       # QUIC requiere TLS 1.3
    ssl_early_data on;                  # opcional, habilita 0-RTT

    root /var/www/miweb;
    index index.html;
}

Puntos críticos:

• reuseport solo en el primer listen ... quic. Sin él, varios workers de Nginx no pueden compartir el mismo puerto UDP eficientemente.
• Alt-Svc es el mecanismo por el que el navegador descubre que tienes HTTP/3. La primera petición sigue siendo HTTP/2; a partir de la segunda, el navegador prueba QUIC. Sin la cabecera, no pasas a HTTP/3 jamás.
• TLS 1.3 obligatorio. Si tu config tiene TLSv1.2 activo solo para HTTP/2, está bien — QUIC ignora esa parte.

3. Abrir el firewall

Esto se olvida más de lo que parece:

sudo ufw allow 443/udp     # Ubuntu/Debian
sudo firewall-cmd --permanent --add-port=443/udp && sudo firewall-cmd --reload  # RHEL family

Si estás detrás de un balanceador (HAProxy, AWS NLB, etc.), el balanceador tiene que reenviar UDP/443. Muchos LBs de los proveedores cloud solo balancean TCP por defecto. Sin abrir UDP/443 en el camino completo, HTTP/3 no llega al servidor.

4. Recargar y verificar

sudo nginx -t
sudo systemctl reload nginx

Test desde fuera:

curl --http3 -I https://miweb.es

Si ves HTTP/3 200, va. Si ves HTTP/2 200, el servidor responde pero el cliente no pidió HTTP/3 (revisa curl con --http3-only para forzar y diagnosticar).

Test desde navegador: Chrome o Firefox → DevTools → Network → columna "Protocol" debe mostrar h3 en la segunda recarga (la primera siempre será h2 por la negociación de Alt-Svc).

Casos en producción que hemos visto

Algunos números reales de los últimos seis meses, sin endulzar:

• Site de comercio electrónico mediano, ~80% tráfico móvil: LCP -8% medido en Chrome UX Report tras activar HTTP/3. Bonito. No revolucionario.
• Site corporativo, tráfico mayoritariamente desktop con fibra: diferencia inapreciable. La negociación Alt-Svc añade un par de bytes a la primera respuesta y poco más.
• Site internacional con clientes en Latinoamérica y África: mejora de 200-400ms en TTFB en redes con latencia alta. Aquí sí se nota.
• VPS pequeña (1 vCPU, 2 GB RAM) sirviendo blog estático con picos esporádicos: CPU subió un 6% de media, sin beneficio visible. Lo volvimos a desactivar.

Moraleja: medir antes y después, no asumir.

Cosas que siguen siendo molestas

• reuseport requiere kernel reciente (4.5+). Cualquier servidor con kernel actualizado lo tiene, pero comprueba si estás en una distro antigua.
• Algunos CDNs intermedios todavía no hablan HTTP/3 entre origin y edge. Si tienes Cloudflare delante, el cliente sí ve HTTP/3 (porque lo hace Cloudflare) y el upgrade en origen no aporta nada.
• Diagnóstico más opaco: capturar tráfico QUIC no es como capturar TCP. Necesitas Wireshark reciente, SSLKEYLOGFILE y paciencia. Si vienes de depurar HTTP/2 con tcpdump, prepárate.
• Las herramientas legacy (curl viejo, wget, ciertos clientes de monitorización) no hablan HTTP/3. Asegúrate de que el Alt-Svc no rompe tu pipeline de monitorización.

¿Lo activamos en tu servidor?

Nuestro consejo en una frase: si tienes tráfico móvil significativo y kernel + Nginx recientes, sí. Si no, espera al siguiente refresco de servidor y hazlo entonces. No es un cambio que arregle ningún problema; es un cambio que añade margen donde antes no había.

Si quieres que lo evaluemos para tu caso, hablamos. La activación en sí lleva una hora; la auditoría previa para no romper monitorización ni firewalls, otra. Lo demás es medir.

Referencias

• Support for QUIC and HTTP/3 — Nginx Documentation
• Our Roadmap for QUIC and HTTP/3 Support in NGINX — NGINX Community Blog