Dominando QUIC y HTTP/3 con Nginx: La Guía Completa

La web ha dependido de TCP durante más de cuatro décadas. Pero las aplicaciones modernas —con sus exigencias de interactividad en tiempo real, conectividad móvil y cargas de página instantáneas— han expuesto las limitaciones fundamentales de TCP. Llegan QUIC y HTTP/3: una reinvención completa del transporte web que abandona TCP en favor de UDP para ofrecer un internet más rápido, seguro y resiliente.

En esta guía completa, exploraremos la historia y la arquitectura de QUIC, entenderemos por qué resuelve problemas que TCP no puede, y recorreremos una configuración completa de Nginx lista para producción.

Cómo lo ejecuto en mi propia infraestructura

jmrp.io sirve HTTP/3 en sí mismo: los dos server blocks en producción llevan listen 443 quic; junto a los listeners TCP habituales, de modo que el sitio acepta conexiones QUIC y TLS-sobre-TCP en paralelo, según lo que soporte realmente el cliente — y lo que haya entre el cliente y el servidor.

No me fié de la palabra de la cabecera Alt-Svc. Ejecutar curl --http3 directamente contra el sitio en vivo devuelve HTTP/3 200: un handshake QUIC completado, no una inferencia sacada de una cabecera de respuesta que un servidor mal configurado podría seguir enviando mientras cae en silencio a HTTP/2 por debajo. Esa distinción importa — muchas listas de comprobación de “HTTP/3 activado” se quedan en la cabecera y nunca confirman que el protocolo se negoció de verdad. Es un detalle pequeño de verificar, y también es la única forma de saber que un despliegue QUIC es real y no aspiracional: la cabecera no cuesta nada añadir, pero solo un handshake desde el lado del cliente demuestra que UDP/443 está realmente abierto y negociando de extremo a extremo.

Servir HTTP/3 y que se use son dos preguntas distintas, y solo la segunda necesita datos. jmrp.io está detrás de Cloudflare, que termina la conexión del cliente, así que el protocolo que negocia de verdad un visitante aparece en la analítica de zona de Cloudflare y no en mi propio log de acceso. En ocho días —del 19 al 27 de agosto de 2026, filtrando por el host jmrp.io para que el resto de la zona no lo tape— HTTP/3 se llevó el 33,5 % de las peticiones que negociaron HTTP/2 o HTTP/3: 11.208 de 33.411.

Ese denominador pide dos frases de defensa, porque la versión honesta de esta medición va sobre todo de lo que hay que tirar. Excluí HTTP/1.1 por completo, y la exclusión no es cosmética: los navegadores actuales acuerdan h2 por ALPN contra Cloudflare, así que una petición que dice ser un navegador y aun así llega por HTTP/1.1 es casi siempre un scraper con el user-agent falseado. Y había unos cuantos: un cubo de «Chrome de escritorio» salía con un 45,8 % de HTTP/1.1, que es algo que Chrome de escritorio no hace. Quitar HTTP/1.1 elimina las falsificaciones evidentes, pero no garantiza que el resto esté limpio: el plan Free no expone puntuación de bot, y la dimensión del navegador se deduce del propio user-agent, de modo que no queda ningún campo independiente por el que filtrar. Por eso tampoco hay aquí una tabla de adopción por navegador: no voy a publicar porcentajes por familia construidos sobre un denominador que no puedo auditar. La ventana son ocho consultas encadenadas de 24 horas, el rango más largo que devuelve ese plan, con lo que arrastra ocho costuras de dos minutos: unos 16 minutos ausentes en total.

Dos cosas sobre esa cifra. La primera es que es una instantánea de esa ventana, no una propiedad estable del sitio. La misma consulta sobre los siete días UTC completos del 26 de agosto al 1 de septiembre de 2026 da un 20,1 % —10.508 de 52.341— y oscila de un día a otro:

