ERR_QUIC_PROTOCOL_ERROR: qué es y solución en Chrome y Edge

¿Qué es ERR_QUIC_PROTOCOL_ERROR?

ERR_QUIC_PROTOCOL_ERROR significa que la conexión QUIC de Chrome con el sitio web se interrumpió, normalmente cuando el sitio ya había empezado a enviar la página. QUIC es el transporte basado en UDP en el que se apoya HTTP/3. Chrome muestra su página genérica "No se ha podido acceder a este sitio" ("Es posible que la página web … esté temporalmente inactiva o que se haya trasladado definitivamente a otra dirección") con el código debajo; Chromium lo define como el error -356, "There is a QUIC protocol error".

Chrome normalmente se recupera solo: cuando una petición QUIC falla, la repite con una conexión TCP corriente, salvo que el servidor ya hubiera empezado a responder (http_network_transaction.cc). Por eso una red que bloquea QUIC por completo no provoca este error; sí lo provoca una red, una VPN o un servidor que deja que QUIC arranque y luego lo corta.

Solo aparece en navegadores basados en Chromium: Chrome, Edge, Opera, Brave y Vivaldi. Es un fallo distinto de ERR_SSL_PROTOCOL_ERROR (un handshake TLS roto) y de ERR_NETWORK_CHANGED (tu conexión cambió). Recarga primero, porque el reintento suele funcionar; si el error vuelve una y otra vez, las soluciones de abajo empiezan por la más fiable, desactivar QUIC, y después repasan cada causa.

¿Qué es QUIC y por qué lo usa Chrome?

QUIC lo desarrolló Google, se anunció por primera vez en 2013 y el IETF lo estandarizó como RFC 9000 en 2021. Sustituye TCP + TLS por un único protocolo cifrado sobre UDP y es el transporte de HTTP/3 (el DNS privado de Android también lo usa para DNS sobre HTTP/3: consulta qué es el DNS privado).

Una conexión TCP + TLS 1.3 necesita dos viajes de ida y vuelta antes de la primera petición; QUIC necesita uno y puede reanudarse con cero. El 7 de octubre de 2020, Google anunció que el 25 % de los usuarios de Chrome Stable ya usaba IETF QUIC (borrador h3-29). Google midió que la latencia de Búsqueda bajaba más de un 2 %, el rebuffering de YouTube más de un 9 % y que el rendimiento subía más de un 3 % en escritorio y un 7 % en móvil (Chromium Blog).

Chrome solo usa QUIC cuando un sitio lo anuncia, en una cabecera Alt-Svc o en un registro HTTPS de DNS. Comprobamos 20 de los sitios más visitados el 26 de octubre de 2026: 10 anuncian HTTP/3 en su cabecera Alt-Svc (Google, YouTube, Facebook, Instagram, Amazon, LinkedIn, Bing, WhatsApp, Cloudflare y OpenAI).

¿Qué causa ERR_QUIC_PROTOCOL_ERROR?

Todas las causas siguen el mismo patrón: QUIC arrancó y luego algo lo rompió.

• Una red que deja arrancar QUIC y luego lo corta — firewalls, routers o equipos del proveedor de Internet que descartan o dejan caducar el tráfico UDP a mitad de una transferencia. (Una red que bloquea UDP 443 por completo solo hace que Chrome use TCP, sin ningún error.)
• Una VPN que pierde el UDP a mitad de conexión — cuando una VPN se reconecta, cambia de servidor o de ruta, o deja caducar los flujos UDP inactivos, una conexión QUIC abierta muere. (Un camino demasiado pequeño para QUIC falla durante el handshake, y ahí Chrome simplemente usa TCP.)
• Software de seguridad que inspecciona el tráfico — la "protección web" de un antivirus o firewall que intercepta las conexiones puede romper los flujos QUIC.
• Una conexión inestable — Wi-Fi débil o cambiar de red en mitad de una descarga.
• La configuración HTTP/3 del sitio web — un servidor o CDN que anuncia HTTP/3 pero cuya pila QUIC falla a mitad de la respuesta. Entonces todos ven el error en ese único sitio, en cualquier red: el Verificador de páginas caídas muestra si también falla para otros.
• No es una causa: un proxy — Chrome solo usa QUIC en conexiones directas, así que con un proxy configurado todas las peticiones van por TCP.

Solución 1: desactivar el protocolo QUIC en Chrome

