ERR_HTTP2_PROTOCOL_ERROR: causas y soluciones

2026-09-19

ERR_HTTP2_PROTOCOL_ERROR significa que el navegador y el servidor negociaron HTTP/2 correctamente, pero un frame o un stream concreto del intercambio incumplió las reglas del protocolo y la conexión se reseteó. Es distinto de un fallo TLS: la conexión cifrada funcionó, y el problema está una capa más arriba, en cómo se formó el propio stream HTTP/2.

Qué significa ERR_HTTP2_PROTOCOL_ERROR

HTTP/2 envía peticiones y respuestas como frames binarios sobre una única conexión, con reglas estrictas sobre el tamaño de los frames, la codificación de cabeceras (HPACK), y el estado de los streams. Un servidor, proxy o CDN que envía un frame mal formado, una cabecera demasiado grande, o un frame para un stream que ya está cerrado incumple esas reglas, y el cliente cierra la conexión en lugar de intentar adivinar qué se quería decir. Como el fallo puede originarse en el servidor de la aplicación, un proxy intermedio, un borde de CDN, o la propia pila de red del navegador, este error cubre un rango de causas raíz más amplio que la mayoría de los demás de esta lista.

Cómo aparece el error

Chrome y Edge muestran "This page isn't working - ERR_HTTP2_PROTOCOL_ERROR", a veces solo en algunas cargas de la página y no en otras, lo que es un indicio de que el fallo es intermitente y no una mala configuración fija. Firefox suele mostrar un error de conexión genérico en lugar de nombrar el protocolo.

curl puede forzar HTTP/2 y mostrar exactamente en qué frame falló la conexión:

curl --http2 -v https://example.com/ 2>&1 | tail -20
...
* Recv failure: Connection reset by peer
* HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

Comparar eso con una petición HTTP/1.1 a la misma URL aísla si el problema es específico del protocolo:

curl --http1.1 -sI https://example.com/

Si la petición HTTP/1.1 tiene éxito y la de HTTP/2 falla, el fallo está en cómo algo de la cadena implementa HTTP/2, no en la propia aplicación.

Qué causa ERR_HTTP2_PROTOCOL_ERROR

Cabeceras mal formadas o demasiado grandes de la aplicación o de un proxy. Una cookie muy larga, un conjunto de cabeceras de respuesta demasiado grande, o un valor de cabecera con caracteres que HPACK no puede codificar violan el tamaño de frame que espera el servidor o el cliente.
Un proxy inverso o balanceador de carga con una implementación de HTTP/2 defectuosa o desactualizada. Algunas pilas HTTP/2 antiguas de nginx, Apache, o de dispositivos embebidos tienen problemas conocidos con secuencias de frames concretas bajo carga.
Un fallo en el borde de un CDN o un desajuste de protocolo entre el borde y el origen. El tramo navegador-borde y el tramo borde-origen pueden usar protocolos distintos; un fallo al traducir entre ellos produce ocasionalmente este error solo para ciertas formas de petición.
Software antivirus o una extensión de navegador que intercepta tráfico HTTPS. El mismo tipo de software que causa fallos de handshake SSL también puede romper un stream HTTP/2 sano si su capa de interceptación no habla HTTP/2 correctamente.
Un navegador desactualizado con una implementación de HTTP/2 antigua, o una caché de red del navegador corrupta.
Un desajuste de Content-Length detrás de un proxy inverso. Si nginx (u otro proxy) reenvía una respuesta cuyo Content-Length declarado no coincide con los bytes realmente enviados, el framing HTTP/2 corriente abajo puede romperse a mitad de camino.

Cómo saber de quién es la culpa

Ejecuta una comprobación HTTP desde varias ubicaciones: si el fallo es constante en todas partes, la gestión de HTTP/2 del servidor o del CDN es la culpable. Si solo falla contigo, es mucho más probable que sea local: el navegador, un antivirus, o un dispositivo de red entre tú y el sitio.

Cómo corregir ERR_HTTP2_PROTOCOL_ERROR

Si eres el visitante

Recarga la página. Como la causa suele ser un único frame mal formado y no una mala configuración persistente, una conexión nueva a menudo tiene éxito.
Borra la caché del navegador en chrome://settings/clearBrowserData, ya que un recurso en caché corrupto puede disparar esto al recargar.
Desactiva temporalmente el escaneo HTTPS/SSL del antivirus y vuelve a intentarlo; este tipo de software es una causa habitual y a menudo pasada por alto.
Prueba una ventana de incógnito para descartar una extensión.
Actualiza el navegador a la última versión, ya que las implementaciones de cliente HTTP/2 más antiguas tenían fallos conocidos.

