err_http2_protocol_error: causas y soluciones en Chrome

Abres una aplicación web, la página de pago de una tienda o la página de un servicio de video en Chrome y, en su lugar, recibes una pantalla gris: «No se puede acceder a este sitio web» (en el Chrome para Latinoamérica, «No se puede acceder a este sitio»), una línea que dice que es posible que la página web «esté temporalmente inactiva o que se haya trasladado definitivamente a otra dirección» y, abajo del todo, ERR_HTTP2_PROTOCOL_ERROR. Otras veces la página carga a medias, falta un script o una imagen, y la consola para desarrolladores dice «Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR».

El código apunta a HTTP/2, el protocolo que la mayoría de los sitios seguros usan con Chrome, y casi siempre significa que el sitio, o un dispositivo entre tú y el sitio, envió algo que rompe las reglas de HTTP/2. A continuación: qué significa el código, cómo se rompe una petición, las causas que reprodujimos, las soluciones para visitantes, qué revisan los propietarios en nginx, IIS y Cloudflare, y el error en Go, Node.js y Python.

¿Qué significa ERR_HTTP2_PROTOCOL_ERROR?#

Significa que la conexión HTTP/2 entre tu navegador y el sitio recibió algo que el protocolo no permite, y la petición no pudo completarse. HTTP/2 es la segunda versión principal de HTTP; funciona dentro de una conexión cifrada con TLS en el puerto TCP 443, y el servidor lo elige durante la negociación TLS con el identificador h2. Chrome y Edge se basan en Chromium, cuya lista de errores de red define este código como el error -337 con una sola línea: «There is an HTTP/2 protocol error.» (Hay un error del protocolo HTTP/2.)

Esa línea nombra el síntoma, no al culpable. El estándar HTTP/2 usa PROTOCOL_ERROR como código genérico para los casos en que «no hay disponible un código de error más específico», así que el mensaje dice que se rompió una regla sin decir cuál. Su hermano ERR_QUIC_PROTOCOL_ERROR se refiere a HTTP/3 sobre QUIC y UDP, con causas distintas, y se explica en Solucionar err_quic_protocol_error en Chrome y Edge.

¿Qué te dice la página de error?#

Vimos estas líneas en pantalla en Chromium 145. La página no tiene la lista «Prueba a:» ni botón de recarga: Chromium no tiene un texto específico para los errores de HTTP/2 y recurre a su página genérica. Edge muestra el mismo código; los demás códigos que aparecen bajo este encabezado se explican en This Site Can't Be Reached: qué significa y por qué aparece.

Cuando la conexión se rompe después de que el servidor ya envió una cabecera 200 OK, la página puede verse incompleta y la consola para desarrolladores (F12) registra «Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR» para la petición que se cortó. Un 200 junto al error significa exactamente eso: la respuesta había empezado antes de que se restableciera el flujo.

¿Cómo se rompe una petición HTTP/2?#

1. Empieza la conexión. Chrome abre una conexión TLS al puerto 443 y ofrece h2; el servidor acepta, y ambas partes intercambian una trama SETTINGS con sus límites.
2. Las peticiones viajan como flujos. Cada petición recibe su propio flujo (stream) en la conexión compartida, con tramas HEADERS para las cabeceras y tramas DATA para el cuerpo.
3. Una trama rompe una regla. RFC 9113, el estándar HTTP/2, considera mal formado un mensaje cuando Content-Length no coincide con el total de las tramas DATA, cuando el valor de una cabecera empieza o termina con un espacio, o cuando está presente una cabecera específica de la conexión como Connection o Transfer-Encoding.
4. El extremo que lo detecta restablece el flujo. Un mensaje mal formado debe tratarse como un error de flujo de tipo PROTOCOL_ERROR, así que el extremo envía una trama RST_STREAM; un error que corrompe toda la conexión se convierte en una trama GOAWAY y la conexión se cierra.
5. Chrome informa del -337. Cuando Chrome recibe un RST_STREAM con PROTOCOL_ERROR, o detecta por sí mismo una trama no válida, hace fallar esa petición con ERR_HTTP2_PROTOCOL_ERROR. Chromium no la reintenta ni vuelve a HTTP/1.1; solo el código HTTP_1_1_REQUIRED hace que Chrome reenvíe una petición por el protocolo antiguo.

