ERR_HTTP2_PROTOCOL_ERROR: qué significa y cómo solucionarlo

¿Qué es ERR_HTTP2_PROTOCOL_ERROR?

ERR_HTTP2_PROTOCOL_ERROR es un error de Chrome y Edge que significa que el navegador recibió una respuesta HTTP/2 que rompió las reglas del protocolo. En Chromium es el error de red -337: "there is an HTTP/2 protocol error" (hay un error de protocolo HTTP/2). Chrome no tiene una página de error propia para este caso, así que ves la genérica: "No se puede acceder a este sitio", con un aviso de que la página web puede estar temporalmente inactiva o haberse trasladado de forma permanente a otra dirección web, y ERR_HTTP2_PROTOCOL_ERROR debajo.

HTTP/2 es la versión más rápida de HTTP que usan hoy la mayoría de los sitios HTTPS. Es más estricta que HTTP/1.1: las respuestas se dividen en tramas binarias, las cabeceras siguen reglas precisas y el tamaño declarado de una respuesta debe coincidir con lo que llega realmente. Cuando Chrome ve una respuesta que rompe esas reglas, por ejemplo una que se detiene a mitad de envío o que lleva una cabecera prohibida, trata toda la respuesta como mal formada y la descarta.

Los desarrolladores lo ven a menudo en la consola de DevTools como net::ERR_HTTP2_PROTOCOL_ERROR 200 (OK). Esa combinación es una pista clara: el servidor respondió 200, pero el cuerpo de la respuesta nunca llegó completo.

Qué considera HTTP/2 una respuesta mal formada

El estándar HTTP/2 (RFC 9113) enumera los errores que hacen que una respuesta esté mal formada, y un stream que se restablece antes de terminar también falla. Estos son los problemas que hay detrás de la mayoría de los errores reales:

¿Qué causa ERR_HTTP2_PROTOCOL_ERROR?

La mayoría de los casos vienen del lado del servidor, pero algunas cosas de tu propio equipo pueden dañar una respuesta mientras llega:

• En el servidor: respuestas cortadas a mitad de envío (un proxy que se queda sin espacio en disco o no puede escribir sus archivos temporales, una aplicación que se bloquea mientras envía datos, un tiempo de espera agotado), valores de Content-Length incorrectos, cabeceras prohibidas o no válidas, y una compatibilidad con HTTP/2 defectuosa en una configuración antigua del servidor o de la CDN.

• De tu lado: un antivirus o un firewall que inspecciona el tráfico HTTPS y reescribe las respuestas, extensiones del navegador que modifican peticiones o respuestas, una copia de la página dañada en la caché y, de vez en cuando, una versión desactualizada de Chrome.

Solución 1: haz una recarga forzada y prueba en modo incógnito

Pulsa Ctrl + Shift + R (Mac: Cmd + Shift + R) para recargar sin la caché. Una respuesta que se cortó una vez puede llegar bien en el siguiente intento.

Después abre la página en una ventana de incógnito (Ctrl + Shift + N; en Mac, Cmd + Shift + N). El modo incógnito no tiene cookies ni la caché de tu perfil normal, y las extensiones están desactivadas por defecto. Si la página carga ahí, la solución 2 o la 3 lo resolverán en tu ventana normal.

Solución 2: borra la caché y las cookies de ese sitio

Una copia en caché dañada o una cookie demasiado grande pueden provocar el error una y otra vez en un mismo sitio. Borra solo los datos de ese sitio: haz clic en el icono a la izquierda de la barra de direcciones → Cookies y datos de sitios (o Configuración del sitio) → elimina los datos y recarga. Para una limpieza más amplia, pulsa Ctrl + Shift + Supr y borra Imágenes y archivos almacenados en caché de los últimos días.

Solución 3: pausa el análisis HTTPS del antivirus y las extensiones

El software de seguridad que descifra e inspecciona el tráfico HTTPS se coloca en medio de cada conexión HTTP/2. Si su gestión de HTTP/2 tiene errores o está desactualizada, puede dejar pasar respuestas que Chrome considera mal formadas. Desactiva solo la función que analiza el HTTPS (suele llamarse análisis HTTPS, escudo web (Web Shield), filtrado de protocolos SSL/TLS o analizar conexiones cifradas) y recarga. Si eso lo soluciona, actualiza el antivirus y añade una exclusión para el sitio.

Después, desactiva todas las extensiones en chrome://extensions, recarga y vuelve a activarlas de una en una. Los bloqueadores de anuncios, las herramientas de privacidad y cualquier cosa que edite cabeceras son los sospechosos habituales.

Solución 4: actualiza Chrome y prueba otros navegadores

