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 flujo HTTP/2 que lleva la página falló: el servidor lo reinició antes de terminar o envió cabeceras que el navegador rechaza. En Chromium es el error de red -337: «There is an HTTP/2 protocol error» (net_error_list.h). 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. Edge muestra el mismo código en su propia pantalla de error.

HTTP/2 es la versión más rápida de HTTP que usan hoy la mayoría de los sitios HTTPS. Cada petición viaja en su propio flujo dentro de una única conexión, y cualquiera de las dos partes puede cancelar un flujo con un reinicio. Chrome informa de cualquier reinicio del servidor como un error de protocolo, sea cual sea el motivo del servidor, y además cancela un flujo por su cuenta cuando las cabeceras rompen las reglas de HTTP/2 (una cabecera Transfer-Encoding, mayúsculas en el nombre de una cabecera, un estado ausente).

Los desarrolladores suelen verlo en la consola de DevTools como net::ERR_HTTP2_PROTOCOL_ERROR 200 (OK). Esa combinación es una pista clara: las cabeceras eran válidas y el servidor respondió 200, pero el flujo falló mientras llegaba el cuerpo.

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. Son los problemas que hay detrás de la mayoría de los errores reales, y así llega cada uno al navegador:

¿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: una respuesta que el servidor o el proxy no puede terminar (un proxy que se queda sin espacio en disco o no puede escribir sus archivos temporales, una aplicación que falla mientras transmite, un tiempo de espera agotado), valores de Content-Length incorrectos que hacen que el proxy de delante se rinda, cabeceras prohibidas o no válidas y un soporte de HTTP/2 defectuoso en un servidor o una configuración de CDN antiguos.
• Por tu parte: antivirus o cortafuegos que inspecciona el HTTPS y reescribe el tráfico, extensiones del navegador que modifican peticiones o respuestas, una petición que el servidor procesa mal (por ejemplo, cookies demasiado grandes) y, de vez en cuando, una versión de Chrome obsoleta.

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 las cookies y los archivos en caché de ese sitio

Borrar las cookies y los archivos en caché del sitio cambia la petición que envía Chrome (menos cookies y ninguna copia en caché que revalidar), lo que puede evitar un fallo del servidor. Haz clic en Ver información del sitio, a la izquierda de la barra de direcciones → Cookies y datos de sitios → Gestionar los datos de sitios en el dispositivo → elimina y recarga. Para una limpieza más amplia, pulsa Ctrl + Shift + Supr y borra Archivos e imágenes en caché de los Últimos 7 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 romper flujos o dejar pasar cabeceras que Chrome rechaza. Desactiva solo la función que analiza el HTTPS (Avast/AVG: Escudo web → Enable HTTPS scanning; ESET: Filtrado del protocolo SSL/TLS; Kaspersky: 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 una por 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 reinicia el navegador. Luego abre la misma página en Firefox o Safari, y en otro dispositivo o red. Si falla en todas partes, el sitio está roto y solo su dueño puede arreglarlo (el análisis HTTPS del antivirus afecta a todos los navegadores de un mismo ordenador, así que un segundo dispositivo es la prueba real). Si solo fallan Chrome o Edge, lo probable es que el sitio envíe una cabecera que Chrome rechaza; aun así, vale la pena repetir las soluciones 2 y 3.

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

Chrome puede iniciarse con HTTP/2 (y HTTP/3) desactivados, lo que muestra si HTTP/2 interviene. Inicia desde una terminal un segundo Chrome, independiente; la carpeta de perfil adicional lo convierte en una instancia nueva aunque tu Chrome habitual esté abierto:

# Windows (Command Prompt)
"C:\Program Files\Google\Chrome\Application\chrome.exe" --user-data-dir="%TEMP%\h2test" --disable-http2 --disable-quic

# macOS (Terminal)
open -na "Google Chrome" --args --user-data-dir=/tmp/h2test --disable-http2 --disable-quic

Si la página carga en esa ventana, sus respuestas HTTP/2 son el problema y el dueño tiene que arreglarlas. Si ahora falla con ERR_CONTENT_LENGTH_MISMATCH o ERR_INCOMPLETE_CHUNKED_ENCODING, el servidor corta la respuesta sea cual sea el protocolo. Cierra esa ventana al terminar; tu Chrome habitual no se ve afectado.

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: watch the end of the output
curl -sv --http2 https://example.com/broken-page -o /dev/null
# A stream the server gave up on ends with something like:
# HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
# (curl 8.19+: HTTP/2 stream 1 reset by server (error 0x2 INTERNAL_ERROR);
#  "reset by curl" means curl rejected the response itself)

# Same URL over HTTP/1.1 for comparison
curl -sv --http1.1 https://example.com/broken-page -o /dev/null

Si HTTP/1.1 funciona y HTTP/2 falla, HTTP/2 interviene. «Reset by server» apunta a que el servidor o un proxy se rindió a mitad de la respuesta. curl no comprueba exactamente lo mismo que Chrome (rechaza discrepancias de Content-Length y cabeceras de conexión que Chrome deja pasar), así que tómalo como una pista sólida, no como una prueba. El verificador de cabeceras HTTP lista las cabeceras que define tu aplicación, vistas desde fuera de tu red.

2. Busca respuestas cortadas a mitad de envío

La causa más frecuente en el servidor es una respuesta que empieza (estado 200, cabeceras enviadas) y luego no se puede terminar. nginx guarda en búfer las respuestas más grandes de tu aplicación en archivos temporales; si el disco está lleno o nginx no puede escribir en su carpeta temporal, reinicia el flujo y el navegador informa de un error de protocolo. Comprueba:

df -h                                   # is any disk full?
sudo grep -E "No space left|Permission denied" /var/log/nginx/error.log | tail
ls -ld /var/lib/nginx/proxy /var/lib/nginx/fastcgi   # Debian/Ubuntu packages
ls -ld /var/cache/nginx/proxy_temp /var/cache/nginx/fastcgi_temp   # nginx.org packages
# the temp folders must be writable by the nginx worker user

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. Una longitud fijada en código PHP mientras un plugin o un ajuste de PHP también comprime la salida es una de las formas en que esto ocurre en sitios WordPress.
• Transfer-Encoding: no la envíes nunca en una respuesta HTTP/2; Chrome reinicia el flujo en cuanto ve una. La RFC 9113 también prohíbe Connection, Keep-Alive, Proxy-Connection y Upgrade. Chrome las ignora, pero curl y otros clientes estrictos las rechazan, y nginx elimina la mayoría de ellas de las respuestas con proxy por ti.
• Valores de cabecera: asegúrate de que ninguna cabecera contenga un salto de línea ni un carácter de control. Suele venir de datos del usuario que acaban en una cabecera, como un nombre de archivo en Content-Disposition.
• CDN por delante: si usas Cloudflare u otra CDN, prueba el origen directamente (con curl --resolve o una entrada en 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.