¿Qué causa ERR_HTTP2_PROTOCOL_ERROR?#

En nuestro servidor HTTP/2 de pruebas, Chromium 145 toleró un Content-Length mayor que el cuerpo e incluso mostró la página truncada, mientras que el cliente HTTP/2 de Node.js, httpx de Python y undici rechazaron la misma respuesta con PROTOCOL_ERROR; cuando el propio servidor restableció el flujo, Chromium mostró ERR_HTTP2_PROTOCOL_ERROR de inmediato. Ese es el patrón habitual en el mundo real: una respuesta ligeramente rota que el navegador se tragaría es rechazada por una CDN o un balanceador de carga más estrictos delante del sitio, que restablecen el flujo del visitante.

¿Cómo lo solucionas como visitante?#

Si otros sitios seguros también fallan, la causa está de tu lado; si el sitio también falla en tu teléfono con el Wi-Fi apagado, es del sitio. Recarga la página después de cada paso.

1. Recarga una vez. Arriba a la izquierda, selecciona Volver a cargar esta página.
2. Prueba una ventana de incógnito u otro navegador. Abre Más > Nueva ventana de Incógnito; si la página carga ahí, desactiva las extensiones de una en una en Más > Extensiones > Gestionar extensiones.
3. Desconecta la VPN y las apps de filtrado, incluidas las apps que bloquean anuncios enrutando el tráfico a través de sí mismas.
4. Pausa la protección web del antivirus para una prueba. Los programas que analizan el tráfico HTTPS se sitúan dentro de la conexión cifrada. Desactiva solo esa función, recarga una vez y vuelve a activarla; si la pausa ayudó, actualiza el programa.
5. Elimina los datos guardados del sitio. Selecciona Más > Configuración, después Privacidad y seguridad > Cookies de terceros > Ver todos los datos y permisos de sitios, busca el sitio, selecciona Eliminar y confirma con Eliminar.
6. Actualiza Chrome. Selecciona Más > Ayuda > Información de Google Chrome y después Reiniciar, si aparece.
7. En una red del trabajo o de un centro educativo, pregunta al equipo de informática. Un firewall que inspecciona el tráfico es de la organización, y la solución también.

En Android, actualiza Chrome desde Play Store: toca el icono de perfil, después Gestionar apps y dispositivo y, bajo «Actualizaciones disponibles», toca Actualizar junto a Chrome. Para eliminar los datos guardados, abre Chrome, toca Más > Eliminar datos de navegación, elige los tipos de datos y toca Eliminar datos. Alterna entre Wi-Fi y datos móviles y desactiva cualquier app de VPN antes de culpar al sitio.

Si el sitio es tuyo: cómo encontrar la respuesta rota#

