Solucionar err_ssl_protocol_error en Chrome y Edge

Haces clic en el enlace de una tienda online y Chrome muestra en su lugar una página gris y sencilla: «Este sitio web no puede proporcionar una conexión segura», la línea «shop.example ha enviado una respuesta no válida.», una sugerencia para ejecutar los Diagnósticos de red de Windows y, abajo del todo, ERR_SSL_PROTOCOL_ERROR. Al volver a cargar aparece la misma página, y Edge muestra el mismo código.

Puede que la tienda esté realmente rota, pero con la misma frecuencia algo de tu equipo o de tu red se interpuso. Esta guía explica qué significa el código y en qué punto de la negociación segura aparece, las causas que reprodujimos en servidores de prueba, las soluciones en el orden en que conviene probarlas, qué revisar si el sitio es tuyo y qué papel tienen los proxies y las VPN.

¿Qué significa ERR_SSL_PROTOCOL_ERROR?#

Los sitios cuya dirección empieza por https:// usan TLS (Transport Layer Security), el cifrado que hay detrás del candado; su nombre anterior, SSL, sigue vivo en códigos de error como este. Antes de que viaje ninguna página, el navegador y el servidor hacen una breve negociación: acuerdan una versión de TLS y un método de cifrado, el servidor demuestra su identidad y los dos lados crean las claves. El estándar de TLS 1.3, RFC 8446, establece que una negociación fallida termina la conexión.

La lista de errores de red de Chromium, el código fuente que hay detrás de Chrome y Edge, describe el error -107 en una frase corta: «An SSL protocol error occurred.» (Se produjo un error de protocolo SSL). El código que convierte los fallos de TLS en estos números explica tanta vaguedad: cualquier fallo de la negociación sin un código más específico acaba como -107. El código dice que la negociación se rompió, no quién la rompió.

Tampoco es una advertencia de certificado. «La conexión no es privada» y los códigos que empiezan por NET::ERR_CERT_ llegan más tarde, cuando el navegador evalúa el certificado del sitio; aquí la negociación se detuvo antes de ese punto. Los problemas de certificado los explicamos en La conexión no es privada: causas y cómo solucionarlo.

¿Qué te dice la página «Este sitio web no puede proporcionar una conexión segura»?#

Citamos el Chrome en español de España, según los archivos de idioma de Chromium, y la página la reprodujimos en Chromium 145 con Windows 11; en un Mac, el enlace dice «Prueba a ejecutar Diagnósticos de red». En el Chrome para Latinoamérica, el título es «Este sitio no puede proporcionar una conexión segura» y la línea gris dice «envió una respuesta no válida», pero el código no cambia. Edge está construido sobre Chromium y muestra el mismo código, aunque su redacción puede variar. A diferencia de una advertencia de certificado, la página no tiene botón Avanzado, porque no existe ninguna conexión segura con la que continuar.

¿En qué punto de la negociación se rompe?#

Una carga segura de página pasa por estas paradas en una fracción de segundo:

1. Conexión. El navegador se conecta al servidor, normalmente en el puerto 443, el puerto estándar de los sitios seguros. Si esto falla, ves «No se puede acceder a este sitio» en su lugar (This Site Can't Be Reached: qué significa y por qué aparece).
2. Client Hello. El navegador enumera las versiones de TLS y los métodos de cifrado que admite y nombra el sitio al que quiere llegar.
3. Server Hello. El servidor elige una versión y un método. La mayoría de los casos de esta guía se rompen aquí: el navegador recibe algo que no puede leer como TLS, como una página web normal, una página de bloqueo o bytes sin sentido. La sección 5 de RFC 8446 exige que el software TLS termine la conexión cuando llega un mensaje inesperado así.
4. Certificate. El servidor envía su certificado. Un fallo en este punto produce una advertencia de certificado.
5. Finished. Los dos lados confirman las claves, aparece el candado y sale la petición de la página.

Si el navegador y el servidor no comparten ninguna versión de TLS en la parada 3, normalmente porque el servidor solo ofrece TLS 1.0 o 1.1, el título sigue igual, pero el código pasa a ser ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

¿Qué causa ERR_SSL_PROTOCOL_ERROR?#

Reprodujimos los casos principales con pequeños servidores de prueba en nuestro propio equipo. En Chromium 145, tanto un servidor que hablaba HTTP sin cifrar en su puerto seguro como uno que respondía al Client Hello con bytes basura dieron ERR_SSL_PROTOCOL_ERROR. Un servidor limitado a TLS 1.0 y 1.1 dio ERR_SSL_VERSION_OR_CIPHER_MISMATCH, y una conexión cortada a mitad de la negociación dio ERR_CONNECTION_CLOSED o ERR_CONNECTION_RESET.

¿El problema está de tu lado o del lado del sitio?#

1. Abre otros dos o tres sitios seguros. Si también fallan, la causa está en tu dispositivo o en tu red.
2. Abre el sitio que falla en tu teléfono con el Wi-Fi desactivado. Si también falla con datos móviles, el sitio está roto; espera o avisa a su propietario.
3. Si funciona con datos móviles, prueba otro dispositivo en tu Wi-Fi. Un segundo fallo apunta a la red; si funciona, apunta a algún programa de tu equipo.
4. Abre una ventana de incógnito con Más > Nueva ventana de Incógnito en Chrome. Las extensiones solo funcionan ahí si les diste permiso, así que una página que carga en incógnito apunta a una extensión.

¿Cómo se soluciona en un equipo?#

Vuelve a cargar la página después de cada paso.

1. Desactiva las extensiones. En Chrome, selecciona arriba a la derecha Más > Extensiones > Gestionar extensiones y desactiva las extensiones de VPN, de proxy, de bloqueo de anuncios y de «seguridad» (los pasos de Google). En Edge, selecciona Extensiones, a la derecha de la barra de direcciones, después Administrar extensiones, y usa el botón de alternancia que hay junto a cada una (los pasos de Microsoft). Si el error desaparece, vuelve a activarlas de una en una.
2. Prueba tu software de seguridad. Los programas con análisis HTTPS, análisis SSL o protección web se colocan en medio de cada negociación TLS. Pausa solo esa función, vuelve a cargar una vez y después actívala de nuevo. Si la pausa ayudó, actualiza el programa o contacta con su soporte en lugar de dejar la protección desactivada.
3. Desactiva la VPN y las apps de filtrado, incluidas las apps que bloquean anuncios haciendo pasar el tráfico por ellas mismas. Comprueba que no haya ningún proxy olvidado configurado en Windows: Cómo quitar un proxy de Chrome y Windows.
4. Actualiza el navegador. En Chrome, selecciona Más > Ayuda > Información de Google Chrome y después Reiniciar si aparece (los pasos de Google). En Edge, escribe edge://settings/help en la barra de direcciones; también llegas a esa página desde Configuración y más > Ayuda y comentarios. El software de seguridad tiene que entender la negociación que inicia el navegador, así que una gran diferencia de versión entre los dos puede romper el análisis.
5. Cierra el navegador por completo y vuelve a abrirlo. Chrome y Edge guardan en memoria los detalles de las negociaciones recientes; un reinicio completo los borra.

¿Por qué aparece solo en una red?#

Escuelas, oficinas, hoteles, routers con control parental y algunos proveedores de internet filtran sitios web. Cuando un filtro bloquea un sitio seguro respondiendo en su lugar con una página normal sin cifrar, el navegador recibe una página web donde esperaba un Server Hello. Es la misma situación que creó nuestro servidor de prueba con HTTP sin cifrar.

En una red del trabajo o de un centro de estudios, pregunta al departamento de informática; el bloqueo es una decisión de quien gestiona la red, no una avería. Cómo inspeccionan las organizaciones el tráfico cifrado lo explicamos en ¿Qué es la inspección profunda de paquetes (DPI)?.

¿Por qué lo muestran localhost o la página del router?#

Un servidor de desarrollo en tu equipo escucha, por ejemplo, en http://localhost:3000, pero el navegador abre https://localhost:3000. El servidor responde al Client Hello en HTTP sin cifrar, y Chrome muestra ERR_SSL_PROTOCOL_ERROR, exactamente como en nuestra prueba. Los routers, impresoras, cámaras y unidades de red en direcciones como 192.168.1.1 pueden comportarse igual.

Para tu propio dispositivo en tu propia red, escribe http:// delante de la dirección, con el puerto si lo hay. Si el servidor de prueba debe usar HTTPS, actívalo en la configuración del servidor con un certificado en el que confíe tu equipo. Nunca hagas esto con un sitio web público: http:// lo envía todo sin cifrar.

Si el sitio es tuyo: cómo arreglar el servidor#

Cuando los visitantes informan del error y puedes reproducirlo desde un teléfono con datos móviles, revisa el servidor:

1. Haz una prueba desde fuera. El SSL Server Test de Qualys enumera las versiones de TLS que ofrece tu sitio público y la cadena de certificados que envía.
2. Asegúrate de que el puerto 443 habla TLS de verdad. En nginx, el parámetro ssl tiene que estar en la línea listen; listen 443; sin más sirve HTTP sin cifrar en el puerto seguro. En Apache, SSLEngine de mod_ssl está desactivado por defecto, así que un bloque <VirtualHost *:443> necesita SSLEngine on.
3. Ofrece TLS 1.2 y 1.3. RFC 8996 declaró obsoletos TLS 1.0 y 1.1 en 2021, y un servidor limitado a ellos recibe ERR_SSL_VERSION_OR_CIPHER_MISMATCH. nginx ofrece TLS 1.2 y 1.3 por defecto desde la versión 1.23.4.
4. Revisa cada servidor que hay detrás del nombre. Detrás de un balanceador de carga o de una CDN, una sola máquina mal configurada causa el error solo para algunos visitantes o regiones. Para ver lo que reciben los visitantes de otro país, prueba desde una dirección IP de allí, por ejemplo con los Proxies residenciales.
5. Recarga la configuración después de cada cambio.

Un bloque mínimo de nginx; la línea ssl_protocols repite el valor por defecto y solo importa si algo lo cambió:

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
}

