ERR_CONNECTION_RESET: qué es, causas y cómo solucionarlo

ERR_CONNECTION_RESET es un error del navegador que indica que la conexión TCP con el servidor se interrumpió de forma inesperada antes de que la comunicación pudiera completarse. A diferencia de ERR_CONNECTION_REFUSED (el servidor rechaza activamente la conexión) o ERR_CONNECTION_TIMED_OUT (el servidor no responde en el tiempo límite), ERR_CONNECTION_RESET significa que la conexión se estableció correctamente pero algo la cortó a mitad. La causa puede estar en el equipo del cliente (firewall, antivirus, VPN), en la red intermedia, o en la configuración del servidor web o de la aplicación.

Qué significa exactamente ERR_CONNECTION_RESET

Para entender este error hay que entender cómo funciona una conexión TCP. Cuando tu navegador se conecta a un servidor web, establece primero una conexión TCP mediante el proceso conocido como three-way handshake (apretón de manos de tres pasos):

1. El cliente envía un paquete SYN (synchronize) al servidor para iniciar la conexión.
2. El servidor responde con un paquete SYN-ACK (synchronize-acknowledge) confirmando que acepta la conexión.
3. El cliente envía un ACK (acknowledge) y la conexión queda establecida.

Una vez establecida la conexión, cliente y servidor intercambian datos. ERR_CONNECTION_RESET ocurre cuando, en cualquier punto de este proceso o durante el intercambio de datos posterior, uno de los extremos envía un paquete RST (reset) en lugar de continuar la comunicación normal. El paquete RST es una señal de "abort": termina la conexión de forma abrupta, sin el proceso de cierre ordenado (FIN-FIN-ACK) que normalmente concluye una conexión TCP limpia.

El navegador recibe ese paquete RST y, al no poder continuar la comunicación, muestra ERR_CONNECTION_RESET al usuario.

ERR_CONNECTION_RESET vs errores de conexión similares

La distinción clave entre RESET y REFUSED: en REFUSED el servidor nunca aceptó la conexión (el puerto está cerrado); en RESET la conexión se aceptó pero alguien la abortó activamente. En TIMED_OUT nadie respondió; en RESET alguien respondió con un abort.

¿El problema está en el cliente o en el servidor?

Antes de empezar a buscar la causa, es fundamental determinar en qué lado de la conexión está el problema. La forma más rápida de saberlo es hacer estas tres comprobaciones rápidas:

Causas más comunes de ERR_CONNECTION_RESET

1. Firewall o software antivirus del cliente

Es la causa más frecuente cuando el error aparece de repente en sitios que antes funcionaban perfectamente. El firewall de Windows Defender, los antivirus con inspección de tráfico HTTPS (Kaspersky, ESET, Avast, Bitdefender, Norton) y las soluciones de seguridad corporativas inspeccionan el tráfico web interceptando la conexión SSL. Si el antivirus detecta algo que considera sospechoso en la comunicación — aunque sea un falso positivo — puede enviar un paquete RST para cortar la conexión.

Esto es especialmente frecuente después de actualizar el antivirus o el sistema operativo, porque las nuevas reglas de inspección pueden bloquear conexiones que antes pasaban sin problema. También ocurre en redes corporativas donde el firewall de empresa actualiza sus listas de bloqueo.

Cómo confirmarlo: desactiva temporalmente el antivirus o el firewall y prueba a cargar el sitio. Si funciona, el problema está en el software de seguridad. Solución permanente: añade una excepción para ese dominio o sitio en la configuración del antivirus.

Importante: desactiva el antivirus solo temporalmente para diagnosticar. No lo dejes desactivado de forma permanente como solución al problema.

2. VPN con configuración incorrecta o inestable

Una VPN activa puede causar ERR_CONNECTION_RESET por varias razones:

• Split tunneling mal configurado: si la VPN tiene reglas que enrutan parte del tráfico por el túnel y parte directamente, pueden surgir inconsistencias que provocan resets.
• MTU incorrecto: la VPN reduce el MTU (Maximum Transmission Unit) disponible porque añade sus propias cabeceras de encapsulación. Si el MTU de la VPN no está configurado correctamente, los paquetes grandes se fragmentan o se descartan, causando resets.
• Servidor VPN con problemas: si el servidor VPN está sobrecargado o tiene problemas de conectividad, las conexiones pueden restablecerse de forma intermitente.
• Cambio de servidor VPN: si la VPN cambia automáticamente de servidor mientras tienes conexiones activas, las conexiones TCP existentes se rompen.

Diagnóstico: desconecta la VPN y prueba la conexión directamente. Si funciona sin VPN, el problema está en la configuración de la VPN.

3. Problemas de red local o con el router

El router doméstico o de oficina puede causar ERR_CONNECTION_RESET cuando:

• La tabla de seguimiento de conexiones NAT del router está llena (ocurre en routers de gama baja con muchas conexiones simultáneas activas).
• El firmware del router tiene bugs que provocan resets espontáneos de conexiones TCP bajo ciertas condiciones.
• Hay interferencias o inestabilidad en la conexión WiFi que provocan pérdida de paquetes y resets.
• El proveedor de internet (ISP) está experimentando problemas en su red.

Diagnóstico: reinicia el router (desenchúfalo 30 segundos, vuelve a enchufarlo) y prueba con una conexión por cable en lugar de WiFi. Si el error desaparece, el problema estaba en el router o en la red WiFi.

4. Configuración incorrecta del servidor web

En el lado del servidor, ERR_CONNECTION_RESET puede generarse cuando el servidor web cierra la conexión antes de enviar la respuesta completa. Las causas más frecuentes en el servidor son:

• Timeout de PHP demasiado corto: si max_execution_time en PHP está configurado a un valor bajo (como 30 segundos) y la aplicación tarda más en responder, PHP interrumpe la ejecución y el servidor cierra la conexión abruptamente, lo que el navegador recibe como un reset.
• Timeout del proxy inverso demasiado corto: si Nginx tiene configurado un proxy_read_timeout bajo y el servidor de aplicación (PHP-FPM, Node.js) tarda más en responder, Nginx cierra la conexión con el cliente.
• Keepalive timeout demasiado agresivo: si el servidor cierra las conexiones persistentes (keep-alive) demasiado rápido, el navegador puede intentar reutilizar una conexión que ya fue cerrada por el servidor, recibiendo un reset.
• Límite de conexiones simultáneas superado: si el servidor está en el límite de conexiones que puede gestionar simultáneamente, puede rechazar nuevas conexiones con un RST.

5. Certificado SSL mal configurado o incompatible

Si el certificado SSL del servidor tiene problemas (caducado, para el dominio incorrecto, con una cadena de certificados incompleta, o usando una versión de TLS no soportada por el navegador), el handshake TLS puede fallar con un reset en lugar de un error SSL específico, dependiendo de en qué punto exacto falla la negociación.

Esto es especialmente frecuente cuando:

• El certificado SSL caducó recientemente y no fue renovado automáticamente.
• Se instaló un certificado SSL nuevo con una cadena de certificados incompleta (falta el certificado intermedio).
• El servidor solo soporta TLS 1.0 o 1.1, que Chrome y Firefox ya no aceptan por considerarlos inseguros.

Diagnóstico: comprueba el estado del certificado SSL con la herramienta gratuita SSL Labs (ssllabs.com/ssltest/) introduciendo tu dominio. Te dará un informe detallado de cualquier problema con el certificado o la configuración TLS.

6. Interferencia de extensiones del navegador

Ciertas extensiones del navegador (especialmente las que inspeccionan o modifican el tráfico web, como bloqueadores de anuncios avanzados, extensiones de VPN dentro del navegador, o herramientas de privacidad) pueden cortar conexiones que consideran problemáticas, generando un reset que el navegador muestra como ERR_CONNECTION_RESET.

