Cómo solucionar ERR_SPDY_PROTOCOL_ERROR en Chrome

ERR_SPDY_PROTOCOL_ERROR es un error de red de Chrome que ocurre cuando el navegador no puede establecer o mantener una sesión SPDY o HTTP/2 válida con un servidor web. Se manifiesta como una carga de página fallida, generalmente acompañada de la pantalla de error estándar de Chrome, y puede ser provocada por conexiones de socket obsoletas, datos de caché corruptos, incompatibilidades TLS/SSL, extensiones que interfieren o una negociación de protocolo mal configurada en el servidor.

El nombre del error hace referencia a SPDY — el protocolo de transporte multiplexado de Google, ahora obsoleto, que precedió a HTTP/2. Aunque Chrome eliminó el soporte nativo de SPDY después de la versión 51, la capa interna de gestión de sockets y sesiones sigue utilizando terminología derivada de SPDY, razón por la cual el código de error persiste incluso en conexiones modernas HTTP/2 y HTTP/3. Comprender esta distinción es esencial para diagnosticar la causa raíz con precisión.

Qué causa realmente ERR_SPDY_PROTOCOL_ERROR

Antes de aplicar soluciones a ciegas, es útil conocer los modos de fallo precisos detrás de este error:

• Sesiones de socket SPDY/HTTP2 obsoletas almacenadas en el grupo de conexiones de Chrome que ya no coinciden con el estado TLS actual del servidor
• Certificados SSL/TLS vencidos o reemitidos en el lado del servidor que invalidan una sesión existente sin un restablecimiento limpio del handshake
• Incompatibilidades de ALPN (Application-Layer Protocol Negotiation) donde el servidor anuncia soporte HTTP/2 pero el handshake TLS falla a mitad de sesión
• Datos de perfil del navegador corruptos incluyendo caché, cookies o el archivo de estado de red
• Proxy, VPN o software de seguridad que realiza inspección TLS y rompe la capa de encuadre HTTP/2
• Versiones desactualizadas de Chrome con errores conocidos en la implementación de HTTP/2 o QUIC
• Configuración incorrecta del servidor — por ejemplo, una instancia de Nginx o Apache con un módulo h2 defectuoso, o un certificado vencido en un nodo edge de CDN

Solución 1: Vaciar los sockets SPDY directamente

Esta es la solución más específica y debería ser su primera acción. Chrome mantiene un grupo persistente de sesiones de socket SPDY/HTTP2. Si una sesión se corrompe — por ejemplo, después de que un servidor se reinicia o se reemite un certificado — Chrome seguirá reutilizando la sesión defectuosa hasta que se vacíe explícitamente.

1. Abra una nueva pestaña de Chrome.
2. Navegue a chrome://net-internals/#sockets
3. Haga clic en Flush socket pools.
4. Luego navegue a chrome://net-internals/#dns
5. Haga clic en Clear host cache.
6. Cierre la pestaña y recargue la página con error.

Este vaciado en dos pasos limpia tanto el grupo de sesiones de la capa de transporte como la caché de resolución DNS simultáneamente, lo que aborda las dos causas más comunes dentro del navegador en un solo paso.

Por qué la URL antigua ya no funciona: Muchas guías aún hacen referencia a chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active. Chrome eliminó la pestaña de Eventos en versiones más recientes. Use #sockets y #dns directamente.

Solución 2: Limpiar la caché y las cookies del navegador

Las respuestas HTTP almacenadas en caché, las cookies guardadas y el estado obsoleto de HSTS (HTTP Strict Transport Security) pueden entrar en conflicto con la configuración TLS o de protocolo actual de un servidor.

1. Abra Chrome y presione Ctrl+Shift+Delete (Windows/Linux) o Cmd+Shift+Delete (macOS).
2. Establezca el Intervalo de tiempo en Todo el tiempo.
3. Marque Cookies y otros datos de sitios e Imágenes y archivos en caché.
4. Haga clic en Borrar datos.

Para un enfoque más quirúrgico — si solo desea borrar datos de un dominio específico sin eliminar todo el estado de su navegador — use lo siguiente:

1. Navegue a chrome://settings/siteData
2. Busque el dominio afectado.
3. Elimine solo las cookies y el almacenamiento de ese sitio.

Además, borre el estado HSTS del dominio en chrome://net-internals/#hsts ingresando el nombre de host en Delete domain security policies. Una entrada HSTS obsoleta puede forzar a Chrome a una ruta de actualización que entra en conflicto con un servidor que ha cambiado su configuración TLS.

Solución 3: Actualizar Google Chrome

