ERR_CONNECTION_TIMED_OUT

Qué significa este error y cómo reconocerlo

• El navegador muestra un mensaje como “No se puede acceder a este sitio” junto con ERR_CONNECTION_TIMED_OUT.
• El fallo aparece después de una espera apreciable, no de forma inmediata.
• El hostname funciona desde una red, pero agota el tiempo de espera desde otra.
• Las solicitudes a la dirección pública del servidor también pueden agotar el tiempo de espera mientras la consola de hosting sigue mostrando la instancia como activa.
• El problema afecta a muchos visitantes cuando el host, la interfaz de red, la ruta o la red ascendente no están disponibles.
• Un servidor sometido a una presión extrema de CPU, memoria, procesos o conexiones puede seguir encendido, pero no completar nuevas conexiones a tiempo.
• Una CDN, un reverse proxy o un balanceador de carga pueden ser accesibles mientras su conexión con el origen agota el tiempo de espera.

Causas principales, ordenadas por probabilidad

1. El host o la interfaz de red no son accesibles — el servidor, la VM, la interfaz de red, la ruta o la red ascendente pueden no estar disponibles.
2. Un firewall o grupo de seguridad descarta el tráfico silenciosamente — una regla de descarte suele causar un timeout, mientras que un rechazo explícito normalmente falla más rápido.
3. El servidor está sobrecargado — el agotamiento de recursos, los límites de procesos o un exceso de conexiones abiertas pueden impedir que se complete el handshake TCP o la respuesta de la aplicación.
4. El DNS apunta al destino equivocado — el hostname puede resolver a una dirección antigua, una dirección inaccesible o una infraestructura que ya no sirve el sitio.
5. La ruta de red del visitante está dañada — un problema de enrutamiento del ISP, una VPN, un proxy, un firewall local o un dispositivo de filtrado pueden bloquear el acceso desde una red.
6. IPv6 está configurado incorrectamente — un registro AAAA inutilizable puede provocar fallos en redes que prefieren IPv6, aunque el servicio IPv4 funcione.
7. Una CDN, un reverse proxy, un balanceador de carga o una capa de protección ascendente están mal configurados — el frontend puede no poder llegar al origen aunque el origen esté operativo.

Cómo solucionarlo

1. Prueba desde una segunda red

Abre el sitio usando datos móviles u otra conexión independiente. Si hay una VPN o un proxy activo, prueba sin él cuando esté permitido.

• Funciona en la segunda red: investiga la red Wi-Fi original, la ruta del ISP, el firewall local, la VPN, el proxy o el dispositivo de filtrado.
• Agota el tiempo de espera en todas partes: continúa con las comprobaciones de DNS, servidor, firewall y proveedor de hosting.

No des por hecho que una prueba correcta demuestra que el sitio funciona para todos los usuarios; los problemas de enrutamiento y de familia de direcciones pueden afectar solo a algunas redes.

2. Comprueba el DNS y ambas familias de direcciones

Usa una herramienta de consulta DNS como nslookup o dig para identificar las direcciones IPv4 e IPv6 devueltas para el hostname. Compara cada dirección devuelta con el servidor, balanceador de carga, CDN u otro servicio que debería recibir el tráfico.

Busca una dirección obsoleta, un registro inesperado o un destino IPv6 que no esté configurado. Si el DNS cambió recientemente, comprueba los registros autoritativos y considera el periodo de caché configurado antes de evaluar el cambio desde una sola red.

3. Prueba el servicio sin depender del navegador

Desde una red que debería poder acceder al sitio, ejecuta una solicitud de solo lectura como esta:

curl -v --connect-timeout 10 https://[your hostname]

La salida detallada ayuda a mostrar si el fallo ocurre durante la resolución del hostname, el establecimiento de la conexión TCP o la negociación HTTPS. Prueba el puerto y el protocolo reales del servicio. Un ping fallido por sí solo no es concluyente porque ICMP puede estar bloqueado.

Si administras el servicio, compara por separado el comportamiento de las conexiones IPv4 e IPv6 mediante pruebas de solo lectura adecuadas. Un fallo en una sola familia de direcciones limita la investigación a esa ruta, listener, política de firewall o registro DNS.

4. Comprueba la consola del proveedor de hosting

Usa el panel del proveedor o una consola out-of-band en lugar de depender de SSH cuando el acceso de red esté fallando. Confirma que la instancia esté en ejecución, que la interfaz de red esté conectada, que la dirección pública sea correcta y que las comprobaciones de estado del proveedor no indiquen ningún fallo.

Si la consola muestra que el host no responde, utiliza un procedimiento de recuperación autorizado. Reiniciar o apagar y volver a encender es un cambio operativo: confirma que tienes permiso, comprende el efecto sobre los usuarios activos y el trabajo no guardado, y sigue el proceso de recuperación documentado por el proveedor.

5. Revisa las reglas del firewall de la nube y del host

Comprueba los grupos de seguridad, las ACL de red y las políticas de firewall del proveedor para el puerto de servicio entrante esperado, normalmente HTTP o HTTPS según la configuración. Después, revisa el firewall del sistema operativo, como ufw o iptables, si tienes acceso a la consola.

Comprueba las reglas introducidas durante un cambio de hardening, un despliegue, una actualización de dirección o una migración. Confirma que el tráfico esté permitido desde los rangos de origen relevantes y que la regla se aplique a la interfaz y la familia de direcciones correctas. No desactives ampliamente la protección; realiza solo el cambio autorizado más pequeño y documéntalo.

6. Comprueba el agotamiento de recursos

Desde la consola del proveedor o una sesión administrativa existente, inspecciona la CPU, la memoria, la presión del disco, los límites de procesos, los sockets en escucha y el número de conexiones. Una máquina puede parecer encendida y, aun así, estar demasiado saturada para aceptar nuevas conexiones.

Compara las lecturas actuales con los niveles normales y revisa los logs alrededor del primer fallo. Si un servicio está agotado, sigue el procedimiento aprobado de capacidad o recuperación en lugar de reiniciarlo repetidamente. Un reinicio puede interrumpir el tráfico activo y ocultar el problema de carga subyacente.

7. Comprueba el proxy, la CDN o el balanceador de carga

Si el DNS apunta a una CDN, un reverse proxy o un balanceador de carga, verifica que el frontend pueda llegar al origen en el puerto configurado. Comprueba la dirección del origen, el estado de las comprobaciones de salud, la configuración TLS, la ruta de red y las listas de permitidos.

Un origen saludable no descarta una política o una ruta defectuosas entre el frontend y el origen. Del mismo modo, un frontend saludable no demuestra que el origen esté aceptando conexiones.

8. Escala el problema con pruebas útiles

Registra el hostname afectado, la hora aproximada y la zona horaria, la red del cliente, las direcciones IPv4 e IPv6 resueltas, si cada familia de direcciones se comporta de forma diferente, la salida detallada de la conexión y el estado de salud mostrado en la consola del proveedor. Esta información ayuda a distinguir entre fallos de DNS, enrutamiento, filtrado, host e intermediarios.

Prevención y cómo verificar la solución

• Supervisa el sitio desde varias ubicaciones externas y genera alertas de los timeouts de conexión por separado de los fallos de estado HTTP.
• Mantén documentados los registros DNS, las direcciones públicas, los orígenes de la CDN y la configuración IPv4/IPv6, y revísalos después de las migraciones.
• Prueba los cambios en firewalls y grupos de seguridad mediante un proceso controlado que incluya una vía de recuperación a través de la consola del proveedor.
• Mantén margen disponible de CPU, memoria, descriptores de archivo, procesos y conexiones para que los picos de tráfico no impidan nuevas conexiones.
• Supervisa el estado del origen por separado del estado de la CDN o del balanceador de carga.
• Incluye las pruebas desde una segunda red y las evidencias de timeouts de conexión en la lista de comprobación de incidentes.
• Usa un comportamiento de firewall claro e intencionado para los puertos de servicio legítimos, conservando la política de seguridad necesaria del entorno.

Preguntas frecuentes