Cómo solucionar el error ERR_CONNECTION_TIMED_OUT: Una guía técnica completa

El error ERR_CONNECTION_TIMED_OUT significa que tu navegador envió una solicitud de conexión a un servidor remoto pero no recibió respuesta dentro del tiempo asignado — típicamente 30 segundos en navegadores basados en Chromium. El protocolo de enlace TCP nunca se completa, por lo que el navegador abandona el intento y muestra este error en lugar de la página cargada.

Este no es un fallo de causa única. Puede originarse en el lado del cliente (tu máquina, tu red, tu navegador), en la infraestructura intermedia (resolvedores DNS, proxies, cortafuegos), o en el lado del servidor (origen sobrecargado, servidor web mal configurado, SSL vencido o fallo de enrutamiento upstream). Diagnosticarlo correctamente requiere trabajar en cada capa de forma sistemática.

Qué Ocurre Realmente Durante un Tiempo de Espera de Conexión

Cuando escribes una URL y presionas Enter, tu navegador ejecuta una secuencia precisa: resolución DNS, conexión TCP (SYN / SYN-ACK / ACK), protocolo de enlace TLS opcional y luego el ciclo de solicitud/respuesta HTTP. Un error de tiempo de espera significa que el proceso se detuvo en algún punto de esa cadena — más comúnmente en la etapa de conexión TCP, antes de que se intercambie cualquier dato HTTP.

Entender qué etapa falló te indica dónde enfocar tu solución. Un fallo DNS produce un código de error diferente (`ERR_NAME_NOT_RESOLVED`). Un fallo TLS produce `ERR_SSL_PROTOCOL_ERROR`. Cuando ves `ERR_CONNECTION_TIMED_OUT` específicamente, la búsqueda DNS tuvo éxito, pero el socket TCP nunca recibió un SYN-ACK de la IP de destino. Eso reduce considerablemente el campo.

Causas Raíz: Por Qué Ocurre Este Error

Método 1: Verifica Tu Conexión a Internet en la Capa de Red

No te limites a "comprobar si internet funciona." Ejecuta una prueba estructurada:

• Haz ping a la puerta de enlace: Abre el Símbolo del sistema y ejecuta `ping 192.168.1.1` (o la IP de tu router). Si esto falla, el problema está entre tu máquina y el router.
• Haz ping a una IP pública directamente: Ejecuta `ping 8.8.8.8`. Si esto tiene éxito pero los sitios web fallan, el problema es DNS, no la conectividad.
• Ejecuta un traceroute: `tracert google.com` en Windows o `traceroute google.com` en Linux/macOS. Busca dónde los saltos dejan de responder — eso identifica el segmento de red que falla.
• Reinicia tu router: Apágalo durante 30 segundos. Esto fuerza una nueva concesión DHCP y restablece la sesión PPPoE/PPPoA con tu ISP.
• Prueba con un punto de acceso móvil: Si el sitio carga por LTE pero no por tu banda ancha doméstica, el fallo está antes de tu router — probablemente tu ISP o una ruta de enrutamiento específica que utilizan.

Método 2: Vacía y Reconstruye la Caché DNS

Una caché DNS envenenada u obsoleta puede almacenar una dirección IP antigua e inaccesible para un dominio, haciendo que cada intento de conexión agote el tiempo de espera contra un servidor que ya no existe en esa dirección.

En Windows:

“`

ipconfig /flushdns

ipconfig /registerdns

“`

En macOS (Ventura / Sonoma):

“`

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

“`

En Linux (systemd-resolved):

“`

sudo systemd-resolve –flush-caches

“`

Después de vaciar, verifica que la caché esté limpia en Windows con `ipconfig /displaydns` — la salida debería ser mínima. Luego intenta la conexión nuevamente antes de realizar cualquier otro cambio, para poder aislar si la caché DNS era la única causa.

Método 3: Cambia a un Resolvedor DNS Público Confiable

El resolvedor DNS predeterminado de tu ISP puede ser lento, poco confiable o estar sujeto a filtrado geográfico. Reemplazarlo con un resolvedor público rápido a menudo resuelve los errores de tiempo de espera causados por fallos de búsqueda DNS que devuelven registros incorrectos o ninguno de forma silenciosa.

En Windows (IPv4):

1. Abre Panel de control > Red e Internet > Centro de redes y recursos compartidos > Cambiar configuración del adaptador.
2. Haz clic derecho en tu adaptador activo y selecciona Propiedades.
3. Selecciona Protocolo de Internet versión 4 (TCP/IPv4) y haz clic en Propiedades.
4. Selecciona Usar las siguientes direcciones de servidor DNS e introduce tu resolvedor preferido.