Las implementaciones de HTTP/2 y QUIC de Chrome reciben parches frecuentes. Usar una versión desactualizada puede significar que está cargando errores conocidos de manejo de protocolos que ya han sido corregidos en versiones posteriores.

1. Haga clic en el menú de tres puntos y vaya a Ayuda > Acerca de Google Chrome.
2. Chrome buscará y descargará actualizaciones automáticamente.
3. Haga clic en Reiniciar para aplicar la actualización.

Para verificar su versión actual desde la barra de direcciones, navegue a chrome://version/. Compare el número de compilación con el blog de Chrome Releases para confirmar que está en el último canal estable.

Solución 4: Deshabilitar VPN, proxy y herramientas de inspección TLS

Las VPN, los proxies corporativos y los productos antivirus que realizan inspección profunda SSL/TLS (también llamada interceptación HTTPS) son una causa frecuente y poco diagnosticada de ERR_SPDY_PROTOCOL_ERROR. Estas herramientas terminan la conexión TLS en el cliente, la vuelven a cifrar con su propio certificado y la reenvían al servidor. Si la implementación HTTP/2 de la herramienta es incompleta o su cadena de certificados no es de confianza, Chrome rechazará la sesión.

Para deshabilitar la configuración de proxy en Windows:

1. Presione Win+I para abrir Configuración.
2. Vaya a Red e Internet > Proxy.
3. Establezca Detectar la configuración automáticamente en Activado y Usar un servidor proxy en Desactivado.

Para deshabilitar la configuración de proxy mediante el Símbolo del sistema:

netsh winhttp reset proxy

Para verificar si hay un proxy activo actualmente:

netsh winhttp show proxy

Si está en una red corporativa, consulte con su administrador de TI antes de deshabilitar la configuración de proxy, ya que hacerlo puede violar la política de red. En su lugar, pregunte si la herramienta de inspección SSL admite el modo de paso directo HTTP/2.

Solución 5: Restablecer la pila TCP/IP y vaciar la caché DNS

Las entradas corruptas de la pila TCP/IP o una caché DNS envenenada pueden causar fallos de conexión que se manifiestan como errores de protocolo. Esta solución opera en la capa de red del sistema operativo, por debajo del propio Chrome.

Abra el Símbolo del sistema como Administrador (presione Win+R, escriba cmd, luego presione Ctrl+Shift+Enter), y ejecute los siguientes comandos en secuencia:

netsh int ip reset
netsh winsock reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew

Reinicie su equipo después de ejecutar estos comandos. El comando netsh winsock reset es particularmente importante — un catálogo Winsock corrupto puede causar errores de protocolo intermitentes y aparentemente aleatorios que son difíciles de rastrear hasta su origen.

En macOS, el comando equivalente para vaciar DNS es:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Solución 6: Deshabilitar o aislar extensiones del navegador

Las extensiones que interceptan solicitudes de red — bloqueadores de anuncios, herramientas de privacidad, extensiones antivirus, extensiones VPN y conmutadores de proxy personalizados — pueden corromper los marcos HTTP/2 o inyectar encabezados que violan la especificación HTTP/2, provocando un error de protocolo.

Método de aislamiento sistemático:

1. Abra chrome://extensions/
2. Deshabilite todas las extensiones simultáneamente.
3. Recargue la página con error.
4. Si el error desaparece, vuelva a habilitar las extensiones de una en una, recargando la página después de cada una, hasta identificar la culpable.

Alternativamente, abra Chrome en modo Incógnito (Ctrl+Shift+N), que deshabilita todas las extensiones de forma predeterminada (a menos que las haya habilitado explícitamente en Incógnito). Si la página carga correctamente en Incógnito, una extensión es definitivamente la causa.

Solución 7: Reiniciar el router o módem

Las tablas NAT (Network Address Translation) y la inspección de paquetes con estado en los routers de consumo pueden mantener entradas de sesión TCP obsoletas que impiden que las nuevas conexiones HTTP/2 completen su handshake. Un ciclo de apagado completo — no solo un reinicio por software — borra estas tablas.

1. Apague completamente el router y el módem.
2. Espere 60 segundos (no 30 — los condensadores necesitan tiempo para descargarse completamente y borrar el estado volátil).
3. Encienda primero el módem, espere a que se sincronice completamente y luego encienda el router.
4. Espere a tener una conexión completa antes de realizar pruebas.

Solución 8: Deshabilitar temporalmente el antivirus o el firewall

El software de seguridad con funciones de análisis HTTPS o escudo web funciona de manera similar a un proxy de inspección TLS corporativo. Intercepta el handshake TLS, lo que puede romper la negociación de sesión HTTP/2 si el motor del software de seguridad no admite completamente la extensión ALPN o el encuadre HTTP/2.