Un certificado caducado, un nombre que no coincide o la falta de un certificado intermedio muestran la advertencia de certificado, no esta página.

Nivel avanzado: comprueba si el puerto 443 habla TLS#

Esta comprobación es para propietarios de sitios que usan la línea de comandos. curl viene con Windows 10, Windows 11 y macOS; en Windows PowerShell escribe curl.exe, porque ahí curl es un alias de otro comando. Este comando envía a propósito una petición sin cifrar al puerto seguro:

curl -I http://example.com:443

Usa tu propio dominio y lee la primera línea de la respuesta:

• Una línea de estado normal, como HTTP/1.1 200 OK, o una redirección: el puerto 443 responde en HTTP sin cifrar, así que TLS está desactivado. Nuestro servidor de prueba con HTTP sin cifrar respondió HTTP/1.0 200 OK.
• 400 Bad Request: es la respuesta de nginx cuando HTTP sin cifrar llega a un puerto TLS; su página dice «The plain HTTP request was sent to HTTPS port». TLS está activado.
• curl: (52) Empty reply from server: el servidor descartó la petición sin cifrar, como hizo nuestro servidor de prueba con TLS. TLS está activado.

¿Y si usas un proxy o una VPN?#

Un proxy normal rara vez es la causa. Con un sitio https://, el navegador pide al proxy un túnel y hace la negociación TLS con el sitio a través de él, mientras el proxy pasa los bytes cifrados sin leerlos. En nuestra prueba, un sitio que hablaba HTTP sin cifrar en su puerto seguro dio el mismo ERR_SSL_PROTOCOL_ERROR con proxy y sin él, y un sitio bien configurado pasó intacto. Cambiar de proxy o de servidor VPN no puede reparar un sitio roto.

Los problemas de proxy muestran otros códigos: un túnel rechazado da ERR_TUNNEL_CONNECTION_FAILED (Solucionar err_tunnel_connection_failed en Chrome y Edge), y un proxy HTTP introducido como proxy HTTPS en una extensión de proxy nos dio ERR_PROXY_CONNECTION_FAILED (El servidor proxy no responde: qué es y cómo solucionarlo). La excepción es el software que abre el tráfico cifrado a propósito, como los proxies de depuración y las apps de VPN gratuitas que te piden instalar un certificado; se sitúa dentro de la negociación y puede romperla (¿Qué es un proxy MITM? Guía de Charles, Fiddler y mitmproxy).

