ERR_SSL_PROTOCOL_ERROR: solución en Chrome y Android

¿Qué es ERR_SSL_PROTOCOL_ERROR?

ERR_SSL_PROTOCOL_ERROR significa que la conexión segura se rompió durante su handshake TLS, antes de que tu navegador pudiera cargar nada. Chrome y Edge lo muestran como «Este sitio web no puede proporcionar una conexión segura. example.com ha enviado una respuesta no válida.» Si la dirección es localhost, tu servidor de desarrollo casi seguro habla HTTP sin cifrar: abre http://localhost en su lugar (consulta la sección para desarrolladores más abajo).

Toda conexión HTTPS empieza con un handshake TLS, en el que el navegador y el servidor acuerdan una versión del protocolo (TLS 1.2 o 1.3) y los cifrados, e intercambian certificados. ERR_SSL_PROTOCOL_ERROR significa que esa negociación falló: el otro lado respondió con algo que no es TLS válido, o rechazó el handshake de una forma que el navegador no supo clasificar.

Ocurre antes de que se envíe cualquier solicitud HTTP, así que no es un código de estado HTTP. La lista de errores de Chromium lo define como el error -107 con una sola línea, «An SSL protocol error occurred»: el error comodín de un handshake roto, a diferencia del error específico -113, «no hay una versión de protocolo ni un cifrado en común».

Cómo se ve el ERR_SSL_PROTOCOL_ERROR

Chrome y otros navegadores basados en Chromium muestran este error como una advertencia de página completa con el mensaje «Este sitio web no puede proporcionar una conexión segura». Debajo verás el código de error concreto. Estas son las variantes más comunes.

• localhost ha enviado una respuesta no válida (en inglés, «localhost sent an invalid response»): la versión que ven los desarrolladores, con https:// abierto en un servidor local que habla HTTP sin cifrar
• ERR_SSL_PROTOCOL_ERROR: el código de error que Chrome imprime en letra pequeña bajo el mensaje
• net::ERR_SSL_PROTOCOL_ERROR: el código de error interno completo que se muestra en la consola de Chrome DevTools
• Este sitio web no puede proporcionar una conexión segura: el mensaje principal que Chrome muestra al usuario
• [dominio] ha enviado una respuesta no válida: el texto de error detallado que Chrome muestra bajo el mensaje principal
• ERR_SSL_PROTOCOL_ERROR en todos los navegadores: cuando el error aparece a la vez en Chrome, Edge, Brave y Opera (indica un problema del servidor o de todo el sistema, no un fallo propio de un navegador)

¿Qué causa ERR_SSL_PROTOCOL_ERROR?

Este error tiene causas tanto del lado del cliente (tu dispositivo) como del lado del servidor (el sitio web). Identificar de qué lado está el problema es el primer paso para arreglarlo. Si el error aparece en todos los sitios web, el problema está de tu lado. Si solo aparece en un sitio concreto, lo más probable es que esté en el servidor.

• HTTPS enviado a un servidor que habla HTTP: el caso más buscado, https://localhost en un servidor de desarrollo, o un sitio cuyo puerto 443 no está configurado para TLS. El navegador inicia un handshake y recibe texto sin cifrar, que Chrome muestra como «ha enviado una respuesta no válida».
• Análisis SSL/HTTPS del antivirus: el software de seguridad que intercepta HTTPS (Avast, Kaspersky, Bitdefender, ESET) se mete en el handshake y puede romperlo, en todos los sitios a la vez.
• Interferencia de una VPN o un proxy: las VPN y los proxies corporativos que inspeccionan el tráfico HTTPS pueden corromper el handshake, sobre todo justo después de cambiar de red.
• Una red que filtra el sitio: los filtros del proveedor de internet, del colegio, del trabajo o del país, y los bloqueadores basados en DNS, rompen el handshake a propósito en los sitios que bloquean. La pista: el sitio carga con datos móviles o en otra red Wi-Fi.
• Una configuración TLS rota en el servidor: el puerto 443 responde en HTTP sin cifrar (un bloque de servidor en el 443 sin TLS activado), u otro programa escucha en el puerto 443.
• Extensiones del navegador: las extensiones de privacidad, bloqueo de anuncios y seguridad que reescriben las solicitudes HTTPS pueden interferir con el handshake.
• Estado obsoleto del navegador: datos de sesión en caché que ya no coinciden con el servidor.
• Suele confundirse con él: un servidor atascado en TLS 1.0 o 1.1 muestra ERR_SSL_VERSION_OR_CIPHER_MISMATCH («utiliza un protocolo no admitido»); un certificado vencido, con el nombre equivocado o autofirmado, o un reloj incorrecto, muestra un error de certificado (NET::ERR_CERT_…); y un problema de QUIC (HTTP/3) muestra ERR_QUIC_PROTOCOL_ERROR. Consulta ERR_SSL_VERSION_OR_CIPHER_MISMATCH y «Tu conexión no es privada».

