ERR_CONNECTION_CLOSED: qué significa y cómo solucionarlo

¿Qué es ERR_CONNECTION_CLOSED?

ERR_CONNECTION_CLOSED es el error de Chrome y Edge que muestra "No se puede acceder a este sitio" y explica que example.com cerró la conexión de forma inesperada (en la versión en inglés: "example.com unexpectedly closed the connection"). En Chromium es el error de red -100, definido como "a connection was closed (corresponding to a TCP FIN)" (se cerró una conexión, lo que equivale a un TCP FIN).

Un FIN es la forma educada de terminar una conexión TCP. Es lo contrario de un reset: nada se cayó ni se mató; un lado simplemente dijo "he terminado" y colgó. El problema es el momento. El otro lado colgó antes de que el navegador recibiera la página, así que no había nada que mostrar.

Algo decidió terminar tu conexión antes de tiempo. Puede ser el servidor del sitio web, una CDN delante de él, un filtro en tu red o un software de tu propio equipo. Las soluciones de abajo te muestran cuál.

Dónde se produce el cierre: normalmente en el handshake HTTPS

El código de red de Chromium nos dice dónde mirar. Cuando una conexión termina durante el handshake TLS (HTTPS), la capa de cifrado convierte ese fin de conexión en ERR_CONNECTION_CLOSED. Cuando una conexión nueva consigue enviar su petición y el servidor cierra sin responder, Chrome muestra ERR_EMPTY_RESPONSE en su lugar.

Chrome también reintenta automáticamente una petición cuando una conexión antigua reutilizada se cierra por debajo, así que rara vez verás el error por ese motivo. Como resultado, una página de ERR_CONNECTION_CLOSED en un sitio HTTPS suele significar que algo colgó mientras se establecía la conexión segura. Eso apunta a lo que gestiona TLS a lo largo del camino: el analizador HTTPS de tu antivirus, una VPN o un proxy, un equipo de filtrado en tu red, la CDN del sitio o la configuración TLS del servidor web.

¿Qué causa ERR_CONNECTION_CLOSED?

Solución 1: prueba otra red para encontrar al culpable

Abre la página en tu teléfono con datos móviles (con el Wi-Fi desactivado), o en otro equipo conectado a una red distinta.

• Funciona en otra red: el cierre viene de tu dispositivo o de tu red. Continúa con las soluciones 2 a 6.

• Falla en todas partes: el servidor o la CDN del sitio web está colgando. Solo el propietario puede arreglarlo. Si el sitio es tuyo, salta a la sección para propietarios de sitios web más abajo.

• Comprueba el certificado desde fuera: el SSL Checker de DNS Robot se conecta al sitio desde nuestros servidores y muestra si el handshake HTTPS funciona y qué certificado se sirve.

Solución 2: desactiva la VPN y el proxy

Los servidores VPN y los proxies gestionan cada conexión que haces, y cuando están saturados o bloqueados suelen terminar las conexiones durante el handshake. Desconecta la VPN por completo y luego comprueba si hay un proxy configurado:

• Windows 11: Configuración → Red e Internet → Proxy → en Configuración manual del proxy, desactiva Usar un servidor proxy.

• macOS: Ajustes del Sistema → Red → tu conexión → Detalles… → Proxies → desactívalos.

• Las extensiones del navegador que actúan como VPN o proxy también cuentan. Prueba en una ventana de incógnito, donde las extensiones están desactivadas por defecto.

Solución 3: pausa el análisis HTTPS del antivirus

Las suites de seguridad que inspeccionan el tráfico cifrado se sitúan en medio de cada handshake HTTPS. Si el analizador no consigue negociar con un sitio, por ejemplo por una función de TLS más reciente o un certificado poco habitual, a menudo simplemente cierra la conexión.

Busca un ajuste llamado análisis HTTPS, escudo web (Web Shield), filtrado de protocolos SSL/TLS o analizar conexiones cifradas, desactiva solo ese y recarga. Si la página carga, añade el sitio como exclusión y vuelve a activar el análisis. Actualizar el antivirus suele solucionarlo de forma definitiva.

Solución 4: cambia el DNS para descartar un filtrado

Algunos proveedores de internet y filtros de red bloquean sitios haciendo que el dominio apunte a su propio servidor, que luego cuelga las conexiones HTTPS que no puede atender. Si el DNS Lookup de DNS Robot devuelve para el sitio direcciones IP distintas de las que obtiene tu equipo (nslookup example.com), tu resolver te está redirigiendo.

Cambia a un resolver público como Cloudflare (1.1.1.1), Google (8.8.8.8) o Quad9 (9.9.9.9), luego vacía tu caché DNS y vuelve a intentarlo. Si tu red también bloquea el DNS cifrado, consulta esta red bloquea el tráfico DNS cifrado.