Diagnóstico: abre Chrome sin extensiones usando el modo incógnito (que desactiva todas las extensiones por defecto) o abre una sesión de Chrome con el flag --disable-extensions.

Cómo solucionar ERR_CONNECTION_RESET: proceso completo

Si el error aparece en todos los sitios web

El problema está en tu equipo o red local. Sigue estos pasos en orden:

Paso 1: Reinicia el router y el equipo

El reinicio limpia el estado de las conexiones TCP activas tanto en el router (tabla NAT) como en el sistema operativo (socket buffers). Desenchufa el router 30 segundos, vuelve a enchufarlo, espera a que reinicie completamente y reinicia también el ordenador.

Paso 2: Desactiva temporalmente el antivirus y el firewall

Desactiva el antivirus y el firewall de Windows Defender temporalmente y prueba a cargar el sitio. Si funciona, añade una excepción en el software de seguridad para ese dominio. Si sigues usando el antivirus corporativo, contacta con el equipo de IT para revisar las reglas de inspección de tráfico HTTPS.

Paso 3: Desconecta la VPN

Si tienes una VPN activa, desconéctala y prueba directamente. Si funciona sin VPN, el problema está en la configuración de la VPN: revisa la configuración del MTU o contacta con el soporte de tu proveedor de VPN.

Paso 4: Prueba con cable en lugar de WiFi

Conecta el ordenador directamente al router con un cable Ethernet y comprueba si el error persiste. Si desaparece, el problema era la inestabilidad de la conexión WiFi.

Paso 5: Limpia la caché de sockets de Chrome

Chrome mantiene una caché de conexiones de red que puede volverse inconsistente. Para limpiarla:

# En la barra de direcciones de Chrome, escribe:
chrome://net-internals/#sockets

# Haz clic en "Flush socket pools" (Vaciar grupos de sockets)
# Luego ve a:
chrome://net-internals/#dns
# Y haz clic en "Clear host cache" (Limpiar caché de host)

Paso 6: Reinicia la pila TCP/IP del sistema operativo

# En Windows (como administrador):
netsh winsock reset
netsh int ip reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew
# Reinicia el ordenador después de ejecutar estos comandos

# En macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# En Linux (Ubuntu/Debian):
sudo systemd-resolve --flush-caches
sudo resolvectl flush-caches

Paso 7: Cambia el servidor DNS

Aunque ERR_CONNECTION_RESET no suele estar causado por el DNS (el DNS ya resolvió el dominio si la conexión llegó a establecerse), en algunos casos un DNS lento o con problemas puede contribuir al problema. Prueba con los DNS de Cloudflare (1.1.1.1) o Google (8.8.8.8):

# En Windows: Panel de control > Conexiones de red > 
# Propiedades del adaptador > TCP/IPv4 > DNS preferido: 1.1.1.1

# En Linux con NetworkManager:
nmcli connection modify "Nombre de tu conexión" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli connection up "Nombre de tu conexión"

Si el error aparece solo en un sitio específico

El problema está en el servidor de ese sitio o en su configuración. Si eres el administrador del servidor:

Paso 1: Revisa los logs del servidor

# Apache — buscar resets y errores de conexión:
sudo tail -100 /var/log/apache2/error.log | grep -i "reset\|connection\|abort"

# Nginx — buscar timeouts y resets:
sudo tail -100 /var/log/nginx/error.log | grep -i "reset\|timeout\|upstream"

# Ver conexiones activas y su estado:
ss -tn | grep :443
netstat -tn | grep :443

Paso 2: Aumenta los timeouts del servidor

# En la configuración de Nginx (/etc/nginx/nginx.conf o el bloque server):
keepalive_timeout      65s;
proxy_connect_timeout  60s;
proxy_read_timeout     300s;
proxy_send_timeout     300s;
fastcgi_read_timeout   300s;

# Aplica los cambios:
sudo nginx -t && sudo systemctl reload nginx

# En Apache (/etc/apache2/apache2.conf o el VirtualHost):
KeepAlive On
KeepAliveTimeout 65
Timeout 300
ProxyTimeout 300