ERR_SSL_PROTOCOL_ERROR en localhost (desarrolladores)

localhost ha enviado una respuesta no válida. ERR_SSL_PROTOCOL_ERROR casi siempre significa que abriste https://localhost en un servidor de desarrollo que solo habla HTTP sin cifrar. El navegador inicia un handshake TLS, el servidor responde con texto HTTP normal y Chrome muestra esa respuesta como no válida. Firefox muestra el mismo error como SSL_ERROR_RX_RECORD_TOO_LONG.

• Usa la dirección que imprime el servidor: cambia https://localhost:3000 por http://localhost:3000. Los servidores de desarrollo de Next.js, Vite, React, Django, Rails y Flask sirven HTTP a menos que actives HTTPS
• Revisa el puerto: https://localhost sin puerto significa el puerto 443. Si tu aplicación corre en el 3000 o el 5173, la solicitud llega a otro programa, o a ninguno
• Chrome insiste en cambiar a https://: puede deberse a una redirección guardada de una aplicación anterior en el mismo puerto: borra las imágenes y archivos en caché o prueba en una ventana de incógnito. (Las versiones de Chrome anteriores a la 132 también podían conservar una entrada HSTS para localhost, que se borra en Delete domain security policies en chrome://net-internals/#hsts)
• Necesitas HTTPS en local (callbacks de OAuth, cookies seguras): next dev --experimental-https crea un certificado de confianza local con mkcert; Vite acepta opciones de certificado en server.https, o @vitejs/plugin-basic-ssl para uno autofirmado rápido; en cualquier otro caso, mkcert -install && mkcert localhost 127.0.0.1 genera archivos que tu servidor puede cargar
• Un certificado autofirmado da otro error: NET::ERR_CERT_AUTHORITY_INVALID, no este. Haz clic en Configuración avanzada → Acceder a localhost (sitio no seguro), o mejor, usa un certificado de mkcert (la antigua opción allow-insecure-localhost ya caducó)

Cómo solucionar ERR_SSL_PROTOCOL_ERROR (para usuarios)

Empieza por la Solución 1: en dos minutos te dice si el problema está en tu navegador, en tu dispositivo o red, o en el sitio. Después sigue la lista hacia abajo.

Solución 1: prueba el modo incógnito y otra red

Una ventana de incógnito empieza sin cookies, sin caché y sin extensiones (a menos que las hayas permitido ahí). Abre el sitio en una ventana de incógnito (Ctrl+Shift+N en Chrome y Edge, Ctrl+Shift+P en Firefox) y luego en otra red, por ejemplo con los datos móviles de tu teléfono.

Si carga en incógnito, la causa está en tu navegador: una extensión o datos obsoletos (Soluciones 4 y 5). Si solo carga en otra red, tu red, una VPN o un proxy lo filtra o lo intercepta (Solución 3). Si falla en todas partes, prueba el sitio con un verificador SSL: si también falla ahí, solo su propietario puede arreglarlo.

Solución 2: desactiva el análisis SSL/HTTPS del antivirus