La solución más fiable: con QUIC desactivado, Chrome usa HTTP/2 (o HTTP/1.1) sobre TCP en todos los sitios. Las páginas siguen cargando; lo que pierdes son las ventajas de velocidad de QUIC, que Google midió en torno a un 2 % más rápido en Búsqueda y un 9 % menos de rebuffering en YouTube.

Para administradores de TI: la directiva de Chrome y Edge QuicAllowed en false desactiva QUIC en los equipos gestionados, sin tocar chrome://flags.

Desactivar QUIC en Google Chrome

Sigue estos pasos para desactivar QUIC en Chrome en Windows, Mac o Linux.

1. Open Chrome and type in the address bar:
   chrome://flags/#enable-quic

2. Find "Experimental QUIC protocol"

3. Change the dropdown from "Default" to "Disabled"

4. Click "Relaunch" at the bottom to restart Chrome

5. Verify: visit the website that showed the error

Desactivar QUIC en Microsoft Edge

Como Edge está basado en Chromium, el proceso es casi idéntico.

1. Open Edge and type in the address bar:
   edge://flags/#enable-quic

2. Find "Experimental QUIC protocol"

3. Change to "Disabled"

4. Click "Restart" to apply

Desactivar QUIC en Opera y Brave

Opera y Brave usan el mismo sistema de flags de Chromium.

Opera:  opera://flags/#enable-quic → Disabled → Restart
Brave:  brave://flags/#enable-quic → Disabled → Restart

Solución 2: restablecer las conexiones de Chrome

Borrar datos rara vez lo arregla, pero restablecer las conexiones abiertas sí puede: Chrome empieza entonces conexiones QUIC (o TCP) nuevas con el sitio.

Vaciar las conexiones y después borrar la caché

Empieza por Flush socket pools (mira la nota de abajo). Si el error sigue, borra la caché:

1. Press Ctrl+Shift+Delete (Windows/Linux) or Cmd+Shift+Delete (Mac)

2. Choose More → All time for the time range

3. Tick "Cached images and files"