Paso 3: Verifica el certificado SSL

# Comprueba la fecha de caducidad del certificado desde la línea de comandos:
echo | openssl s_client -connect tudominio.com:443 2>/dev/null | openssl x509 -noout -dates

# Ver qué versiones de TLS soporta el servidor:
nmap --script ssl-enum-ciphers -p 443 tudominio.com

# Verificar la cadena de certificados completa:
echo | openssl s_client -connect tudominio.com:443 -showcerts 2>/dev/null | grep "subject\|issuer"

Paso 4: Aumenta el timeout de PHP para respuestas lentas

# En php.ini:
max_execution_time = 300
max_input_time = 300

# En .htaccess (Apache con mod_php):
php_value max_execution_time 300

# Verificar el valor actual desde PHP:
php -r "echo ini_get('max_execution_time');"

Paso 5: Revisa el uso de recursos del servidor

# Ver carga del servidor en tiempo real:
top
htop

# Ver conexiones TCP activas y su estado:
ss -s
netstat -s | grep -i "reset\|reset"

# Ver si hay conexiones en estado TIME_WAIT acumuladas (puede agotar los puertos):
ss -tn | grep TIME-WAIT | wc -l

ERR_CONNECTION_RESET en Chrome: causas específicas del navegador

Si el error aparece solo en Chrome y no en Firefox o Edge, las causas más probables son internas a Chrome:

Chrome tiene una herramienta de diagnóstico de red integrada muy útil para este tipo de errores:

# Accede al log de red de Chrome en tiempo real:
chrome://net-internals/#events

# Filtra por "TCP_CONNECT" o "SSL_CONNECT" para ver los intentos de conexión
# y en qué punto exacto falla

ERR_CONNECTION_RESET en entornos específicos

En redes corporativas o educativas

Los firewalls corporativos son una de las causas más frecuentes de ERR_CONNECTION_RESET en entornos de empresa o universidad. Estos firewalls realizan inspección profunda de paquetes (DPI) y pueden bloquear conexiones por múltiples razones: el dominio está en una lista negra, la categoría del contenido está bloqueada por política, o el certificado SSL del sitio no cumple los requisitos del firewall corporativo.

En estos entornos, la solución no está en tu mano: debes contactar con el departamento de IT para que revisen las reglas del firewall y añadan una excepción para ese dominio si es necesario para tu trabajo.

En servidores con Fail2Ban

Fail2Ban es una herramienta de seguridad para servidores Linux que bloquea automáticamente IPs que generan demasiados errores de autenticación o intentos de acceso no autorizados. Si tu IP fue bloqueada por Fail2Ban, el servidor enviará un RST a todas tus solicitudes, generando ERR_CONNECTION_RESET.

# Ver si una IP está bloqueada por Fail2Ban:
sudo fail2ban-client status sshd
sudo fail2ban-client status nginx-http-auth

# Desbloquear una IP específica:
sudo fail2ban-client set sshd unbanip 195.234.56.78

# Ver el log de Fail2Ban para confirmar:
sudo tail -50 /var/log/fail2ban.log | grep "Ban\|Unban"

Impacto de ERR_CONNECTION_RESET en el SEO

Desde el punto de vista del SEO, ERR_CONNECTION_RESET tiene un comportamiento similar al de los errores 5xx: si Googlebot encuentra este error al intentar rastrear tu sitio, no puede indexar el contenido. Sin embargo, hay diferencias importantes:

• Si el error lo genera un firewall que bloquea la IP de Googlebot, el impacto en el SEO es especialmente grave porque es un bloqueo activo del rastreador.
• Si el error es intermitente (Googlebot a veces puede acceder y a veces no), el impacto es menor porque Google puede indexar el contenido en las visitas exitosas.
• Google Search Console muestra los errores de conexión en la sección Cobertura, pero a veces los clasifica como "Error del servidor" (5xx) en lugar de mostrar el código de error específico del navegador.