Resolvedores DNS públicos recomendados:

Caso límite crítico: Si recientemente migraste tu sitio web a un nuevo servidor o cambiaste su registro A, la propagación DNS puede tardar hasta 48 horas. Durante este período, algunos usuarios serán dirigidos a la IP antigua. Ejecutar `nslookup yourdomain.com 8.8.8.8` frente a `nslookup yourdomain.com 1.1.1.1` te permite comparar lo que devuelven diferentes resolvedores — si las IPs difieren, estás en un período de propagación, no ante un verdadero error de tiempo de espera.

Método 4: Limpia la Caché del Navegador, Cookies y Extensiones

Chrome y otros navegadores basados en Chromium almacenan en caché las respuestas DNS de forma independiente a la caché DNS del sistema operativo. Esta caché DNS interna del navegador puede contener registros obsoletos incluso después de vaciar la caché del sistema.

Limpia la caché DNS interna de Chrome directamente:

1. Navega a `chrome://net-internals/#dns`
2. Haz clic en Clear host cache
3. Navega a `chrome://net-internals/#sockets`
4. Haz clic en Flush socket pools

Limpia los datos de navegación:

1. Abre Chrome y presiona `Ctrl + Shift + Delete`
2. Establece el intervalo de tiempo en Todo el tiempo
3. Marca Cookies y otros datos de sitios e Imágenes y archivos en caché
4. Haz clic en Borrar datos

Prueba primero en una ventana de incógnito. Si el sitio carga en incógnito pero no en una ventana normal, una extensión del navegador es la culpable. Deshabilita todas las extensiones a través de `chrome://extensions/` y vuelve a habilitarlas una a una para identificar al responsable. Los bloqueadores de anuncios, las extensiones VPN y las herramientas de seguridad son las fuentes de interferencia más comunes.

Método 5: Deshabilita la Configuración del Proxy

Una configuración de proxy incorrecta u obsoleta es una de las causas más frecuentemente ignoradas de este error, especialmente en equipos corporativos o después de desinstalar software VPN que dejó configuraciones de proxy.

A través de Chrome:

1. Ve a Configuración > Sistema > Abrir la configuración de proxy de tu equipo
2. En Configuración manual del proxy, asegúrate de que Usar un servidor proxy esté desactivado
3. En Configuración automática del proxy, asegúrate de que Usar script de configuración esté desactivado a menos que uses intencionalmente un archivo PAC

A través de la Configuración de Windows directamente:

1. Abre Configuración > Red e Internet > Proxy
2. Deshabilita todas las entradas de proxy manual
3. Habilita Detectar la configuración automáticamente solo si tu red lo requiere

A través del Símbolo del sistema (método más rápido):

“`

netsh winhttp reset proxy

“`

Esto restablece la configuración del proxy WinHTTP a conexión directa, omitiendo cualquier proxy a nivel de sistema que pueda haber sido establecido por algún software.

Método 6: Restablece la Pila TCP/IP y el Catálogo Winsock

La corrupción en el catálogo Winsock — la implementación de Windows de la API de sockets Berkeley — puede causar fallos de conexión intermitentes o persistentes que parecen idénticos a los tiempos de espera del lado del servidor. Esto es especialmente común después de la eliminación de malware, actualizaciones fallidas de controladores de red o actividad agresiva del antivirus.

Abre el Símbolo del sistema como Administrador y ejecuta estos comandos secuencialmente:

“`

netsh winsock reset

netsh int ip reset resetlog.txt

ipconfig /release

ipconfig /flushdns

ipconfig /renew

“`

Reinicia tu equipo después de ejecutar todos los comandos. El archivo `resetlog.txt` se creará en tu directorio de trabajo y registra cada clave de registro que fue restablecida — útil para auditar qué estaba corrupto.

En Linux, el equivalente para restablecer el estado de la red es:

“`

sudo systemctl restart NetworkManager

sudo ip route flush cache

“`

Método 7: Audita las Reglas del Cortafuegos y el Antivirus

Windows Defender Firewall y las suites de seguridad de terceros pueden bloquear silenciosamente las conexiones salientes a puertos específicos, rangos de IP o dominios. El bloqueo no produce un error inmediato de "conexión rechazada" — en cambio, los paquetes se descartan y el navegador espera hasta que se alcanza su umbral de tiempo de espera.

Prueba de diagnóstico temporal:

1. Ve a Panel de control > Sistema y seguridad > Windows Defender Firewall
2. Haz clic en Activar o desactivar Windows Defender Firewall
3. Desactívalo temporalmente para redes privadas y públicas
4. Intenta la conexión

Si el sitio carga con el cortafuegos desactivado, vuelve a activarlo inmediatamente y luego crea una regla de salida específica para permitir el tráfico al dominio o IP afectado en lugar de dejar el cortafuegos desactivado. Navega a Configuración avanzada > Reglas de salida > Nueva regla para configurarlo con precisión.

Para el software antivirus: La mayoría de las suites modernas incluyen una función de inspección HTTPS o "escudo web" que realiza una intercepción de tipo intermediario del tráfico TLS. Esto puede romper las conexiones si el certificado raíz del antivirus no es de confianza para el navegador, o si el antivirus marca incorrectamente el servidor de destino. Deshabilitar temporalmente el componente de escudo web (no todo el antivirus) es una prueba más quirúrgica que deshabilitar toda la protección.

Método 8: Restablece las Flags y el Predictor de Red de Chrome

Las flags experimentales y las funciones de predicción de red de Chrome pueden ocasionalmente causar problemas de conexión, especialmente después de actualizaciones del navegador que cambian el comportamiento de estas funciones.

Deshabilita la predicción de red:

1. Ve a Configuración > Privacidad y seguridad > Cookies y otros datos de sitios
2. Desplázate hasta Precargar páginas para una navegación y búsqueda más rápidas y desactívalo

Restablece todas las flags de Chrome a sus valores predeterminados:

1. Navega a `chrome://flags`
2. Haz clic en Reset all en la esquina superior derecha
3. Reinicia Chrome

Restablece toda la configuración de la pila de red de Chrome:

1. Ve a Configuración > Avanzado > Restablecer y limpiar > Restaurar la configuración a sus valores predeterminados originales

Esto no elimina marcadores ni contraseñas, pero restablece las páginas de inicio, la configuración de nueva pestaña, las pestañas ancladas, la configuración de contenido, las cookies y las extensiones — dándote efectivamente una línea base de configuración de red limpia.

Método 9: Aumenta el Tiempo de Espera de Conexión TCP (Avanzado)

De forma predeterminada, Windows espera aproximadamente 21 segundos antes de declarar fallido un intento de conexión TCP (basado en el valor de registro `TcpMaxConnectRetransmissions`, que por defecto es 2 retransmisiones con retroceso exponencial). En redes lentas o congestionadas, esto puede ser demasiado corto.

Ajusta mediante el Editor del Registro (Windows):

1. Abre `regedit`
2. Navega a `HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters`
3. Busca o crea un valor DWORD llamado `TcpMaxConnectRetransmissions`
4. Establécelo en `3` o `4` (hexadecimal) para permitir más intentos de retransmisión

Importante: Esto aumenta el tiempo que Windows esperará antes de abandonar una conexión TCP. No soluciona la causa subyacente — simplemente da más tiempo para que los servidores lentos o las rutas congestionadas respondan. Úsalo solo como herramienta de diagnóstico o para casos de uso específicos como conectarse a servidores geográficamente distantes.

Método 10: Verifica que el Servidor Sea Realmente Accesible

Antes de dedicar más tiempo a soluciones del lado del cliente, confirma si el problema está en el lado del servidor. Un sitio web puede ser completamente inaccesible debido a una cuenta de alojamiento suspendida, una regla de cortafuegos del lado del servidor o un servidor web mal configurado — ninguno de los cuales puedes solucionar desde tu navegador.

Herramientas para verificar la accesibilidad del servidor desde puntos externos:

• downforeveryoneorjustme.com — Comprobación simple de activo/inactivo desde una única ubicación
• downdetector.com — Agrega informes de usuarios para servicios principales
• tools.pingdom.com — Prueba el tiempo de respuesta desde múltiples ubicaciones globales
• mxtoolbox.com/SuperTool — Prueba DNS, cabeceras HTTP y conectividad
• check-host.net — Realiza pings y comprobaciones HTTP desde docenas de nodos geográficos simultáneamente

Ejecuta `curl -v https://yourdomain.com` desde un terminal para ver el punto exacto del fallo — si la conexión TCP es rechazada, agota el tiempo de espera o tiene éxito pero devuelve un código de error HTTP. Este único comando te dice más que cualquier herramienta con interfaz gráfica.

Causas del Lado del Servidor: Qué Verificar si Eres el Propietario del Sitio Web

Si eres el propietario del sitio web y tus visitantes reportan `ERR_CONNECTION_TIMED_OUT`, el problema casi con certeza está en tu infraestructura. Las causas más comunes del lado del servidor son:

Agotamiento de la cola de conexiones del servidor web:

En Apache, la directiva `MaxClients` (o `MaxRequestWorkers` en Apache 2.4+) limita las conexiones simultáneas. Cuando se alcanza este límite, las nuevas conexiones se ponen en cola y eventualmente agotan el tiempo de espera. Verifica tu configuración actual:

“`

apache2ctl -V | grep -i mpm

grep -i maxrequestworkers /etc/apache2/apache2.conf

“`

En Nginx, el equivalente es `worker_connections` en el bloque `events` y `worker_processes`. Una configuración incorrecta común es establecer `worker_processes` en `1` en un servidor multinúcleo, creando un cuello de botella.

Cortafuegos bloqueando el tráfico entrante en el puerto 80/443:

Si gestionas un entorno de VPS Hosting, verifica tus reglas de iptables o nftables:

“`

iptables -L INPUT -n -v | grep -E "80|443"

“`

Una regla ACCEPT faltante para los puertos 80 y 443 hará que todas las conexiones del navegador agoten el tiempo de espera silenciosamente. También verifica que el cortafuegos del panel de control de tu alojamiento (CSF, UFW o Firewalld) no haya bloqueado inadvertidamente estos puertos después de una actualización de seguridad.

Problemas de certificado SSL que causan tiempos de espera en el protocolo de enlace TLS:

Un certificado SSL vencido o mal configurado puede hacer que el protocolo de enlace TLS se detenga, lo que se manifiesta como un tiempo de espera de conexión en lugar de un error de certificado en algunos casos límite — especialmente cuando se usan versiones TLS antiguas o conjuntos de cifrado mal configurados. Verifica tu certificado con:

“`

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

“`

Agotamiento de recursos en el servidor:

Un uso elevado de CPU o RAM puede hacer que el proceso del servidor web deje de responder. En un servidor Linux, verifica:

“`

top -b -n 1 | head -20

free -h

ss -s

“`

El comando `ss -s` muestra el resumen de los estados de los sockets — un gran número de conexiones en estado `TIME-WAIT` o `CLOSE-WAIT` indica problemas en el manejo de conexiones que harán que las nuevas conexiones agoten el tiempo de espera.

Configuración DNS incorrecta tras la migración del servidor:

Si recientemente trasladaste tu sitio a un Servidor Dedicado o cambiaste de proveedor de alojamiento, verifica que el registro A de tu dominio apunte a la dirección IP correcta y que el TTL de los registros antiguos haya expirado. Usa `dig yourdomain.com +trace` para seguir la cadena completa de resolución DNS desde los servidores raíz hacia abajo.

Comparación de ERR_CONNECTION_TIMED_OUT con Errores de Navegador Similares

Entender esta tabla es operativamente importante: si estás solucionando problemas en tu propio servidor, el error específico que ven tus usuarios te indica exactamente qué capa de la pila investigar primero.

Matriz de Decisión Práctica: Qué Solución Aplicar Primero

Usa esta secuencia para minimizar el tiempo de diagnóstico:

1. ¿Puedes acceder a otros sitios web? No — soluciona primero tu red local o la conexión con el ISP (Métodos 1, 6). Sí — continúa al paso 2.
2. ¿El sitio carga en un dispositivo o red diferente? Sí — el problema es del lado del cliente (Métodos 2, 3, 4, 5, 7). No — el problema probablemente es del lado del servidor o de la propagación DNS.
3. ¿Un verificador externo (check-host.net) muestra el sitio como caído desde múltiples ubicaciones? Sí — contacta al administrador del servidor o a tu proveedor de alojamiento. No — el problema es de enrutamiento regional o de tu ISP específico.
4. ¿El sitio carga en modo incógnito? Sí — una extensión del navegador o datos en caché son la causa (Método 4). No — continúa con las soluciones a nivel DNS y de red.
5. ¿Cambiaste recientemente los registros DNS o migraste servidores? Sí — espera la propagación DNS y verifica los registros con `dig` o `nslookup`. No — verifica el cortafuegos del lado del servidor y la configuración del servidor web.