1. Localiza la petición. En DevTools, abre el panel Red, recarga y busca la petición marcada como fallida con este error; la columna Protocolo, que se activa haciendo clic con el botón derecho en la cabecera de la tabla, muestra h2.
2. Pídela dos veces desde la línea de comandos. curl --http2 -v https://example.com/ruta y curl --http1.1 -v con la misma URL fuerzan los dos protocolos e imprimen las cabeceras de la respuesta. Si HTTP/2 falla mientras HTTP/1.1 devuelve la página, la respuesta rompe una regla de HTTP/2. El curl incluido en Windows 11 rechaza --http2 («the installed libcurl version does not support this»), así que prueba en Linux, macOS o en el servidor.
3. Compara el origen con el borde. Detrás de una CDN o un balanceador de carga, pide la misma URL directamente al servidor de origen y a través de la dirección pública, y compara las cabeceras: Content-Length y Content-Encoding, cualquier cabecera Connection, Keep-Alive o Transfer-Encoding, y valores con espacios al final.
4. Arregla la respuesta, no el protocolo. Un middleware de compresión que aplica gzip al cuerpo después de que la aplicación ya fijó Content-Length es la causa clásica; deja que una sola capa comprima y recalcule la longitud. Quita las cabeceras específicas de la conexión del código de la aplicación y mantén las cookies pequeñas. Desactivar HTTP/2 en el servidor es un paso de diagnóstico de unos minutos, nunca la solución: la respuesta sigue mal formada y el siguiente cliente estricto vuelve a fallar.
5. nginx. Las versiones actuales activan HTTP/2 con http2 on; junto a listen 443 ssl;, disponible desde la 1.25.1; la forma antigua listen 443 ssl http2; está obsoleta, y http2_max_field_size y http2_max_header_size quedaron sin efecto desde la 1.19.7, sustituidas por large_client_header_buffers, como explica la documentación de ngx_http_v2_module.
6. IIS. IIS 10 en Windows Server 2016 y posteriores solo habla HTTP/2 sobre TLS y vuelve a HTTP/1.1 con la autenticación de Windows, según el artículo de Microsoft sobre HTTP/2 en IIS; el campo «Protocol version» en Logging (Registro) > Select Fields (Seleccionar campos) muestra qué peticiones usan HTTP/2. Para probar, Windows puede desactivar HTTP/2 por enlace TLS con netsh http update sslcert ... disablehttp2=enable (de la documentación de netsh http; no lo probamos aquí).
7. Cloudflare. HTTP/2 está activado por defecto en todos los planes, y la página de HTTP/2 de Cloudflare señala las cabeceras de origen con formato incorrecto y los problemas de compresión, como gzip sin un Content-Length actualizado, como las causas habituales en los sitios que pasan por Cloudflare, y sugiere dejar que comprima Cloudflare.

Desarrolladores y scrapers: el mismo error en Go, Node.js y Python#

Los clientes HTTP que negocian h2 fallan igual que Chrome. http.Server y http.DefaultTransport de Go usan HTTP/2 automáticamente para HTTPS (GODEBUG=http2client=0 desactiva la parte cliente). En Node.js 24.22, el fetch integrado habló HTTP/1.1 con nuestro servidor de pruebas, mientras que un Agent de undici creado con allowH2: true negoció HTTP/2. En Python, httpx necesita pip install httpx[http2] y httpx.Client(http2=True); HTTP/2 está desactivado por defecto. Ante una respuesta cuyo Content-Length prometía 100 bytes pero entregaba 5, nuestros clientes informaron:

# Node.js 24.22, node:http2
response: :status=200 content-length=100 content-type=text/plain
stream error: ERR_HTTP2_STREAM_ERROR Stream closed with error code NGHTTP2_PROTOCOL_ERROR

# undici 7.30 con allowH2: true
TypeError: terminated <- ERR_HTTP2_STREAM_ERROR: Stream closed with error code NGHTTP2_PROTOCOL_ERROR

# Python httpx 0.28 con http2=True
h2.exceptions.InvalidBodyLengthError: InvalidBodyLengthError: Expected 100 bytes, received 5

Trata un error de protocolo HTTP/2 como una respuesta mal formada, no como un bloqueo: reintenta una vez por HTTP/1.1 para confirmarlo, arregla el servidor si es tuyo e informa de la URL y las cabeceras al propietario si no lo es. Cambiar de dirección IP no sirve de nada; todas las direcciones reciben la misma respuesta rota.

Un proxy rara vez entra en juego. Para un sitio https://, el cliente pide al proxy un túnel con una petición CONNECT y ejecuta TLS, con HTTP/2 dentro, de extremo a extremo con el sitio; el proxy nunca ve una trama, así que los Proxies HTTPS ni causan ni curan este error. Solo un proxy que termina TLS a propósito, como una pasarela de inspección corporativa, es un extremo HTTP/2 por sí mismo.

