Abres un video o una aplicación web en Chrome, aparece parte de la página y luego la pestaña se convierte en una pantalla gris: «No se puede acceder a este sitio web» (en el Chrome para Latinoamérica, «No se puede acceder a este sitio»), debajo la línea «Es posible que la página web … esté temporalmente inactiva o que se haya trasladado definitivamente a otra dirección.» y ERR_QUIC_PROTOCOL_ERROR abajo del todo. Recargar a veces ayuda y a veces no, y en tu teléfono la misma web se abre sin problemas.
Rara vez la web está caída. El error viene de QUIC, la forma más reciente en que Chrome y Edge se conectan a muchas webs grandes, y de algo en tu equipo o en tu red que deja que esa conexión empiece y luego la rompe. Aquí verás qué es QUIC, por qué Chrome suele ocultar estos fallos, cuáles son las causas y las soluciones, y qué cambia con una VPN o un proxy.
¿Qué significa ERR_QUIC_PROTOCOL_ERROR?
QUIC es un protocolo de transporte: el conjunto de reglas que mueve los datos de una página entre el servidor de la web y tu navegador. La mayor parte del tráfico web sigue usando TCP para ese trabajo. QUIC hace lo mismo sobre UDP, un protocolo más sencillo que envía paquetes sin esperar a que se confirme cada uno; la comprobación, el orden y el cifrado los añade el propio QUIC. La diferencia entre ambos se explica en TCP y UDP: ¿en qué se diferencian?.
En la lista de errores de red de Chromium, el código fuente que hay detrás de Chrome y Edge, este es el error -356, descrito en una sola línea: «There is a QUIC protocol error.» (Hay un error del protocolo QUIC.) Dice que la conexión QUIC falló, no quién lo causó. La pantalla gris es la página genérica de Chrome: Chromium no tiene un texto propio para este error, así que «temporalmente inactiva» es una frase por defecto, no un diagnóstico.
¿Qué relación hay entre HTTP/3, QUIC y el puerto UDP 443?
HTTP es el idioma que usan navegadores y servidores para pedir y entregar páginas. Su versión más reciente, HTTP/3, se define en RFC 9114 como HTTP transportado sobre QUIC, y el estándar de QUIC, RFC 9000, mete los paquetes QUIC dentro de datagramas UDP (paquetes UDP sueltos). Para una dirección https://, eso significa normalmente el puerto UDP 443. Las webs seguras siempre han usado el puerto 443, pero hasta HTTP/3 era un puerto TCP, y muchos firewalls y filtros se diseñaron pensando en eso.
Una web anuncia HTTP/3 en una cabecera de una respuesta normal. Cuando lo comprobamos el 6 de octubre de 2026, example.com respondió con alt-svc: h3=":443"; ma=86400: HTTP/3 ("h3") está disponible en el puerto 443, y el navegador puede recordarlo durante 86.400 segundos, es decir, un día. YouTube y Google envían la misma oferta con una memoria de 30 días.
El estándar también prevé los fallos. Cuando una red bloquea UDP, RFC 9114 dice que los navegadores deberían volver a las versiones de HTTP basadas en TCP: HTTP/2 o HTTP/1.1 sobre una conexión cifrada normal.
¿Por qué Chrome muestra un error en lugar de volver a TCP?
Chrome sigue esa regla, así que una red que bloquea QUIC por completo rara vez produce este error. El error aparece cuando QUIC funciona al principio y falla después:
- La web ofrece HTTP/3. La oferta llega en la cabecera
alt-svco, en algunas webs, en un registro DNS, y Chrome la guarda. - Chrome prueba QUIC. En la siguiente visita abre una conexión QUIC al puerto UDP 443 y mantiene una conexión TCP normal en reserva.
- QUIC nunca llega a conectar. Si los paquetes UDP se bloquean del todo, TCP toma el relevo, y Chrome marca QUIC como roto para esa web durante unos minutos, más tiempo tras fallos repetidos. No notas nada.
- QUIC conecta y se rompe antes de que llegue la respuesta. Chrome vuelve a enviar la petición por TCP y, si funciona, marca QUIC como roto para esa web.
- QUIC se rompe cuando la respuesta ya ha empezado. En cuanto parte de la respuesta ha llegado al navegador, el código de conexión de Chromium trata la petición como una que «can not be retried» (no se puede reintentar). Chrome muestra
ERR_QUIC_PROTOCOL_ERROR.
Así que el error apunta a una red en la que QUIC funciona a medias: los paquetes pasan el tiempo suficiente para empezar una página y luego algo los descarta, los modifica o los corta. Un bloqueo limpio solo te habría costado HTTP/3, no la página.
¿Qué causa ERR_QUIC_PROTOCOL_ERROR?
| Causa | Señal típica | Primera comprobación |
|---|---|---|
| Antivirus o suite de seguridad con protección web | Fallan muchas webs en un equipo, en cualquier red | Pausa la protección web durante una recarga |
| Firewall de una empresa, un centro educativo o una red Wi-Fi pública | Solo en esa red | Pregunta a quien gestiona la red |
| App de VPN | Solo con la VPN conectada | Desconéctala o elige otro servidor |
| Router o firewall que olvida las conexiones UDP inactivas | Una pestaña abierta durante un rato falla en el siguiente clic | Recarga; actualiza el firmware del router |
| El servidor HTTP/3 de la web o su CDN | Una web, en todas las redes y dispositivos | Espera o avisa al propietario de la web |
| Un proxy configurado en el navegador | No es este error: Chrome no usa QUIC a través de un proxy | Mira la sección sobre proxies más abajo |
En un equipo doméstico, los programas de seguridad son los primeros sospechosos. El centro de ayuda de ESET dice que su protección web puede no funcionar correctamente con QUIC activado, y Trend Micro y WatchGuard documentan cómo bloquear el puerto UDP 443 para que los navegadores pasen a HTTP/2. Un filtro que bloquea QUIC de forma limpia es inofensivo; uno que deja pasar los primeros paquetes y descarta el resto produce este error.
Los routers y los firewalls también llevan la cuenta de cada conversación que pasa por ellos. RFC 9308, la guía del IETF para operar QUIC, señala que olvidan una conversación UDP inactiva mucho antes que una TCP, y algunos firewalls rechazan después los paquetes del servidor que ya no esperan. Por eso una pestaña que se quedó quieta un rato puede fallar en el siguiente clic.
¿Cómo se soluciona ERR_QUIC_PROTOCOL_ERROR?
Sigue estos pasos en orden y recarga la página después de cada uno:
- Recarga una vez. Un corte puntual, como un breve fallo del Wi-Fi, a menudo no se repite.
- Prueba otra red. Abre la web con los datos móviles de tu teléfono o con un punto de acceso. Si ahí funciona, la web está bien.
- Desconecta la VPN. Si la página carga entonces, prueba otro servidor u otro protocolo de conexión en la app de la VPN.
- Pausa la protección web del antivirus para una prueba. Desactiva la función que analiza el tráfico web o HTTPS, recarga y vuelve a activarla. Si la pausa ayudó, actualiza el programa y busca HTTP/3 o QUIC en su ayuda; algunos fabricantes recomiendan en su lugar el paso siguiente.
- Desactiva QUIC en el navegador. Esto elimina el error en todos los casos, porque el navegador deja de usar QUIC. Los pasos están justo debajo.
- En un equipo del trabajo o de un centro educativo, pregunta al departamento de informática. El firewall y la configuración del navegador son de la organización, y la solución también.
¿Cómo se desactiva QUIC en Chrome y Edge?
QUIC viene activado por defecto. El interruptor está en la página de funciones experimentales del navegador, donde los nombres de las opciones y los valores de sus menús siguen en inglés aunque Chrome esté en español. En Chrome para Windows, Mac, Linux o Android:
- Escribe
chrome://flags/#enable-quicen la barra de direcciones y pulsa Enter. La página salta a Experimental QUIC protocol. - Cambia el menú de al lado de Default a Disabled.
- Haz clic en Reiniciar en la parte inferior de la página. Chrome se cierra y se vuelve a abrir.
En Edge, escribe edge://flags/#enable-quic, pon Experimental QUIC protocol en Disabled y haz clic en Restart (Reiniciar).
Lo que pierdes es HTTP/3. Las páginas cargan con HTTP/2 o HTTP/1.1 sobre TCP, y con una buena conexión rara vez lo notarás. Para deshacer el cambio, vuelve a poner la opción en Default. Tómalo como una medida provisional: si el error lo causó un programa de seguridad, la solución de fondo es actualizar o reconfigurar ese programa.
Las organizaciones desactivan QUIC de forma centralizada con una política llamada QuicAllowed ("Allow QUIC protocol"), que se llama igual en Chrome y en Edge (documentación de Microsoft). Escribe chrome://policy en la barra de direcciones para ver las políticas de tu equipo; si QuicAllowed aparece en la lista, tu organización decide si se usa QUIC.
¿La culpa es de la web?
A veces. Si una web falla en todas las redes y dispositivos mientras otras funcionan, la causa probable es su servidor HTTP/3 o la red de distribución de contenidos (CDN, una red de servidores que entrega las páginas de una web desde un punto cercano a ti). Solo el propietario de la web puede arreglarlo; mientras tanto, desactivar QUIC te permite esquivar el problema.
Si la web es tuya, confírmalo con visitantes de otras redes y luego desactiva HTTP/3 para una prueba; en Cloudflare, el interruptor está en Speed > Settings > Protocol Optimization > HTTP/3. Si tienes tu propio balanceador de carga, RFC 9308 advierte que los balanceadores que reparten el tráfico por dirección y puerto pueden romper QUIC cuando el router de un visitante cambia el puerto.
¿Las VPN y los proxies causan este error?
Una app de VPN lleva todo el tráfico de tu dispositivo, incluido el UDP, dentro de un túnel cifrado hasta su servidor. Envolver cada paquete en otro deja menos espacio por paquete, y RFC 9000 dice que QUIC no debe usarse en una ruta que no pueda transportar paquetes UDP de al menos 1200 bytes. Un servidor VPN que filtra UDP, o un túnel con muy poco espacio, rompe QUIC; cambia el servidor o el protocolo en la app.
Un proxy configurado en el navegador funciona de otra manera. Con un proxy HTTP o HTTPS, Chrome le pide al proxy un túnel hacia la web con una petición CONNECT, que va por TCP. Un comentario en el código de conexión de Chromium indica que QUIC no puede hablarse con proxies que no sean proxies QUIC, así que Chrome carga la web con HTTP/2 o HTTP/1.1 y este error no aparece.
SOCKS5 es el caso especial, porque el propio protocolo puede transportar UDP además de TCP; ¿Qué es un proxy SOCKS5? explica cómo.
Chrome no usa esa parte. Su documentación sobre proxies dice que SOCKS5 en Chrome solo gestiona peticiones TCP y «cannot be used to relay UDP traffic» (no puede usarse para retransmitir tráfico UDP). Nuestros Proxies SOCKS5 retransmiten UDP para las apps que lo envían por sí mismas, pero en Chrome transportan las páginas por TCP como cualquier otro proxy.
Esto también explica lo que ves en el trabajo. Cuando compruebas con Proxies residenciales cómo se ve una tienda desde otro país, las herramientas para desarrolladores del navegador (DevTools) muestran h2 donde una visita directa muestra h3. Es lo esperado, no un fallo. Un proxy tampoco es una solución para este error: desactivar QUIC tiene el mismo efecto sin enviar tu tráfico a través de nadie más.
Avanzado: comprueba si una web usa HTTP/3
Esta parte es para quien quiera verlo por sí mismo. DevTools muestra el protocolo de cada petición:
- Abre la web, pulsa F12 o Ctrl+Shift+I (Cmd+Option+I en Mac) y selecciona el panel Red.
- Haz clic con el botón derecho en la cabecera de la tabla de peticiones y selecciona Protocolo.
- Recarga la página.
h3significa HTTP/3 sobre QUIC;h2, HTTP/2 sobre TCP.
Si la web que falla muestra h3 en una red donde sí funciona, QUIC está en juego, y desactivarlo eliminará el error. Para ver la oferta de HTTP/3 de una web sin navegador, pide sus cabeceras con curl, que viene incluido en Windows 10, Windows 11 y macOS; en Windows PowerShell, escribe curl.exe.
curl -sI https://example.comNuestra prueba del 6 de octubre de 2026 (curl 8.21.0, Windows 11) devolvió, entre otras cabeceras, esta línea:
alt-svc: h3=":443"; ma=86400Si la respuesta no trae h3, normalmente la web no ofrece HTTP/3 por esta vía.
Errores relacionados
| Código | Qué falló | Funciona sobre |
|---|---|---|
ERR_QUIC_PROTOCOL_ERROR (-356) | Una conexión QUIC se rompió después de que empezara la respuesta | UDP |
ERR_QUIC_HANDSHAKE_FAILED (-358) | Una conexión QUIC nunca terminó de establecerse; Chrome puede reenviar la petición | UDP |
ERR_HTTP2_PROTOCOL_ERROR (-337) | Falló una conexión HTTP/2 | TCP |
ERR_SSL_PROTOCOL_ERROR (-107) | Falló la negociación cifrada | TCP |
ERR_CONNECTION_RESET (-101) | Se cortó una conexión ya establecida | TCP |
Si al desactivar QUIC el error se convierte en ERR_SSL_PROTOCOL_ERROR, el mismo filtro está rompiendo ahora la conexión TCP, y Solucionar err_ssl_protocol_error en Chrome y Edge sigue desde ahí.
Dónde puedes encontrarlo
- YouTube y los servicios de Google, que ofrecen HTTP/3 a todos los visitantes y piden a los navegadores que lo recuerden 30 días.
- Webs detrás de Cloudflare, que ofrece HTTP/3 en todos sus planes.
- Redes de oficinas y centros educativos cuyos firewalls inspeccionan el tráfico web.
- Equipos con una suite de seguridad de internet que filtra las páginas web.
Errores comunes
- Borrar las cookies y la caché. Guardan páginas e inicios de sesión, no la conexión; el corte ocurre por debajo de ellas.
- Reinstalar Chrome. Una instalación nueva vuelve a usar QUIC por defecto.
- Dejar la protección web desactivada para siempre en lugar de actualizar el programa o desactivar QUIC.
- Culpar a la web tras un solo fallo. Prueba primero otra red.
- Cambiar la configuración de un equipo del trabajo sin preguntar. El firewall que rompe QUIC es de la organización.
Guía de decisión
| Tu situación | Qué hacer |
|---|---|
| Falla con Wi-Fi, funciona con datos móviles | Revisa el router y cualquier filtro de esa red |
| Solo falla con la VPN activada | Cambia de servidor o de protocolo en la app de la VPN |
| Empezó con un antivirus nuevo o actualizado | Pausa la protección web para una prueba y después actualízalo o reconfigúralo |
| Una web, en todas las redes | Avisa al propietario de la web; mientras tanto, desactiva QUIC |
| Equipo del trabajo o de un centro educativo | Pregunta al departamento de informática |
| Necesitas la página ya | Pon Experimental QUIC protocol en Disabled |
Preguntas frecuentes
¿Es seguro desactivar QUIC?
Sí. Las páginas siguen viajando cifradas, con TLS sobre TCP en lugar de QUIC, como funcionaba la mayor parte de la web antes de HTTP/3. Puedes volver a poner la opción en Default cuando quieras.
¿Desactivar QUIC hace más lenta la navegación?
En algunas webs, un poco. QUIC establece las conexiones más rápido y se recupera mejor cuando se pierden paquetes, así que la diferencia se nota sobre todo en conexiones móviles o Wi-Fi débiles.
¿Por qué pasa sobre todo en YouTube y en las webs de Google?
Chrome usa QUIC con ellas más a menudo que con la mayoría de las webs, porque ofrecen HTTP/3 a todos los visitantes. Un filtro que gestiona mal QUIC se nota ahí primero.
¿Cómo lo soluciono en Android?
Primero alterna entre Wi-Fi y datos móviles y desactiva cualquier app de VPN. Si el error sigue, abre chrome://flags/#enable-quic en Chrome para Android y pon Experimental QUIC protocol en Disabled.
¿Firefox muestra ERR_QUIC_PROTOCOL_ERROR?
No. El código pertenece a Chromium, el motor que hay detrás de Chrome, Edge, Brave y Opera. Firefox tiene su propio soporte de HTTP/3 y sus propios nombres de error.
¿Un proxy o una VPN pueden solucionar el error?
Una VPN es más a menudo la causa que el remedio. Un proxy en el navegador elimina el error solo como efecto secundario, porque Chrome no usa QUIC a través de proxies normales; desactivar la opción de QUIC consigue lo mismo.
En resumen
ERR_QUIC_PROTOCOL_ERROR significa que una conexión QUIC, el transporte UDP que hay detrás de HTTP/3, se rompió cuando la web ya había empezado a responder, así que Chrome no pudo volver a TCP sin avisar. Prueba otra red, la VPN y la protección web de tu antivirus para encontrar qué interfiere, y pon Experimental QUIC protocol en Disabled si necesitas la página ahora. Si usas un navegador con proxies por trabajo, espera ver HTTP/2 ahí; puedes comparar tipos de proxy y protocolos en nuestra página de proxies.