Muchos antivirus (Avast, Kaspersky, Bitdefender, ESET, Norton) incluyen una función de «análisis HTTPS» o «inspección SSL» que intercepta las conexiones cifradas actuando como proxy man-in-the-middle. Cuando gestiona mal el handshake de un sitio, todos los navegadores del ordenador fallan en ese sitio.

Busca en tu antivirus ajustes con nombres como Web Shield, HTTPS Scanning, SSL Scanning o Encrypted connections scanning y desactívalos temporalmente. Si el error desaparece, puedes añadir el dominio afectado a la lista de exclusiones del antivirus.

Solución 3: desactiva la VPN o el proxy

Las VPN y los proxies HTTP se sitúan entre tu navegador y el servidor web. Algunas VPN inspeccionan el tráfico HTTPS o enrutan las conexiones por servidores con TLS roto. Los proxies corporativos suelen usar intercepción SSL (parecida al análisis HTTPS del antivirus) que puede romper los handshakes TLS.

Desconecta temporalmente tu VPN e intenta cargar el sitio. Si funciona sin la VPN, el problema está en cómo tu VPN gestiona las conexiones SSL. Prueba con otro servidor de la VPN o contacta con tu proveedor.

Solución 4: desactiva las extensiones del navegador

Las extensiones que filtran o redirigen el tráfico, como las de VPN y proxy y los complementos de seguridad, pueden romper las conexiones seguras.

Ve a chrome://extensions/, desactiva todas las extensiones y recarga la página. Si el error desaparece, vuelve a activarlas de una en una para encontrar la responsable.

Solución 5: borra la caché y las cookies del navegador

A veces las cookies o los datos en caché obsoletos estorban, y borrarlos lleva un minuto.

• Paso 1: Pulsa Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete) para abrir Borrar datos de navegación
• Paso 2: En el intervalo de tiempo, elige Más → Desde siempre
• Paso 3: Marca Cookies y otros datos de sitios y Archivos e imágenes en caché
• Paso 4: Haz clic en Eliminar datos (Eliminar de este dispositivo si no has iniciado sesión) y reinicia Chrome

Para un solo sitio, ve a chrome://settings/content/all, busca el dominio y borra sus datos.

Solución 6: descarta QUIC (HTTP/3)

Chrome prueba QUIC (HTTP/3 sobre UDP) junto con una conexión TCP normal y vuelve a TCP cuando QUIC falla, así que QUIC rara vez causa ERR_SSL_PROTOCOL_ERROR. Si la página o DevTools muestran ERR_QUIC_PROTOCOL_ERROR, la solución es desactivar QUIC (consulta ERR_QUIC_PROTOCOL_ERROR):

• Paso 1: Escribe chrome://flags/#enable-quic en la barra de direcciones
• Paso 2: Busca Experimental QUIC protocol
• Paso 3: Cámbialo de Default a Disabled
• Paso 4: Haz clic en Relaunch para reiniciar Chrome

Las páginas siguen cargando con QUIC desactivado, mediante HTTP/2 sobre TCP; vuelve a activarlo cuando se arregle la red o el sitio.

Solución 7: actualiza tu navegador

Las versiones antiguas del navegador pueden carecer de las funciones TLS y los cifrados que esperan los sitios modernos, y las actualizaciones corrigen errores de TLS.

Actualiza Chrome: ve a chrome://settings/help o Menú → Ayuda → Acerca de Google Chrome. Chrome descarga las actualizaciones automáticamente, pero necesita reiniciarse para aplicarlas. En Edge: edge://settings/help. En Firefox: Menú → Ayuda → Acerca de Firefox.

Solución 8: vaciar la caché DNS

Un DNS obsoleto puede llevar a tu navegador a un servidor antiguo que ya no sirve el sitio por TLS. Vaciar la caché DNS fuerza una consulta nueva.

# Windows (Command Prompt as Admin)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux
sudo resolvectl flush-caches

# Chrome internal DNS cache
# Visit chrome://net-internals/#dns → Click "Clear host cache"