La segunda es que ninguna de las dos lecturas se puede recalcular después. El plan Free retiene httpRequestsAdaptiveGroups ocho días en ventana deslizante y rechaza cualquier consulta más antigua con cannot request data older than 1w1d, así que ambas cifras son observaciones fechadas que la propia fuente no volverá a servir. La tabla está aquí por eso, y publica los dos recuentos y no solo el porcentaje diario, porque los porcentajes por sí solos no bastarían: el día con más tráfico casi duplica al más tranquilo, así que las siete cuotas redondeadas no permiten reconstruir el 20,1 % ponderado —su media sin ponderar es del 20,4 %—. Con cada numerador y cada denominador en la página, el total es aritmética que cualquiera puede comprobar.

Un detalle medido que no esperaba. Mi origen sí envía la cabecera que esta guía te dice que añadas —add_header Alt-Svc 'h3=":443"; ma=86400' always; está en los dos server blocks TLS, y una petición directa al origen vuelve con ella—. A través de Cloudflare, esa cabecera sencillamente no está:

En la propia máquina de origen, saltándose el CDN por completo:$ curl -sS -kD- -o /dev/null -H 'Host: jmrp.io' https://127.0.0.1/
alt-svc: h3=":443"; ma=86400
$ curl -sS -D- -o /dev/null --resolve jmrp.io:443:104.21.40.251 https://jmrp.io/
server: cloudflare
(sin cabecera alt-svc en la respuesta)
$ dig +short HTTPS jmrp.io @1.1.1.1
1 . alpn="h3,h2" ipv4hint=104.21.40.251,172.67.158.146 ech=…

QUIC funciona igualmente, como ya demostraba el handshake de antes, porque el anuncio vive en otro sitio: el registro DNS HTTPS del dominio lleva alpn="h3,h2", y los navegadores que resuelven ese registro se enteran de HTTP/3 antes de abrir una sola conexión. Esto es comportamiento de Cloudflare en toda su plataforma, no una particularidad de mi configuración — el edge termina la conexión y decide por su cuenta qué anuncia, y nada de mi configuración de Nginx puede cambiarlo. La lección práctica es estrecha pero vale: si tienes un CDN delante del origen que configuraste para HTTP/3, la cabecera que estás comprobando puede no ser la que ven tus visitantes. Mira también el registro DNS.

¿Por qué QUIC sustituyó a TCP en HTTP/3?

El protocolo QUIC tiene una evolución interesante desde un experimento propietario de Google hasta un estándar IETF completo.

La familia de RFCs de QUIC

La especificación completa de QUIC abarca múltiples RFCs:

¿Por qué QUIC? Entendiendo las limitaciones de TCP

Para apreciar QUIC, debemos entender por qué TCP —la columna vertebral de internet desde 1974— tiene dificultades con las demandas modernas de la web.

¿Qué es el head-of-line (HOL) blocking?

Este es el problema fundamental que QUIC resuelve. Imagina una autopista con un solo carril (conexión TCP). Si un coche se avería (pérdida de paquete), todos los que van detrás deben parar y esperar, aunque vayan a destinos diferentes.

El problema de la latencia del handshake

Establecer una conexión TCP segura requiere múltiples viajes de ida y vuelta:

El problema de la migración de conexión

Las conexiones TCP se identifican por una 4-tupla: (IP origen, puerto origen, IP destino, puerto destino). Cuando cambias de Wi-Fi a datos móviles, tu IP cambia — y tu conexión TCP se rompe.

Arquitectura de QUIC en profundidad

Transporte sobre UDP

QUIC se construye sobre UDP en lugar de crear un nuevo protocolo IP. Fue una elección pragmática:

• No requiere cambios en el kernel: UDP tiene soporte universal
• Implementación en espacio de usuario: Iteración y despliegue más rápidos
• Traversal de middleboxes: UDP atraviesa la mayoría de NATs y firewalls

Estructura de paquetes

QUIC utiliza dos tipos de paquetes:

Streams y control de flujo

Los streams QUIC son canales ligeros y multiplexados dentro de una conexión:

Decodificación del Stream ID: El Stream ID es un entero de 62 bits donde los 2 bits menos significativos funcionan como cabecera de tipo:

• Bit 0 (Iniciador): 0 = Cliente, 1 = Servidor
• Bit 1 (Dirección): 0 = Bidireccional, 1 = Unidireccional

Esto crea 4 espacios de direcciones distintos:

• …00: Petición/Respuesta del cliente
• …01: Server Push (obsoleto)
• …10: Stream de control del cliente
• …11: Stream de control del servidor (QPACK)

Control de flujo de doble capa: Para que un paquete sea procesado, debe pasar dos comprobaciones independientes:

1. Nivel de conexión: ¿Hay crédito MAX_DATA para toda la conexión?
2. Nivel de stream: ¿Hay crédito MAX_STREAM_DATA para este stream específico? Si cualquiera se agota, la transmisión se bloquea hasta que llegue un frame WINDOW_UPDATE.

El handshake de QUIC: velocidad y seguridad

QUIC combina los handshakes de transporte y criptográficos en un único intercambio, reduciendo drásticamente la latencia.

Handshake 1-RTT (primera conexión)

Handshake 0-RTT (conexión reanudada)

Para clientes que se han conectado previamente, QUIC permite enviar datos cifrados en el primer paquete:

Arquitectura de seguridad

La seguridad de QUIC no es opcional —está integrada en el protocolo desde su diseño.

Cuatro niveles de cifrado

Protección de paquetes

Cada paquete QUIC (excepto Initial) está protegido con cifrado AEAD:

Connection ID y privacidad

Mecanismos de protección contra DoS

QUIC incluye varias medidas anti-amplificación y anti-suplantación:

1. Validación de dirección: Los servidores envían paquetes RETRY para validar las direcciones de los clientes
2. Anti-amplificación: Los servidores limitan los datos enviados antes de la validación de dirección (3x los datos del cliente)
3. Stateless Reset: Terminación limpia de conexión sin estado

HTTP/3: HTTP sobre QUIC

HTTP/3 es el mapeo de la semántica HTTP sobre el transporte QUIC. Reemplaza el framing binario de HTTP/2 con streams QUIC.

¿Quién usa HTTP/3 hoy?

A fecha de 2026, la adopción de HTTP/3 es significativa y creciente:

Configuración de Nginx: guía completa

Ahora vamos a implementar HTTP/3 en Nginx. Esta sección cubre todo, desde los prerrequisitos hasta el despliegue en producción.

Prerrequisitos

Verifica tu instalación de Nginx:

nginx version: nginx/1.28.0
built with OpenSSL 3.5.0 8 Apr 2025 (running with OpenSSL 3.5.4 30 Sep 2025)
configure arguments: … --with-http_v3_module …

sudo apt install curl gnupg2 ca-certificates
DISTRO=$(. /etc/os-release && echo "$ID")
CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")

# Clave de firma de Nginx en su propio llavero
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://nginx.org/keys/nginx_signing.key -o /tmp/nginx.key

# Contrasta las huellas con la lista que publica nginx en
# https://nginx.org/en/pgp_keys.html ANTES de confiar en la clave. El
# paquete lleva varias claves y rotan, así que compara la salida y no un
# número copiado de un artículo.
gpg --show-keys --with-fingerprint /tmp/nginx.key

sudo gpg --dearmor -o /etc/apt/keyrings/nginx.gpg /tmp/nginx.key

# Repositorio mainline, restringido a ese llavero
echo "deb [signed-by=/etc/apt/keyrings/nginx.gpg] https://nginx.org/packages/mainline/$DISTRO $CODENAME nginx" \
    | sudo tee /etc/apt/sources.list.d/nginx.list

sudo apt update && sudo apt install nginx

# Comprobar la compilación que acabas de instalar
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'http_v3|OpenSSL'

openssl version   # 3.5.0 o superior

wget https://nginx.org/download/nginx-1.31.4.tar.gz
tar xzf nginx-1.31.4.tar.gz
cd nginx-1.31.4