El gateway de Proxynet retransmite los túneles sin descifrarlos, así que no instalas ningún certificado nuestro; para usar los Proxies HTTPS en un navegador, consulta Configuración de proxy en Windows y Chrome. En scripts, Playwright mostró net::ERR_SSL_PROTOCOL_ERROR en nuestra prueba, y en Python un SSLError con WRONG_VERSION_NUMBER suele indicar un proxy HTTP escrito con https:// (Max Retries Exceeded With URL: qué es y cómo solucionarlo).

Errores comunes#

• Buscar una forma de saltarse la página. No existe ninguna conexión cifrada, así que no hay nada que aceptar para seguir. http:// envía tus datos sin cifrar; resérvalo para tu propio router o servidor de prueba.
• Dejar el antivirus desactivado. Pausa solo el análisis y solo para una prueba.
• Borrar la caché y las cookies una y otra vez. Ninguna de las dos interviene en la negociación TLS.
• Pulsar Clear SSL state (borrar estado SSL) en Windows. Ese botón antiguo de Windows viene de Internet Explorer y vacía la caché propia de Windows; Chrome y Edge guardan la suya dentro del navegador, y un reinicio completo la borra.
• Desactivar QUIC en chrome://flags. QUIC, el transporte que hay detrás de HTTP/3, tiene su propio código, ERR_QUIC_PROTOCOL_ERROR.
• Ajustar el reloj por este error. Una fecha incorrecta rompe la comprobación del certificado, y eso trae una advertencia de reloj o de certificado.

Guía de decisión#

Preguntas frecuentes#

¿Por qué me sale ERR_SSL_PROTOCOL_ERROR en todos los navegadores?#

La causa está fuera del navegador: software de seguridad, una app de VPN o de filtrado, o la red. Las extensiones no se comparten entre Chrome, Edge y Firefox, pero el análisis del antivirus y los filtros de red afectan a todos. Si un sitio falla en todas partes, el propio sitio está mal configurado.

¿Cómo soluciono ERR_SSL_PROTOCOL_ERROR en un teléfono Android?#

Cambia entre Wi-Fi y datos móviles, desactiva las apps de VPN y de bloqueo de anuncios (muchas funcionan como una VPN en el teléfono), actualiza Chrome desde Google Play y reinicia el teléfono. Si el sitio sigue fallando con datos móviles, el problema está del lado del sitio.

¿Puedo saltarme ERR_SSL_PROTOCOL_ERROR?#

No, y no hay nada que saltarse. La conexión cifrada nunca llegó a formarse, así que Chrome no ofrece ninguna forma de continuar. Escribir http:// enviaría tus datos sin cifrar, algo aceptable solo para tu propio router o servidor de prueba.

¿Por qué localhost muestra ERR_SSL_PROTOCOL_ERROR?#

Tu servidor de desarrollo habla HTTP sin cifrar y el navegador lo abrió con https://. Usa http://localhost con el número de puerto o activa HTTPS en la configuración del servidor.

¿ERR_SSL_PROTOCOL_ERROR significa que han hackeado mi equipo?#

Normalmente no; la mayoría de los casos se deben a software de seguridad, filtros, extensiones o un sitio mal configurado. Si un software que nunca instalaste intercepta el tráfico cifrado, haz un análisis de malware, y nunca instales un certificado que te pida un sitio web o una app.

¿Una VPN o un proxy pueden solucionar ERR_SSL_PROTOCOL_ERROR?#

No cuando el sitio está roto: una VPN o un proxy llevan la misma negociación al mismo servidor. Si lo causa un filtro de tu red, es una decisión de quien gestiona esa red, así que pregúntale.

En resumen#

ERR_SSL_PROTOCOL_ERROR significa que la negociación TLS se rompió antes incluso de comprobar el certificado, normalmente porque el navegador recibió algo distinto de un Server Hello válido. Averigua si falla un sitio o todos y después revisa las extensiones, el software de seguridad, las apps de VPN y de filtrado y la red; en localhost o en la página de un router, usa http://. Si el sitio es tuyo, asegúrate de que el puerto 443 hable TLS 1.2 o 1.3. Un túnel de proxy normal deja la negociación intacta; nuestra página de proxies explica los tipos de proxy y para qué sirve cada uno.