Después de vaciarla, comprueba que el dominio resuelva a la IP correcta con la herramienta Consulta DNS de DNS Robot. Si la dirección IP parece incorrecta, es posible que el sitio haya cambiado de proveedor de hosting y el DNS aún no se haya propagado por completo.

Solución 9: comprueba la fecha y la hora del sistema

Un reloj incorrecto normalmente muestra otro error, NET::ERR_CERT_DATE_INVALID («Tu reloj está adelantado» o «Tu reloj está atrasado»), porque un certificado solo es válido entre dos fechas. Descartarlo lleva diez segundos:

• Windows: Configuración → Hora e idioma → Fecha y hora → activa «Establecer la hora automáticamente» y «Establecer la zona horaria automáticamente»
• Mac: Ajustes del Sistema → General → Fecha y hora → activa «Ajustar fecha y hora automáticamente»
• Linux: Ejecuta sudo timedatectl set-ntp true para activar la sincronización NTP

Solución 10: borra el estado SSL (Windows)

Muchas guías sugieren Borrar estado SSL en las Opciones de Internet de Windows (inetcpl.cpl → Contenido → Borrar estado SSL). Vacía la caché de sesiones de la biblioteca TLS propia de Windows, que usan las aplicaciones basadas en la red de Windows. Chrome y Edge usan su propia biblioteca TLS, así que rara vez cambia algo para ellos.

El equivalente en el navegador es más sencillo: cierra todas las ventanas del navegador (mira la bandeja del sistema por si queda un Chrome en segundo plano) y ábrelo de nuevo. Así se descartan todas las sesiones TLS en caché. Si el error sobrevive a un reinicio completo, pasa a las siguientes soluciones.

Solución 11: restablece la configuración de red (último recurso)

Si nada más funciona, restablece tu pila de red. En Windows, estos comandos restablecen Winsock y TCP/IP, incluidas las direcciones IP estáticas y los servidores DNS que hayas puesto a mano; en macOS y Linux solo vacían la caché DNS o reinician el servicio de red.

# Windows (Command Prompt as Admin)
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

# Then restart your computer

# macOS — flush the DNS cache
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux — restart NetworkManager
sudo systemctl restart NetworkManager

Cómo solucionar ERR_SSL_PROTOCOL_ERROR (para propietarios de sitios web)

Si muchos visitantes informan de ERR_SSL_PROTOCOL_ERROR, el problema está en el servidor: normalmente el puerto 443 responde en HTTP sin cifrar, u otro programa ocupa ese puerto. Los problemas de certificado muestran sus propios errores, pero revísalos ya que estás ahí. (Un certificado y una clave que no coinciden impiden que el servidor cargue la configuración nueva: compruébalo con nginx -t o apachectl configtest después de cada cambio.)

Verifica tu certificado SSL

El primer paso es verificar que tu certificado SSL sea válido, esté bien instalado y no haya vencido. Usa el Verificador SSL de DNS Robot para ver al instante el estado del certificado, la fecha de vencimiento, el emisor y la cadena de certificados.

Estos problemas de certificado muestran sus propios errores en lugar de ERR_SSL_PROTOCOL_ERROR, pero arréglalos ya que estás ahí:

• Certificado vencido (NET::ERR_CERT_DATE_INVALID): los certificados de Let's Encrypt duran 90 días (64 días desde febrero de 2027), así que la renovación debe ejecutarse sola; si falló (el temporizador de certbot no corre, el desafío DNS está roto), el certificado vence en silencio.
• Dominio incorrecto (NET::ERR_CERT_COMMON_NAME_INVALID): el certificado se emitió para example.com pero el sitio se sirve en www.example.com (o al revés). El certificado debe coincidir con el dominio exacto o incluir un comodín (*.example.com).
• Certificado autofirmado (NET::ERR_CERT_AUTHORITY_INVALID): vale para desarrollo, pero los navegadores nunca lo aceptan en producción.
• Certificado revocado (NET::ERR_CERT_REVOKED): la autoridad certificadora lo revocó tras el compromiso de una clave o una emisión incorrecta.
• Certificado equivocado para el nombre (NET::ERR_CERT_COMMON_NAME_INVALID): varios sitios comparten una dirección IP y el servidor no usa SNI (Server Name Indication) para elegir el certificado de cada sitio.