Si gestionas tu propia infraestructura de servidor — ya sea en un VPS con cPanel o en un entorno de metal desnudo — siempre revisa los registros del servidor antes de dedicar tiempo a soluciones del lado del cliente. El registro de errores de Apache (`/var/log/apache2/error.log`) y el registro de errores de Nginx (`/var/log/nginx/error.log`) contendrán registros explícitos de fallos de conexión, eventos de agotamiento de recursos y errores de configuración.

Para los equipos que gestionan múltiples dominios, mantener el Registro de Dominios y la gestión DNS centralizados bajo un único proveedor reduce significativamente el riesgo de errores de tiempo de espera relacionados con la propagación causados por configuraciones DNS divididas o registros de dominio vencidos.

Conclusiones Técnicas Clave

• `ERR_CONNECTION_TIMED_OUT` indica específicamente un fallo a nivel TCP — el paquete SYN fue enviado pero no se recibió SYN-ACK. Esto lo distingue de los errores DNS, los errores TLS y los errores a nivel HTTP.
• Siempre prueba desde un punto de vista externo (check-host.net, curl desde un servidor remoto) antes de asumir que el problema está en tu máquina local.
• Chrome mantiene su propia caché DNS interna separada del sistema operativo. Vaciar solo la caché del sistema operativo mediante `ipconfig /flushdns` es insuficiente — también debes limpiar `chrome://net-internals/#dns`.
• En el lado del servidor, los descartes silenciosos de paquetes por reglas de cortafuegos son la causa más común de este error específico. Una conexión rechazada (`RST`) produciría un código de error diferente.
• Los retrasos de propagación DNS después de migraciones de servidores se diagnostican erróneamente con frecuencia como errores de tiempo de espera. Siempre verifica con `nslookup` contra múltiples resolvedores antes de investigar más.
• Para servidores web en producción, monitorea la salida de `ss -s` regularmente. Un recuento creciente de `CLOSE-WAIT` indica errores de manejo de sockets a nivel de aplicación que eventualmente causarán tiempos de espera de conexión bajo carga.

Preguntas Frecuentes

¿Por qué aparece ERR_CONNECTION_TIMED_OUT solo en un sitio web específico pero no en otros?

Esto casi siempre significa que el servidor de destino es inaccesible desde tu red específicamente — ya sea que el servidor esté caído, su IP haya cambiado debido a la propagación DNS, o una regla de cortafuegos en el servidor esté bloqueando tu rango de IP. Usa un verificador externo como check-host.net para confirmar si el sitio es globalmente inaccesible o solo inaccesible desde tu ubicación.

¿Vaciar la caché DNS soluciona ERR_CONNECTION_TIMED_OUT?

Puede hacerlo, pero solo si la causa es un registro DNS obsoleto que apunta a una IP de servidor antigua. Si el registro DNS es correcto y el servidor es genuinamente inaccesible, vaciar la caché no ayudará. Siempre verifica a qué dirección IP se resuelve el dominio usando `nslookup` antes y después de vaciar.

¿Puede una VPN causar ERR_CONNECTION_TIMED_OUT?

Sí. Una VPN enruta tu tráfico a través de sus propios servidores y resolvedores DNS. Si el servidor VPN está sobrecargado, geográficamente distante o tiene un problema de enrutamiento hacia el sitio de destino, verás errores de tiempo de espera. Desconecta la VPN y prueba directamente. Por el contrario, algunos sitios bloquean los rangos de IP de los nodos de salida de VPN a nivel de cortafuegos, lo que también producirá este error.

¿Cómo soluciono ERR_CONNECTION_TIMED_OUT en un servidor que gestiono?

Verifica en este orden: (1) confirma que el proceso del servidor web está en ejecución (`systemctl status nginx` o `apache2`), (2) verifica que los puertos 80 y 443 estén abiertos en tu cortafuegos (`iptables -L` o `ufw status`), (3) comprueba el uso de recursos del servidor con `top` y `free -h`, (4) revisa el registro de errores del servidor web en busca de rechazos de conexión o mensajes de agotamiento de workers, (5) confirma que tu certificado SSL es válido y no ha vencido.

¿Es ERR_CONNECTION_TIMED_OUT lo mismo que un 504 Gateway Timeout?

No. Un 504 Gateway Timeout es un error a nivel HTTP devuelto por un proxy inverso (como Nginx o un CDN) cuando no puede obtener una respuesta del servidor de origen upstream dentro de su tiempo de espera configurado. `ERR_CONNECTION_TIMED_OUT` es un error a nivel del navegador que ocurre antes de que se reciba cualquier respuesta HTTP — la propia conexión TCP nunca se completa. Ambos indican un tiempo de espera, pero en diferentes capas de la pila de red.