Una segunda salida distingue un fallo global de uno regional: repite la petición desde los Proxies de centro de datos de otro país; el mismo error ahí significa que la respuesta está rota para todos, y una respuesta limpia apunta a tu propia red o a tu software de inspección.

Errores relacionados#

Si en su lugar ves ERR_SSL_PROTOCOL_ERROR, nunca se llegó a HTTP/2; Solucionar err_ssl_protocol_error en Chrome y Edge cubre ese caso.

Dónde puedes encontrarlo#

• Aplicaciones web detrás de una CDN o un balanceador de carga, donde una respuesta de la API lleva una cabecera añadida a mano.
• Aplicaciones ASP.NET y otras alojadas en IIS poco después de activar HTTPS, ya que HTTP/2 en IIS solo existe sobre TLS.
• Páginas de servicios de video en las que las peticiones del reproductor fallan mientras el resto de la página carga.

Errores comunes#

• Vaciar toda la caché del navegador una y otra vez. Solo importan las cookies del sitio que falla, y solo cuando la causa son cabeceras demasiado grandes.
• Corregir el reloj del sistema. Una fecha incorrecta produce avisos de certificado, no este código.
• Desactivar QUIC en chrome://flags. Esa opción se refiere a HTTP/3; HTTP/2 no tiene interruptor en Chrome.
• Rotar direcciones IP en un scraper. La respuesta está rota para todas las direcciones.

Guía de decisión#

Preguntas frecuentes#

¿Cómo soluciono ERR_HTTP2_PROTOCOL_ERROR en Android?#

Actualiza Chrome desde Play Store, alterna entre Wi-Fi y datos móviles y desactiva cualquier app de VPN o de bloqueo de anuncios. Si el sitio sigue fallando con datos móviles, la causa es el sitio o su CDN.

¿Por qué el registro de mi servidor muestra 200 OK cuando los visitantes ven el error?#

Porque la línea de estado se envió y se registró antes de que se restableciera el flujo. La aplicación respondió con 200, y después el servidor, una CDN o el navegador encontraron mal formado el resto de la respuesta y cancelaron el flujo.

¿El error ocurre más a menudo en sitios con Cloudflare?#

Es más a menudo visible ahí, porque el borde de Cloudflare es un extremo HTTP/2 estricto entre el origen y el visitante. Una respuesta que un navegador quizá toleraría directamente del origen se rechaza en el borde.

¿Puedo desactivar HTTP/2 en Chrome?#

No. La configuración de Chrome no tiene interruptor de HTTP/2, y la opción de QUIC en chrome://flags se refiere a HTTP/3. Prueba en el lado del servidor con curl --http1.1 y curl --http2; en el lado del cliente, Firefox es la segunda opinión más rápida.

¿ERR_HTTP2_PROTOCOL_ERROR es señal de que mi equipo está hackeado?#

Normalmente no; la mayoría de los casos se remontan al servidor del sitio, a su CDN o al software de seguridad de tu equipo.

¿Una VPN o un proxy solucionan ERR_HTTP2_PROTOCOL_ERROR?#

No cuando la respuesta del sitio está rota, porque las mismas tramas te llegan por cualquier ruta. Una VPN o un proxy que inspecciona es más a menudo la causa que el remedio.

En resumen#

ERR_HTTP2_PROTOCOL_ERROR significa que una trama de la conexión HTTP/2 de Chrome rompió las reglas del protocolo, casi siempre porque el sitio o su CDN restableció una petición tras una respuesta mal formada: una cabecera prohibida, un Content-Length que ya no coincidía con un cuerpo comprimido o cabeceras demasiado grandes. Los visitantes prueban el modo incógnito, otro navegador y una VPN o un antivirus en pausa; los propietarios comparan la respuesta por HTTP/1.1 y HTTP/2 y la arreglan en lugar de desactivar HTTP/2. Para comprobaciones desde varias ubicaciones, los tipos de proxy se comparan en nuestra página de proxies.