Si administras el sitio

Compara HTTP/2 frente a HTTP/1.1 con los comandos de curl de arriba. Si solo falla HTTP/2, el problema está en la capa HTTP/2 de un proxy o de un CDN, no en la aplicación.
Aumenta los límites de tamaño de cabecera de nginx si están implicadas cookies o cabeceras grandes:
```
http2_max_field_size 16k;
http2_max_header_size 32k;
large_client_header_buffers 4 16k;
```
Reinicia o recarga nginx tras el cambio y vuelve a probar.
Revisa si hay un desajuste de Content-Length entre lo que envía la aplicación y lo que reenvía el proxy; activa el buffering del proxy (proxy_buffering on;) para que nginx pueda leer la respuesta completa antes de formatearla para HTTP/2.
Actualiza nginx, Apache, o cualquier balanceador de carga a una versión actual; los fallos de gestión de frames de HTTP/2 son del tipo que se corrige en versiones menores.
Desactiva HTTP/2 como prueba de diagnóstico, no como solución permanente: elimina temporalmente http2 de la directiva listen de nginx. Si los errores se detienen, se confirma que el fallo está específicamente en la capa HTTP/2, y puedes volver a activarlo una vez aplicada la solución de cabeceras o buffering de arriba.
Revisa los registros del lado del CDN si hay uno delante del origen; la mayoría de los CDN muestran los errores de framing de HTTP/2 en sus registros de borde con más detalle del que el navegador llega a mostrar nunca.

Errores relacionados

ERR_SSL_PROTOCOL_ERROR parece similar pero falla antes, durante el handshake TLS, antes de que se intercambie ningún frame de HTTP/2.
Códigos de error de servidor 5xx cubren los casos donde la conexión y el protocolo funcionan bien pero la propia aplicación falla.

Un detalle que merece la pena separar: un error de protocolo HTTP/2 no es lo mismo que un stream HTTP/2 que la aplicación cerró de forma limpia, por ejemplo cuando un cliente cancela una petición a mitad de camino. Las herramientas de desarrollador del navegador y los registros de acceso del servidor a veces etiquetan ambos casos como "reset", pero solo una violación real del framing produce ERR_HTTP2_PROTOCOL_ERROR en el navegador; un stream cancelado intencionadamente simplemente se detiene sin ninguna página de error.

Cómo prevenir ERR_HTTP2_PROTOCOL_ERROR

Como este error suele ser intermitente, ligado a tamaños de cabecera concretos o a versiones concretas de un proxy, puede afectar a una fracción de los visitantes durante semanas antes de que alguien note un patrón. Una comprobación HTTP ejecutada según un horario desde varias ubicaciones detecta un aumento en la tasa de fallos justo después de un despliegue, un cambio de CDN, o una actualización de proxy, en lugar de depender de reportes de usuarios dispersos. HostTracker alerta por correo, SMS, llamada de voz, Slack, Telegram y más en cuanto una comprobación empieza a fallar.

Preguntas frecuentes

¿ERR_HTTP2_PROTOCOL_ERROR es lo mismo que un error SSL?

No. Este error ocurre después de que TLS tiene éxito, en la capa de framing de HTTP/2. Un error SSL significa que la propia conexión cifrada nunca llegó a formarse.

¿Por qué el error solo aparece a veces, no en cada carga de página?

La mayoría de las causas aquí se disparan por condiciones concretas, una cabecera que crece por encima de un límite, una condición de carrera en un proxy bajo carga, un recurso en caché en particular, en lugar de una mala configuración fija que falla siempre.

¿Desactivar HTTP/2 en mi servidor perjudicará el rendimiento?

HTTP/2 ofrece beneficios reales (multiplexación, compresión de cabeceras), así que trata desactivarlo como un paso de diagnóstico temporal, no como una solución permanente. Corrige el problema subyacente de tamaño de cabecera o de buffering y vuelve a activarlo.

¿Puede un CDN causar esto aunque mi servidor de origen esté bien?

Sí. El borde del CDN y el origen pueden usar protocolos distintos en cada tramo de la conexión, y un fallo o una mala configuración en cómo el CDN traduce entre ellos puede producir este error con independencia de la salud del propio origen.

¿Ocurre esto en sitios con HTTP/1.1?

No, ERR_HTTP2_PROTOCOL_ERROR es específico de conexiones que negociaron HTTP/2. Un sitio que solo sirve HTTP/1.1 no puede producir este error concreto, aunque puede tener sus propios problemas de conexión.