Los productos comunes conocidos por causar este problema incluyen Avast, AVG, Kaspersky y ESET cuando sus módulos de protección web están activos.

• Deshabilite temporalmente la función Escudo Web o Análisis HTTPS específicamente (no todo el antivirus).
• Pruebe la URL con error.
• Si el error se resuelve, busque una opción para agregar el sitio afectado a una lista de exclusión de análisis HTTPS en lugar de deshabilitar la protección globalmente.

Solución 9: Crear un nuevo perfil de Chrome

Un perfil de usuario de Chrome corrupto — específicamente la subcarpeta Network dentro del directorio del perfil — puede causar ERR_SPDY_PROTOCOL_ERROR persistentes que sobreviven a los vaciados de caché y de sockets. El archivo de estado de red del perfil almacena datos HSTS, registros de transparencia de certificados y resultados de negociación de protocolo en caché.

Para probar con un perfil nuevo:

1. Navegue a chrome://settings/
2. Desplácese hasta Personas y haga clic en Agregar persona (o Agregar perfil).
3. Cree un perfil de prueba mínimo.
4. Abra la URL con error en el nuevo perfil.

Si la URL carga correctamente en el nuevo perfil, el problema está aislado en el estado de red almacenado de su perfil original. Puede eliminar manualmente la carpeta Network del directorio de su perfil sin perder marcadores ni contraseñas:

• Windows: %LOCALAPPDATA%GoogleChromeUser DataDefaultNetwork
• macOS: ~/Library/Application Support/Google/Chrome/Default/Network
• Linux: ~/.config/google-chrome/Default/Network

Elimine la carpeta Network con Chrome cerrado y luego reinícielo.

Solución 10: Diagnosticar y escalar problemas del lado del servidor

Si todas las soluciones del lado del cliente fallan, el error se origina en el servidor. Las causas comunes del lado del servidor incluyen:

• Certificado SSL/TLS vencido o recientemente reemitido sin reiniciar el servidor para cargar el nuevo certificado
• Configuración HTTP/2 defectuosa en Nginx (directiva http2 mal configurada) o Apache (mod_http2 cargado pero Protocols h2 http/1.1 no configurado correctamente)
• Configuración incorrecta de CDN o proxy inverso donde el nodo edge y el servidor de origen tienen configuraciones de protocolo en conflicto
• Incompatibilidad de versión TLS — por ejemplo, un servidor configurado para usar solo TLS 1.3 mientras que un proxy intermedio solo admite TLS 1.2

Ejemplo de configuración correcta de HTTP/2 en Nginx:

server {
    listen 443 ssl;
    http2 on;
    ssl_certificate     /etc/ssl/certs/your_domain.crt;
    ssl_certificate_key /etc/ssl/private/your_domain.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
}

Nota: En Nginx 1.25.1+, http2 on reemplaza la sintaxis antigua listen 443 ssl http2. Usar la sintaxis obsoleta en versiones más recientes puede causar fallos en la negociación ALPN.

Ejemplo de configuración correcta de HTTP/2 en Apache:

Protocols h2 http/1.1
SSLEngine on
SSLCertificateFile    /etc/ssl/certs/your_domain.crt
SSLCertificateKeyFile /etc/ssl/private/your_domain.key

Si administra su propia infraestructura de servidor, asegurarse de que sus Certificados SSL sean válidos, estén correctamente encadenados y se renueven antes de su vencimiento elimina el desencadenante más común del lado del servidor para este error. Los entornos de alojamiento que funcionan en Hosting VPS correctamente mantenidos le brindan acceso directo a los archivos de configuración del servidor, lo que facilita la aplicación de estas soluciones sin tener que esperar a un proveedor de hosting compartido.

Para equipos que ejecutan aplicaciones web en Servidores Dedicados, verificar que mod_http2 o el módulo HTTP/2 de Nginx esté correctamente compilado y habilitado debería ser parte de cualquier lista de verificación posterior a la implementación.

Herramientas de diagnóstico para identificar la causa raíz más rápidamente

Antes de trabajar en cada solución secuencialmente, use estas herramientas para identificar el origen:

El comando curl es particularmente útil para confirmar si el problema es específico del navegador o afecta a todo el servidor:

curl -v --http2 https://your-domain.com 2>&1 | grep -E "ALPN|HTTP|SSL|error"

Si curl también falla al negociar HTTP/2, el problema es definitivamente del lado del servidor. Si curl tiene éxito pero Chrome falla, el problema está en el estado de sesión del navegador o en una herramienta de interceptación local.

ERR_SPDY_PROTOCOL_ERROR vs. errores de red relacionados de Chrome