./configure \
    --with-http_v3_module \
    --with-http_ssl_module \
    --with-http_v2_module

make -j"$(nproc)"
sudo make install

Configuración básica

Esta es la configuración mínima para habilitar HTTP/3:

server {
    server_name example.com;
    root /var/www/example.com;

    # ==========================================
    # LISTENERS: TCP (HTTP/1.1, HTTP/2) + UDP (HTTP/3)
    # ==========================================
    
    # Standard HTTPS over TCP
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    
    # QUIC/HTTP/3 over UDP
    # 'reuseport' is critical for multi-worker performance
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    # ==========================================
    # SSL/TLS CONFIGURATION
    # ==========================================
    
    # TLS 1.3 is REQUIRED for QUIC
    ssl_protocols TLSv1.3 TLSv1.2;
    ssl_prefer_server_ciphers off;
    
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ==========================================
    # HTTP/3 CONFIGURATION
    # ==========================================
    
    http3 on;
    
    # Advertise HTTP/3 support to browsers
    # ma=86400 means "cache this info for 24 hours"
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    location / {
        try_files $uri $uri/ =404;
    }
}

Configuración completa de producción

Aquí tienes una configuración exhaustiva con todas las optimizaciones. La configuración se divide en dos archivos: el nginx.conf principal para ajustes globales y un archivo de configuración específico del sitio.

# Main context
worker_processes auto;
error_log /var/log/nginx/error.log warn;

events {
    worker_connections 4096;
    use epoll;
    multi_accept on;
}