# Check certificate from command line
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Check certificate chain completeness
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>&1 | grep -E "depth|Verify"

# Renew Let's Encrypt certificate
sudo certbot renew --dry-run   # test first
sudo certbot renew

Habilita TLS 1.2 y TLS 1.3

Todos los navegadores modernos exigen al menos TLS 1.2: TLS 1.0 y 1.1 quedaron oficialmente obsoletos con la RFC 8996 en 2021. Si uno de los lados rechaza la versión del otro, el handshake termina con la alerta TLS 70, protocol_version (RFC 8446 §6.2). Un servidor que solo admite TLS 1.0 o 1.1 muestra ERR_SSL_VERSION_OR_CIPHER_MISMATCH en lugar de este error, pero falla igualmente. TLS 1.3 conecta en un solo viaje de ida y vuelta, frente a los dos de TLS 1.2: activa ambos.

# Nginx — ssl_protocols in nginx.conf or site config
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# Apache — in httpd.conf or ssl.conf
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder off

Después de actualizar tu configuración TLS, reinicia el servidor web (sudo systemctl restart nginx o sudo systemctl restart apache2) y comprueba con el Verificador SSL de DNS Robot que los protocolos estén activos.

Instala la cadena de certificados completa

Una cadena incompleta se muestra como error de certificado (NET::ERR_CERT_AUTHORITY_INVALID) en los navegadores y aplicaciones que no pueden completar el intermedio que falta, así que instala la cadena completa mientras revisas. Tu servidor debe enviar tu certificado más los certificados intermedios que lo enlazan con una raíz de confianza.

La mayoría de las autoridades certificadoras ofrecen un archivo «CA bundle» o de «cadena completa». Con Let's Encrypt, usa fullchain.pem (no solo cert.pem). Con otras CA, descarga el certificado intermedio de su documentación y concaténalo con tu certificado.

# Nginx — use fullchain, not just cert
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

# Apache
SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

Verifica la configuración de HSTS

HSTS (HTTP Strict Transport Security) le indica a los navegadores que usen siempre HTTPS para tu dominio. Si tu política HSTS tiene un max-age largo y después se rompe tu configuración TLS, los navegadores no pueden volver a HTTP: los visitantes ven una página de error sin forma de continuar.

Revisa tu cabecera HSTS con el Verificador de encabezados HTTP de DNS Robot. Si pusiste un max-age muy largo (como 2 años) y tu certificado venció, los usuarios que ya visitaron tu sitio quedan bloqueados en HTTPS sin alternativa. Para arreglarlo, primero repara tu certificado SSL y luego los navegadores volverán a conectar con normalidad.

Verifica la configuración del servidor

Este error de servidor rompe el handshake incluso con un certificado válido, y hay otro que muestra un error distinto:

• El puerto 443 sirve HTTP sin cifrar: la causa clásica del lado del propietario: en nginx, listen 443; sin ssl (debe ser listen 443 ssl;), u otro servicio ligado al puerto 443.
• Incompatibilidad de conjuntos de cifrado: un servidor que solo ofrece cifrados que los navegadores rechazan muestra ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Usa cifrados AEAD modernos (AES-GCM, ChaCha20).

Pruébalo desde fuera con openssl s_client -connect example.com:443 -servername example.com </dev/null: «wrong version number» (OpenSSL) o «tlsv1 alert protocol version» (el openssl integrado de macOS) significa que el puerto 443 no habla TLS, y que aparezca un certificado significa que el handshake funciona.

ERR_SSL_PROTOCOL_ERROR en Android