Para sitios donde QUIC está causando inestabilidad, puede deshabilitarlo en chrome://flags/#enable-quic estableciendo la flag en Disabled. Esto obliga a Chrome a recurrir a HTTP/2 basado en TCP o HTTP/1.1.

Matriz de decisión técnica: qué solución aplicar primero

Use esta matriz para priorizar su solución de problemas según el contexto en que aparece el error:

Si administra su propio servidor web y necesita un panel de control para simplificar la gestión de SSL y protocolos, los Paneles de Control VPS proporcionan interfaces gráficas para la instalación de certificados y la configuración del servidor web que reducen el riesgo de configuración incorrecta manual. Para proyectos más pequeños en Hosting Web Compartido, la configuración del protocolo se gestiona a nivel de infraestructura — contacte con soporte si sospecha una configuración incorrecta de HTTP/2 en el servidor.

Lista de verificación antes de escalar

Trabaje en esta lista de verificación en orden. Deténgase en el paso que resuelva el error.

• [ ] Vaciar grupos de sockets en chrome://net-internals/#sockets
• [ ] Limpiar la caché de host DNS en chrome://net-internals/#dns
• [ ] Eliminar la política HSTS del dominio en chrome://net-internals/#hsts
• [ ] Borrar toda la caché y las cookies del navegador (Todo el tiempo)
• [ ] Probar en modo Incógnito para descartar extensiones
• [ ] Probar en un segundo navegador (Firefox, Edge) para descartar problemas específicos de Chrome
• [ ] Deshabilitar temporalmente el análisis HTTPS del antivirus
• [ ] Deshabilitar VPN o proxy
• [ ] Ejecutar netsh winsock reset y ipconfig /flushdns como Administrador
• [ ] Apagar y encender el router y el módem (descarga completa de 60 segundos)
• [ ] Crear un nuevo perfil de Chrome y eliminar la carpeta Network del perfil antiguo
• [ ] Ejecutar curl -v --http2 https://your-domain.com para determinar si el problema es del lado del servidor
• [ ] Si es del lado del servidor: auditar la validez del certificado SSL, la configuración del módulo HTTP/2 y recargar el proceso del servidor
• [ ] Actualizar Chrome a la última versión estable

Preguntas frecuentes

¿Qué es ERR_SPDY_PROTOCOL_ERROR y por qué sigue apareciendo si SPDY está obsoleto?

La pila de red interna de Chrome heredó códigos de error de la era SPDY que nunca fueron renombrados. El error ahora aparece ante cualquier fallo en la capa de sesión HTTP/2 o QUIC — incluyendo fallos de negociación ALPN, handshakes TLS defectuosos y entradas obsoletas del grupo de conexiones — aunque SPDY en sí no se ha utilizado desde Chrome 51.

¿Por qué el error aparece en un solo sitio web pero no en otros?

Esto casi siempre indica una sesión de socket de Chrome obsoleta específica de ese dominio, o un problema del lado del servidor en ese host en particular — como un certificado recientemente reemitido que invalidó las sesiones existentes, o una configuración HTTP/2 defectuosa en ese servidor. Vaciar los grupos de sockets y probar con curl --http2 confirmará cuál es.

¿Puede el software antivirus realmente causar ERR_SPDY_PROTOCOL_ERROR?

Sí. Los productos de seguridad que realizan inspección HTTPS (Avast, AVG, Kaspersky, ESET y otros) actúan como un proxy TLS de intermediario. Si su implementación HTTP/2 es incompleta o su certificado inyectado no es de confianza para el almacén de certificados de Chrome, la sesión HTTP/2 fallará con exactamente este error. Deshabilitar solo el componente de análisis HTTPS — no todo el antivirus — es la solución específica correcta.

¿Cómo sé si el problema está de mi lado o del lado del servidor?

Ejecute curl -v --http2 https://your-domain.com desde la línea de comandos. Si curl también falla al negociar HTTP/2, el servidor está mal configurado. Si curl tiene éxito pero Chrome falla, el problema es local — ya sea una sesión de Chrome obsoleta, una extensión o una herramienta de seguridad interceptora.

¿Afecta este error al SEO o al rendimiento del sitio web?

Para los usuarios finales, sí — el error impide que la página cargue por completo. Para los propietarios de sitios, un ERR_SPDY_PROTOCOL_ERROR persistente causado por una configuración incorrecta de HTTP/2 en el servidor o un certificado vencido resultará en intentos fallidos de rastreo de Googlebot, lo que puede afectar negativamente la cobertura de rastreo y la indexación. Asegurarse de que su certificado SSL sea válido y que su configuración HTTP/2 sea correcta es un requisito básico de SEO técnico.