http {
    # ==========================================
    # HTTP/3 GLOBAL SETTINGS
    # ==========================================
    # Explicit for clarity (http3 defaults to 'on' in nginx 1.25.0+)
    http3 on;
    
    # Custom log format to track HTTP/3 connections
    log_format quic '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" '
                    'proto="$server_protocol" quic="$http3"';

    # MIME types
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # Performance optimizations
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    
    # Gzip compression
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_types text/plain text/css application/json application/javascript 
               text/xml application/xml application/xml+rss text/javascript;

    # Include site configurations
    include /etc/nginx/sites-enabled/*;
}

La configuración específica del sitio incluye todas las directivas para QUIC, TLS, cabeceras y logging:

server {
    server_name example.com www.example.com;
    root /var/www/example.com;

    # ==========================================
    # DUAL-STACK LISTENERS
    # ==========================================
    
    # TCP: HTTP/1.1 and HTTP/2 fallback
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    
    # UDP: QUIC/HTTP/3
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    # ==========================================
    # TLS CONFIGURATION (Required for QUIC)
    # ==========================================
    
    ssl_protocols TLSv1.3 TLSv1.2;
    # TLS 1.3 ciphersuites (handled separately for better OpenSSL compatibility)
    ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
    # TLS 1.2 ciphers only (ECDHE for forward secrecy)
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;
    ssl_ecdh_curve X25519:P-256:P-384;
    
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    
    # Session resumption for performance
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;  # Better security
    
    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;

    # ==========================================
    # QUIC-SPECIFIC SETTINGS
    # ==========================================
    
    # Enable 0-RTT early data (with security considerations)
    ssl_early_data on;
    
    # DoS protection: require address validation
    quic_retry on;
    
    # Performance: Generic Segmentation Offload (Linux 4.18+)
    quic_gso on;

    # ==========================================
    # HEADERS
    # ==========================================
    
    # Advertise HTTP/3 availability
    add_header Alt-Svc 'h3=":443"; ma=86400' always;
    
    # Warn backends about 0-RTT replay risk
    add_header Early-Data $ssl_early_data always;
    
    # Security headers
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "DENY" always;

    # ==========================================
    # LOGGING
    # ==========================================
    
    access_log /var/log/nginx/example.com.access.log quic;
    error_log /var/log/nginx/example.com.error.log;

    # ==========================================
    # LOCATIONS
    # ==========================================
    
    location / {
        try_files $uri $uri/ =404;
    }
    
    # Static assets with long cache
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2)$ {
        expires 1y;
        add_header Cache-Control "public, immutable" always;
        add_header Alt-Svc 'h3=":443"; ma=86400' always;
        
        # Security headers (inherited from server block may not apply with add_header in location)
        add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header X-Frame-Options "DENY" always;
    }
}

# HTTP to HTTPS redirect
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Referencia de todas las directivas QUIC

Configuración del firewall

Crítico: HTTP/3 usa UDP en el puerto 443, no TCP. Si tu firewall solo permite TCP/443, QUIC fallará silenciosamente y los clientes retrocedarán a HTTP/2.

# Check current rules
sudo ufw status

# Allow UDP on port 443
sudo ufw allow 443/udp comment 'QUIC/HTTP3'

# Verify
sudo ufw status verbose

# Allow incoming UDP 443
sudo iptables -A INPUT -p udp --dport 443 -j ACCEPT

# Save rules (Debian/Ubuntu)
sudo iptables-save | sudo tee /etc/iptables/rules.v4

# For IPv6
sudo ip6tables -A INPUT -p udp --dport 443 -j ACCEPT
sudo ip6tables-save | sudo tee /etc/iptables/rules.v6

# Add UDP 443 to default zone
sudo firewall-cmd --permanent --add-port=443/udp

# Reload
sudo firewall-cmd --reload

# Verify
sudo firewall-cmd --list-ports

Ajuste del kernel para alto tráfico

Para servidores con alto tráfico, aumenta los tamaños de buffer UDP:

# Increase UDP buffer sizes for QUIC
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576

# UDP memory limits
net.ipv4.udp_mem = 65536 131072 262144
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192

# Allow more local ports for connections
net.ipv4.ip_local_port_range = 1024 65535

Aplica los ajustes:

Verificación y pruebas

Tras la configuración, verifica que HTTP/3 funciona correctamente.

Método 1: curl

Las versiones modernas de curl (7.66+ con soporte HTTP/3) permiten probar directamente:

HTTP/3 200
server: jmrp.io
date: Wed, 14 Jan 2026 20:02:32 GMT
content-type: text/html; charset=utf-8
alt-svc: h3=":443"; ma=86400
strict-transport-security: max-age=63072000; includeSubDomains; preload

Método 2: DevTools del navegador

1. Abre Chrome o Firefox
2. Navega a tu sitio
3. Abre DevTools (F12) → pestaña Red (Network)
4. Haz clic derecho en las cabeceras de columna → Activa la columna Protocolo
5. Recarga la página
6. Busca h3 en la columna Protocolo

Método 3: herramientas online

Método 4: comprobar los logs de Nginx

Usa el formato de log personalizado para verificar el tráfico HTTP/3:

192.168.1.100 - - [14/Jan/2026:20:02:32 +0000] "GET / HTTP/3" 200 15234 "-" "Mozilla/5.0…" proto="HTTP/3" quic="h3"

Guía de resolución de problemas

Modo depuración

Activa el logging de depuración temporalmente:

error_log /var/log/nginx/error.log debug;

Comprueba los mensajes específicos de QUIC:

2026/01/14 10:42:15 [debug] 12345#0: *1 quic handle packet: fd:16, addr:192.0.2.1:54321
2026/01/14 10:42:15 [debug] 12345#0: *1 quic packet rx dcid len:8 87654321
2026/01/14 10:42:15 [debug] 12345#0: *1 quic packet rx scid len:8 12345678
2026/01/14 10:42:15 [info] 12345#0: *1 quic SSL_do_handshake() failed: SSL_ERROR_SSL: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown
2026/01/14 10:42:15 [debug] 12345#0: *1 quic close connection: 0:

Lista de verificación para producción

Antes de desplegar HTTP/3 en producción, verifica:

¿Cuándo NO deberías usar QUIC?

Aunque QUIC ofrece beneficios significativos, hay escenarios donde TCP puede ser preferible: