--- title: "Solucionar err_ssl_protocol_error en Chrome y Edge" description: "err_ssl_protocol_error y «Este sitio web no puede proporcionar una conexión segura»: falló la negociación TLS. ¿La culpa es de tu equipo, tu red o el sitio?" url: https://proxynet.io/es/blog/err-ssl-protocol-error date: 2026-10-05 author: "Acar Diveroli" category: "Tutoriales" lang: es --- # 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. > **Nota: Respuesta breve** > > `ERR_SSL_PROTOCOL_ERROR` significa que el navegador llegó al servidor del sitio, pero la negociación TLS (el handshake), el intercambio inicial que establece una conexión cifrada, falló porque la respuesta no era válida. Si un sitio falla en todos los dispositivos y redes, ese sitio está mal configurado, a menudo sirve HTTP sin cifrar en su puerto seguro, y solo su propietario puede arreglarlo. Si fallan muchos sitios en un equipo o en una red, prueba una ventana de incógnito, desactiva las extensiones, la VPN y las apps de filtrado, pausa el análisis HTTPS del antivirus durante una sola recarga y actualiza el navegador. En `localhost` o en la dirección de tu router, escribe `http://` en su lugar. La página no ofrece ninguna forma de continuar, y no deberías buscarla. ## ¿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](https://www.rfc-editor.org/rfc/rfc8446.html), establece que una negociación fallida termina la conexión. La [lista de errores de red](https://github.com/chromium/chromium/blob/main/net/base/net_error_list.h) 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](https://github.com/chromium/chromium/blob/main/net/ssl/openssl_ssl_util.cc) 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](/es/blog/your-connection-is-not-private). ## ¿Qué te dice la página «Este sitio web no puede proporcionar una conexión segura»? | Línea en la pantalla | Qué significa | |---|---| | «Este sitio web no puede proporcionar una conexión segura» | El título de Chrome para los fallos de la negociación TLS | | «example.com ha enviado una respuesta no válida.» | La respuesta al primer mensaje del navegador no era TLS válido. Chrome nombra el sitio, pero no puede saber si la envió el sitio o un dispositivo intermedio | | «Prueba a ejecutar Diagnósticos de red de Windows.» | Un enlace al solucionador de problemas del sistema; como el servidor sí respondió, rara vez encuentra algo | | `ERR_SSL_PROTOCOL_ERROR` y **Volver a cargar** | El código y un botón que simplemente lo vuelve a intentar | 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](/es/blog/this-site-cant-be-reached)). 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? | Causa | Quién lo ve | Quién puede arreglarlo | |---|---|---| | El sitio sirve HTTP sin cifrar en su puerto seguro | Todo el mundo, en cualquier dispositivo | El propietario del sitio | | Se escribió `https://` para un dispositivo o un servidor de prueba que solo habla HTTP | Solo esa dirección | Tú: usa `http://` para tu propio dispositivo | | Falla un antivirus que analiza el tráfico cifrado | Muchos sitios, un equipo | Tú: actualízalo o cambia su configuración | | Una VPN, un bloqueador de anuncios o una app de «protección» que filtra el tráfico | Muchos sitios, un dispositivo | Tú: desactívala para probar | | Un filtro de red responde con su propia página sin cifrar | Sitios bloqueados, toda la red | El administrador de la red | | Una extensión del navegador que gestiona el tráfico | Un navegador | Tú: desactívala | 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](https://support.google.com/chrome/answer/2664769?hl=es)). 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](https://support.microsoft.com/es-es/microsoft-edge/add-turn-off-or-remove-extensions-in-microsoft-edge-9c0ec68c-2fbc-2f2c-9ff0-bdc76f46b026)). 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](/es/blog/remove-proxy-chrome-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](https://support.google.com/chrome/answer/95414?hl=es)). 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)?](/es/blog/what-is-deep-packet-inspection). ## ¿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](https://www.ssllabs.com/ssltest/) 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`](https://nginx.org/en/docs/http/configuring_https_servers.html); `listen 443;` sin más sirve HTTP sin cifrar en el puerto seguro. En Apache, [`SSLEngine`](https://httpd.apache.org/docs/2.4/mod/mod_ssl.html) de mod_ssl está desactivado por defecto, así que un bloque `` necesita `SSLEngine on`. 3. **Ofrece TLS 1.2 y 1.3.** [RFC 8996](https://www.rfc-editor.org/rfc/rfc8996.html) 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](https://proxynet.io/es/residential-proxy). 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ó: ```nginx 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: ```bash 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](/es/blog/err-tunnel-connection-failed)), 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](/es/blog/proxy-server-not-responding)). 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](/es/blog/mitm-proxy)). El gateway de Proxynet retransmite los túneles sin descifrarlos, así que no instalas ningún certificado nuestro; para usar los [Proxies HTTPS](https://proxynet.io/es/https-proxy) en un navegador, consulta [Configuración de proxy en Windows y Chrome](/es/blog/windows-chrome-proxy-settings). 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](/es/blog/max-retries-exceeded-with-url)). ## 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 | Tu situación | Qué hacer | |---|---| | Un sitio falla en todos los dispositivos y redes | El sitio está roto; espera o avisa a su propietario | | Todos los sitios seguros fallan en un equipo | Extensiones, después software de seguridad, después apps de VPN o de filtrado | | Solo lo muestra una red Wi-Fi | Un filtro de red; pregunta a quien gestiona la red | | La página carga en una ventana de incógnito | Desactiva las extensiones de una en una | | La dirección es `localhost` o `192.168.x.x` | Usa `http://` para tu propio dispositivo | | El sitio es tuyo | Revisa `listen 443 ssl` o `SSLEngine on`, y TLS 1.2 y 1.3 | ## 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](/es/proxy) explica los tipos de proxy y para qué sirve cada uno.