Abre chrome://settings/help para instalar cualquier actualización pendiente y luego reinicia el navegador. Después abre la misma página en Firefox o Safari. Si falla en todos, el sitio está roto y solo su propietario puede arreglarlo. Si solo fallan Chrome o Edge, normalmente sigue siendo cosa del sitio, porque Chrome es el más estricto al rechazar HTTP/2 mal formado, pero vale la pena repetir las soluciones 2 y 3.

Solución 5: prueba la página sin HTTP/2

Chrome se puede iniciar con HTTP/2 desactivado, lo que te dice con certeza si HTTP/2 es el problema. Primero cierra todas las ventanas de Chrome y luego inícialo desde una terminal:

# Windows (Símbolo del sistema)
"C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-http2

# macOS (Terminal)
open -a "Google Chrome" --args --disable-http2

Si la página carga en esa ventana, las respuestas HTTP/2 del sitio están mal formadas y el propietario tiene que corregirlas. Después, cierra Chrome y vuelve a abrirlo con normalidad. El flag solo se aplica a ese inicio.

Para propietarios de sitios web: cómo corregir los errores de protocolo HTTP/2

Si visitantes de distintas redes y navegadores informan del error, el problema está en tu infraestructura. Estas tres comprobaciones encuentran casi todos los casos.

1. Reprodúcelo con curl

# HTTP/2: fíjate en el final de la salida
curl -sv --http2 https://example.com/broken-page -o /dev/null
# Un stream roto termina con algo parecido a:
# HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
# (curl 8.19+: HTTP/2 stream 1 reset by server (error 0x1 PROTOCOL_ERROR))

# La misma URL con HTTP/1.1 para comparar
curl -sv --http1.1 https://example.com/broken-page -o /dev/null

Si HTTP/1.1 funciona y HTTP/2 falla, has confirmado el error. Compara las cabeceras de respuesta de los dos casos y fíjate en cuántos bytes llegan antes de que se rompa el stream. La herramienta Cabeceras HTTP también muestra las cabeceras que envía tu sitio vistas desde fuera de tu red.

2. Busca respuestas cortadas a mitad de envío

La causa más habitual en el lado del servidor es una respuesta que empieza (estado 200, cabeceras enviadas) y luego se detiene antes de tiempo. nginx guarda en archivos temporales las respuestas grandes que le llegan de tu aplicación, y si el disco está lleno o nginx no puede escribir en su carpeta temporal, la respuesta termina antes de tiempo y el navegador informa de un error de protocolo. Comprueba:

df -h                                   # ¿hay algún disco lleno?
sudo grep -E "No space left|Permission denied" /var/log/nginx/error.log | tail
ls -ld /var/lib/nginx/proxy /var/lib/nginx/fastcgi   # carpetas temporales en Debian/Ubuntu; el propietario debe coincidir con el usuario de nginx

Revisa también la propia aplicación: un proceso de PHP o Node que se bloquea, agota el tiempo de espera o alcanza un límite de memoria mientras envía una página grande o una descarga produce el mismo resultado. Los logs de la aplicación en torno a la hora del error suelen mostrarlo.

3. Corrige Content-Length y las cabeceras prohibidas

• Content-Length: deja que lo calcule el servidor. No lo fijes a mano en el código de la aplicación si un plugin, un middleware o el servidor web también comprime o modifica la salida, porque entonces la longitud declarada ya no coincide con los bytes enviados. En los sitios WordPress, una forma de que ocurra es fijar la longitud en el código PHP mientras un plugin o un ajuste de PHP también comprime la salida.

• Cabeceras específicas de la conexión: elimina el código que fija Connection, Keep-Alive, Transfer-Encoding o Upgrade en las respuestas. HTTP/2 las prohíbe y, aunque nginx elimina la mayoría por ti, algunos servidores de aplicaciones y proxies no lo hacen.

• Valores de cabecera: asegúrate de que ninguna cabecera contiene un salto de línea o un carácter de control. Esto suele venir de datos introducidos por el usuario que acaban en una cabecera, como un nombre de archivo en Content-Disposition.

• CDN delante: si usas Cloudflare u otra CDN, prueba el servidor de origen directamente (con la opción --resolve de curl o una entrada en el archivo hosts) para saber si el error viene del origen o de la CDN.

ERR_HTTP2_PROTOCOL_ERROR frente a errores similares

Guías detalladas: ERR_QUIC_PROTOCOL_ERROR, ERR_SSL_PROTOCOL_ERROR, ERR_CONNECTION_CLOSED y ERR_EMPTY_RESPONSE. Para revisar desde fuera el certificado y la configuración HTTPS de un sitio, usa el Verificador de Certificado SSL.