4. Click "Delete data" ("Delete from this device" if you're signed out)

5. Restart Chrome and try the website again

Solución 3: desactivar las extensiones del navegador

Rara vez es la causa: las extensiones no pueden cambiar el propio QUIC, y las extensiones "VPN" de Chrome de escritorio son en realidad proxies, que impiden que Chrome use QUIC.

Abre el sitio en una ventana de Incógnito (Ctrl+Shift+N), donde las extensiones están desactivadas salvo que las hayas permitido. Si allí carga, desactiva tus extensiones una por una en chrome://extensions/ para encontrar la responsable.

Solución 4: revisar el firewall y el antivirus

Un firewall que bloquea el puerto UDP 443 por completo no causa este error: Chrome simplemente usa TCP. El problema es un firewall o una suite de seguridad que deja arrancar QUIC y luego lo descarta o lo inspecciona.

Permite UDP 443 de salida por completo o bloquéalo por completo. Así se comprueban las configuraciones habituales.

Firewall de Windows

El Firewall de Windows Defender permite el tráfico saliente por defecto y una regla de bloqueo siempre gana a una de permiso, así que busca una regla de bloqueo que alguien haya añadido y desactívala. Ejecuta PowerShell como administrador:

# List enabled outbound block rules that cover UDP (or any protocol)
Get-NetFirewallRule -Direction Outbound -Action Block -Enabled True |
  Where-Object { ($_ | Get-NetFirewallPortFilter).Protocol -in 'UDP', 'Any' } |
  Select-Object Name, DisplayName

# Turn off the rule that blocks UDP 443 (use its Name from the list)
Disable-NetFirewallRule -Name '<Name>'

Firewall de macOS

El firewall integrado de macOS solo controla las conexiones entrantes, así que no puede bloquear QUIC. Si usas un firewall de salida como Little Snitch o LuLu, revisa sus reglas para el tráfico UDP de Chrome al puerto 443.

Firewalls a nivel del router

La prueba más rápida: conéctate al punto de acceso móvil de tu teléfono y carga el sitio. Si el error desaparece, la causa es tu router, el equipo de tu proveedor o el firewall de la oficina.

Después busca en la página de administración del router (normalmente 192.168.1.1 o 192.168.0.1) los ajustes de firewall, "SPI" o seguridad que limiten UDP, y actualiza su firmware.

Solución 5: revisar tu VPN

Una VPN tuneliza todo tu tráfico, UDP incluido, así que QUIC normalmente pasa por ella. Los problemas empiezan cuando el propio túnel es inestable: una reconexión, un cambio de servidor o de ruta, o una VPN que deja caducar los flujos UDP inactivos mata las conexiones QUIC abiertas.

Desconecta la VPN y recarga. Si el error desaparece, prueba esto:

• Cambia de servidor o de protocolo de la VPN — un servidor más estable u otro protocolo suele acabar con las caídas
• VPN corporativas — muchas redes de empresa bloquean QUIC a propósito para poder inspeccionar HTTPS; sigue la configuración de TI y desactiva QUIC si los errores persisten
• Deja QUIC desactivado mientras uses la VPN — la Solución 1 funciona con cualquier VPN, porque Chrome usa entonces TCP

Solución 6: busca un proxy oculto o un filtro de tráfico

Un ajuste de proxy no causa este error: Chrome solo usa QUIC en conexiones directas, así que con un proxy todas las peticiones van por TCP. Lo que sí puede parecer un proxy es el software de seguridad o de VPN que filtra el tráfico a nivel de red sin que haya ningún ajuste de proxy.

Si el error aparece en todas las redes pero solo en este ordenador, desactiva ese software ("web shield", "protección de red", una app de VPN que se ejecuta en segundo plano) de uno en uno y recarga.

Solución 7: actualizar Chrome a la última versión

El código QUIC de Chrome se actualiza con regularidad, y las actualizaciones corrigen errores del lado de Chrome en la conexión. Actualiza Chrome (o Edge, Opera, Brave) antes de cambiar nada más en un ordenador que ha pasado un tiempo sin conexión.

1. Open Chrome → click ⋮ (three dots) → Help → About Google Chrome

2. Chrome will automatically check for updates

3. If an update is available, click "Relaunch" to apply

4. After updating, verify your Chrome version:
   chrome://version
   
   Look for the version number 

Problemas de QUIC en el servidor (para propietarios de sitios web)

Si eres propietario de un sitio web y tus visitantes informan de ERR_QUIC_PROTOCOL_ERROR, el problema puede estar en tu servidor. Estas son las causas más comunes en el servidor.

• Ajuste HTTP/3 de Cloudflare — si los visitantes informan del error y usas Cloudflare, revisa Speed > Settings > Protocol Optimization > HTTP/3 y prueba con él desactivado durante un tiempo
• El HTTP/3 de tu propio servidor — nginx tiene HTTP/3 desde la versión 1.25.0 (listen 443 quic reuseport; más una cabecera Alt-Svc); LiteSpeed y Caddy también lo admiten. Asegúrate de que el listener UDP del puerto 443 es accesible y de que tu pila QUIC está actualizada. QUIC siempre usa TLS 1.3: el Verificador SSL muestra si tu servidor lo ofrece
• Balanceadores de carga que no reenvían UDP — los balanceadores de aplicación como AWS ALB solo transportan TCP. Si anuncias h3 en Alt-Svc sin reenviar UDP 443, Chrome marca QUIC como roto para tu sitio durante 5 minutos, luego reintenta duplicando la espera hasta 2 días, y compite con TCP cada vez: quita la cabecera o usa un balanceador de capa 4 que admita UDP

# Test HTTP/3 only, with no fallback (needs a curl built with HTTP/3)
curl --http3-only -sI https://your-domain.com

# Check something listens on UDP 443 (as root; firewalls are separate)
ss -ulnp 'sport = :443'

# Verify Alt-Svc header (tells browsers QUIC is available)
curl -sI https://your-domain.com | grep -i alt-svc
# Expected: alt-svc: h3=":443"; ma=86400

¿Debes mantener QUIC activado o desactivarlo?

Desactivar QUIC es una solución segura, pero en una red sana pierdes velocidad real. Una forma práctica de decidir:

Mantén QUIC activado en casa, con datos móviles y en cualquier red donde el error no aparezca. Los propios datos de Google muestran Búsqueda más rápida, menos rebuffering de vídeo y mayor rendimiento con él, y QUIC mantiene las conexiones vivas cuando tu teléfono pasa del Wi-Fi a los datos móviles.

Desactiva QUIC en una red o VPN donde el error siga volviendo. Chrome usa entonces HTTP/2 (o HTTP/1.1) sobre TCP, que cualquier red admite; la mayoría de la gente no notará la diferencia en una buena línea de banda ancha.

Cuando el mismo tipo de fallo ocurre con HTTP/2 en lugar de QUIC, Chrome muestra ERR_HTTP2_PROTOCOL_ERROR, que tiene sus propias causas y soluciones.