ERR_CONNECTION_TIMED_OUT: el servidor no responde a tiempo

Qué significa el error

El navegador resolvió el nombre, envió su petición de conexión al puerto 443 (o 80) y esperó. No llegó nada: ni una respuesta, ni un rechazo. Pasado un tiempo, Chrome se rinde y muestra ERR_CONNECTION_TIMED_OUT (« No se puede acceder a este sitio web »); Firefox dice « Se ha agotado el tiempo de espera de la conexión ». La diferencia con ERR_CONNECTION_REFUSED importa: en una conexión rechazada el servidor contesta de forma activa « aquí no hay nada »; en un tiempo agotado no contesta nadie. Rechazado: la máquina funciona pero el servidor web no. Agotado: los paquetes se pierden por el camino o la máquina no puede responder.

Causas frecuentes

1. Un firewall descarta los paquetes. ufw, firewalld, iptables o el grupo de seguridad del proveedor cloud usan drop en lugar de reject: el paquete desaparece en silencio y el navegador espera en vano. Habitual tras un servidor nuevo o un cambio de reglas.
2. El servidor o el servicio está colgado o saturado. La máquina responde a ping, pero nginx, Apache o PHP-FPM tienen todas las conexiones ocupadas o la memoria se agotó. Las conexiones nuevas esperan hasta que el navegador abandona.
3. IP equivocada en el DNS. Tras una mudanza de servidor, el registro A sigue apuntando a la máquina antigua, ya apagada: el nombre se resuelve, pero nada responde ahí.
4. La red del visitante. Un router que bloquea el destino, una VPN caída, un proxy de empresa, un filtro de contenido o un proveedor de internet con problemas de ruta.
5. MTU o IPv6. El dominio tiene un registro AAAA, pero el servidor no responde por IPv6; o un túnel reduce el tamaño máximo de paquete y las conexiones TLS se quedan a medias.

Si eres visitante

1. Abre el sitio desde tu teléfono sin wifi. Si así entra, el problema está en tu red, no en el sitio.
2. Desconecta la VPN y desactiva un proxy manual que no uses.
3. Reinicia el router y vacía la caché DNS (sudo dscacheutil -flushcache en macOS, sudo resolvectl flush-caches en Linux).
4. Prueba en una ventana privada y en otro navegador.
5. Si tampoco responde desde otra red y otro dispositivo, solo el propietario puede corregirlo.

Si es tu sitio: comprobar primero

Abre el Website down checker: si tampoco desde nuestro punto de verificación en Europa contesta el servidor, el fallo no está en tu red. Después, desde la línea de comandos:

# ¿a qué dirección apunta el dominio?
dig +short example.com A
dig +short example.com AAAA

# ¿responde el servidor? (-v muestra en qué paso se queda)
curl -v --max-time 10 -4 https://example.com/
curl -v --max-time 10 -6 https://example.com/

Si curl -4 entra y curl -6 se cuelga, el problema es IPv6. Si curl se detiene en « Trying 203.0.113.10:443… », los paquetes se pierden antes de llegar al servidor web. Entra por SSH (si tampoco responde, pasa al apartado del proveedor de hosting):

# ¿quién escucha en el 80 y el 443, y en qué dirección?
sudo ss -tlnp | grep -E ':80 |:443 '

# reglas del firewall
sudo ufw status verbose

# carga, memoria, disco
uptime
free -h
df -h

Soluciones en tu propio servidor

1. Abrir el firewall

# ufw
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# firewalld
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

En un servidor cloud, revisa también el grupo de seguridad del proveedor: bloquea antes de que el paquete llegue a tu máquina y desde dentro no se ve. Si usas fail2ban, comprueba que no vetó tu propia IP.

2. Liberar un servidor saturado

Si uptime muestra una carga muy superior al número de núcleos, o free -h enseña la memoria agotada, el servidor acepta conexiones demasiado despacio. Busca el proceso culpable con top y revisa el log de PHP-FPM: server reached pm.max_children significa que todos los workers están ocupados, a menudo por una consulta lenta o una ráfaga de robots. Reinicia el servicio afectado tras comprobar su configuración:

sudo nginx -t && sudo systemctl restart nginx
sudo systemctl restart php8.4-fpm
sudo tail -n 50 /var/log/nginx/error.log

Si se repite a diario, sube los workers si la memoria lo permite, pon una caché delante de la aplicación y bloquea a los robots inútiles.

3. Corregir la IP en el DNS

Compara dig +short example.com A con hostname -I en el servidor. Si no coinciden, corrige el registro A en tu proveedor DNS. Si el servidor no tiene IPv6 pública, elimina el registro AAAA: un AAAA sin servidor detrás produce justo este error en parte de los visitantes.

4. Escuchar en todas las direcciones

En nginx, el bloque server necesita listen 443 ssl; y listen [::]:443 ssl;. Si solo escucha en 127.0.0.1, desde fuera nadie responde. Tras el cambio: sudo nginx -t && sudo systemctl reload nginx.

Si el problema está en tu proveedor de hosting

En un hosting compartido no controlas el firewall ni la carga. Si el sitio no responde desde fuera y SSH tampoco, envía esto:

Hola, mi sitio example.com no responde desde las 9:30 (UTC) aproximadamente: los navegadores muestran ERR_CONNECTION_TIMED_OUT y el puerto 443 no contesta. El dominio se resuelve a 203.0.113.10, la IP de mi hosting. No cambié nada por mi parte. ¿Está saturado o caído el servidor de esa máquina, o hay un bloqueo en el firewall?

Para que no vuelva a pasar

Un servidor que calla es el caso en que más tarde se entera el propietario: no hay página de error, solo silencio. Una comprobación desde fuera lo nota al primer intento fallido. En tu propio servidor, el monitoring de servidores con agente de servidor te avisa antes, cuando sube la carga, se agota la memoria o se llena el disco.

¿Caído? Intervenimos. En tu propio servidor o en un hosting compartido con acceso SSH, la intervención rápida reinicia el servicio detenido si su prueba de configuración es correcta, a precio fijo, las 24 horas, todos los días; la intervención a fondo se encarga del firewall, de la sobrecarga o del DNS, en bloques de 15 minutos; la estimación es el precio máximo.