Si sospechas que tu servidor puede estar bloqueando la IP de Googlebot con un firewall, verifica que las IPs de Google están en la lista blanca del firewall. Google publica la lista completa de IPs de Googlebot en su documentación oficial.

Preguntas frecuentes sobre ERR_CONNECTION_RESET

¿ERR_CONNECTION_RESET significa que el servidor está caído?

No necesariamente. El servidor puede estar funcionando perfectamente y recibir solicitudes de otros usuarios sin problema. ERR_CONNECTION_RESET significa que la conexión TCP entre tu equipo y el servidor fue interrumpida por un paquete RST, pero ese paquete puede venir de cualquier punto de la ruta: tu equipo, tu router, el firewall de tu empresa, el proveedor de internet, o el propio servidor. Si el sitio funciona desde otro equipo o red, el servidor está operativo y el problema está en tu lado de la conexión.

¿Por qué ERR_CONNECTION_RESET aparece solo en algunas páginas del mismo sitio?

Si el error aparece solo en páginas específicas de un sitio (no en todas), la causa más probable es que esas páginas generan una respuesta más lenta o más pesada que hace que el servidor o el proxy agote el timeout antes de completar la respuesta. También puede ocurrir si esas páginas específicas activan alguna regla de inspección del firewall que las demás no activan. Revisa los logs del servidor filtrado por las URLs problemáticas para ver si aparecen mensajes de timeout o abort.

¿Cómo diferencio si ERR_CONNECTION_RESET viene de mi antivirus o del servidor?

La forma más directa es desactivar temporalmente el antivirus y probar. Si el error desaparece al desactivar el antivirus, ese es el culpable. Para confirmarlo sin necesidad de desactivar el antivirus, revisa los logs del antivirus buscando entradas relacionadas con el dominio o la IP del sitio que falla. Muchos antivirus con inspección HTTPS registran todos los sitios que inspeccionan o bloquean.

¿ERR_CONNECTION_RESET puede ser causado por el proveedor de internet?

Sí. Algunos ISP aplican filtros de contenido o listas de bloqueo que se implementan enviando paquetes RST para cortar las conexiones a sitios bloqueados. También ocurre cuando el ISP experimenta problemas en su red que provocan pérdida de paquetes y resets TCP. Puedes comprobarlo usando una VPN o Tor: si con VPN el sitio carga correctamente, el ISP está bloqueando o interfiriendo con esa conexión.

¿Cómo sé si mi IP fue bloqueada por el servidor?

La forma más directa es intentar acceder al mismo sitio desde otra red (por ejemplo, desde el móvil con datos en lugar de WiFi) o desde un proxy online. Si desde otra red funciona y desde la tuya da ERR_CONNECTION_RESET, tu IP probablemente está bloqueada por el firewall del servidor o por herramientas como Fail2Ban. Contacta con el administrador del servidor para que verifique y elimine el bloqueo de tu IP.

¿ERR_CONNECTION_RESET y "connection reset by peer" son el mismo error?

Sí, son el mismo error visto desde distintos ángulos. "Connection reset by peer" es el mensaje que muestra el sistema operativo o las herramientas de línea de comandos (como curl o wget) cuando recibe un paquete RST del otro extremo de la conexión. ERR_CONNECTION_RESET es cómo Chrome llama al mismo evento. En los logs del servidor también puedes ver este error como "Broken pipe" o "Connection reset by peer" cuando el cliente corta la conexión antes de que el servidor termine de enviar la respuesta.

¿Puede ERR_CONNECTION_RESET ocurrir durante el handshake SSL?

Sí. Si el handshake TLS falla de forma abrupta (por ejemplo, porque el servidor cierra la conexión al detectar que el cliente usa una versión de TLS no soportada, o porque el cliente rechaza el certificado del servidor), el error puede mostrarse como ERR_CONNECTION_RESET en lugar del más específico ERR_SSL_PROTOCOL_ERROR. Para diagnosticar si la causa está en el SSL, usa openssl s_client o la herramienta SSL Labs para verificar la configuración TLS del servidor.