Solución 5: borra el estado SSL, los grupos de sockets y los datos del navegador

• Grupos de sockets de Chrome: abre chrome://net-internals/#sockets y haz clic en Flush socket pools, para que Chrome deje de reutilizar conexiones que pueden estar obsoletas.

• Estado SSL de Windows: pulsa Win + R, escribe inetcpl.cpl, abre la pestaña Contenido y haz clic en Borrar estado SSL.

• Datos del sitio: haz clic en el icono a la izquierda de la barra de direcciones → Configuración de sitios → Eliminar datos, para que las cookies y los datos en caché de ese sitio empiecen de cero.

• Actualiza el navegador: ve a chrome://settings/help. Las versiones antiguas pueden fallar en el handshake con servidores que usan funciones de TLS más recientes.

Solución 6: restablece la pila de red y reinicia el router

Si varios sitios fallan solo en un dispositivo, restablece su configuración de red. Reinicia también el router, lo que vacía su tabla de conexiones. En Windows, ejecuta estos comandos en un Símbolo del sistema como administrador y luego reinicia:

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

Windows 11 también tiene Configuración → Red e Internet → Configuración de red avanzada → Restablecimiento de red, que reinstala los adaptadores de red. En un Mac, elimina la red Wi-Fi en Ajustes del Sistema → Wi-Fi y vuelve a conectarte a ella.

Cómo solucionar ERR_CONNECTION_CLOSED en Android y iPhone

• Cambia de red: del Wi-Fi a los datos móviles o al revés, para saber si interviene un filtro de red.

• Desactiva las apps de VPN, de bloqueo de anuncios y de "seguridad". Muchas de ellas pasan el tráfico por una VPN local y lo inspeccionan.

• DNS privado en Android: Ajustes → Redes e Internet → DNS privado → Automático. Consulta la guía sobre el DNS privado para saber qué hace cada opción.

• Actualiza Chrome o Safari desde la tienda de apps, y actualiza el sistema operativo si va varias versiones por detrás.

• Restablece la configuración de red: en iPhone, Ajustes → General → Transferir o restablecer el iPhone → Restablecer → Restablecer ajustes de red. En Android, Ajustes → Sistema → Opciones de restablecimiento (Reset options) → Restablecer Bluetooth y Wi-Fi (y Restablecer configuración de red móvil si los datos móviles también fallan).

Para propietarios de sitios web: por qué tu servidor cuelga

Si los visitantes de muchas redes reciben ERR_CONNECTION_CLOSED, prueba tú mismo el handshake TLS desde una máquina fuera de tu red. openssl s_client muestra exactamente dónde se detiene:

• SNI y certificados: cada nombre de host que usan los visitantes, tanto example.com como www.example.com, necesita una entrada server_name y un certificado que lo cubra. A los nombres de host que acaban en un bloque de servidor predeterminado sin certificado se les suele cerrar el handshake.

• Protocolos: sirve TLSv1.2 y TLSv1.3. Las configuraciones muy antiguas que solo ofrecen TLS 1.0/1.1, o listas de cifrados poco habituales, fallan con los navegadores actuales. El SSL Checker muestra el certificado y la cadena que reciben los visitantes.

• Límites de conexiones: si nginx registra worker_connections are not enough, o salta una regla connlimit del firewall o una regla anti-DDoS, las conexiones nuevas se descartan o se cierran cuando hay mucha carga. Sube los límites o localiza el origen del tráfico.

• CDN y WAF: revisa los eventos de seguridad de la CDN para los visitantes afectados. Las reglas de protección contra bots y de bloqueo geográfico pueden cerrar las conexiones de regiones enteras.

• Registros: busca en el registro de errores del servidor web líneas SSL_do_handshake() failed en torno a la hora de los avisos. nginx registra la mayoría de los fallos de handshake del lado del cliente en el nivel info, así que con el nivel error predeterminado puede que no veas nada: configura error_log /var/log/nginx/error.log info; temporalmente mientras investigas.

# Handshake completo con SNI (el nombre de host que usan los visitantes)
openssl s_client -connect example.com:443 -servername example.com </dev/null

# Bien: cadena de certificados, "Verify return code: 0 (ok)", una línea de protocolo TLSv1.3 o TLSv1.2
# Mal: "unexpected eof while reading" o "no peer certificate available"
#      = el servidor (o algo delante de él) cerró el handshake

# Prueba una versión concreta del protocolo
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

Después revisa esto, en orden:

ERR_CONNECTION_CLOSED frente a RESET, EMPTY_RESPONSE y errores SSL

Guías relacionadas: ERR_CONNECTION_RESET, ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH y ERR_CONNECTION_REFUSED.