Los usuarios de Android se encuentran con ERR_SSL_PROTOCOL_ERROR tanto en Chrome para Android como en aplicaciones basadas en WebView. Las soluciones difieren un poco de las del escritorio porque Android gestiona los certificados y la configuración de red de otra manera.

• Cambia de red: desactiva el Wi-Fi y prueba con los datos móviles (o al revés). Si el sitio carga, la red lo está filtrando o interceptando
• Desactiva el DNS privado para probar: Ajustes → Redes e Internet → DNS privado → Desactivado (y en Chrome: Configuración → Privacidad y seguridad → Usar DNS seguro). Un servicio DNS con filtrado (bloqueo de anuncios, control parental) envía los sitios que bloquea a un servidor que no puede completar el handshake
• Borra los datos de Chrome: Ajustes → Aplicaciones → Chrome → Almacenamiento → Borrar caché (después Gestionar almacenamiento si no basta)
• Actualiza Chrome: Play Store → tu foto de perfil → Gestionar apps y dispositivo → actualiza Chrome
• Borra las credenciales de red: Ajustes → Seguridad (en los teléfonos más nuevos: Más ajustes de seguridad → Cifrado y credenciales) → Borrar credenciales. Esto elimina todos los certificados instalados por el usuario
• Revisa la fecha y la hora: Ajustes → Sistema → Fecha y hora → automáticas. Un reloj incorrecto muestra un error de certificado, pero es rápido de descartar
• Restablece la configuración de red: Ajustes → Sistema → Opciones de restablecimiento, y después el restablecimiento de Wi-Fi y red móvil (su nombre varía según la versión de Android)

ERR_SSL_PROTOCOL_ERROR en iPhone y iPad

En un iPhone, Chrome muestra ERR_SSL_PROTOCOL_ERROR y Safari dice que «no puede establecer una conexión segura con el servidor» («can't establish a secure connection to the server»). Las causas son las mismas que en un ordenador; los ajustes están en otros sitios:

• Cambia de red: desactiva el Wi-Fi y prueba con los datos móviles. Si el sitio carga, la red Wi-Fi lo está filtrando o interceptando
• Quita las VPN y los perfiles que no reconozcas: Ajustes → General → VPN y gestión de dispositivos. Un perfil que instala su propio certificado o VPN puede interceptar HTTPS
• Prueba sin el Relay privado de iCloud: Ajustes → [tu nombre] → iCloud → Relay privado de iCloud → desactivado, y vuelve a intentarlo
• Revisa los límites de Tiempo de uso: Ajustes → Tiempo de uso → Restricciones, y después el ajuste de contenido web. Un sitio bloqueado falla en lugar de cargar
• Pon el reloj en automático: Ajustes → General → Fecha y hora → Ajuste automático

ERR_SSL_PROTOCOL_ERROR en otros navegadores

ERR_SSL_PROTOCOL_ERROR es un código de error propio de Chromium. Otros navegadores muestran mensajes distintos para el mismo fallo del handshake SSL.

Si el error aparece en todos los navegadores a la vez, el problema está en tu sistema (análisis HTTPS del antivirus, una VPN o un proxy, tu red) o en el servidor (el puerto 443 no sirve TLS correctamente). Si solo falla un navegador, revisa sus extensiones y sus datos en caché.

Códigos de error SSL/TLS relacionados

Chrome tiene varios códigos de error relacionados con SSL. Todos indican problemas distintos del handshake TLS o de los certificados.

Para cualquier error SSL, puedes diagnosticar el problema rápidamente con el Verificador SSL de DNS Robot: muestra el estado del certificado, si la cadena está completa, las versiones de TLS que admite y la fecha de vencimiento en un solo análisis.

Si tu página dice que el sitio «utiliza un protocolo no admitido», tienes ERR_SSL_VERSION_OR_CIPHER_MISMATCH, no este error: consulta cómo solucionar ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Si en cambio la página dice «example.com ha cerrado la conexión de forma inesperada» (ERR_CONNECTION_CLOSED), la conexión se cortó en lugar de romperse. Consulta ERR_CONNECTION_CLOSED para ese caso.