Servidor caído: qué revisar primero y en qué orden

Esta guía trata del servidor en sí: un VPS, un servidor dedicado o un servidor cloud que administras tú. Si solo falla un sitio web y todo lo demás en la máquina funciona, o tu sitio está en un hosting compartido, empieza mejor por la guía Sitio web caído. Aquí miramos la máquina: ¿responde todavía?, ¿puedes entrar?, ¿qué se ha detenido?

Paso 1: ¿qué está caído exactamente?

«El servidor está caído» puede significar tres cosas muy distintas, y cada una tiene su solución. Comprueba primero desde fuera, desde una red que no sea la tuya. Para los sitios web del servidor, el Website down checker te dice en segundos si el nombre resuelve, si el puerto responde y qué código de estado devuelve. Para la máquina, usa ping y una prueba de puertos desde tu equipo:

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

Lee los resultados juntos:

• Sin ping, sin SSH, sin puerto web: la máquina está apagada, bloqueada o la red que tiene delante está cortada. Sigue con el paso 2.
• El ping responde, SSH no: la máquina funciona, pero SSH está bloqueado, detenido o el servidor está demasiado sobrecargado para responder. Sigue con el paso 3.
• SSH funciona, el sitio web no: el servidor está bien, un servicio no. Sigue con el paso 4.

Algunos servidores no responden al ping a propósito. Si el ping nunca ha funcionado, fíate de las pruebas de puertos.

Paso 2: no responde nada

Abre antes que nada el panel de cliente o la consola cloud de tu proveedor. Tres preguntas resuelven la mayoría de los casos en un minuto:

1. ¿Está encendido el servidor? Una instancia detenida, una cuenta suspendida o un pago rechazado se ven desde fuera exactamente igual que una caída.
2. ¿Hay una incidencia conocida? Mira la página de estado del proveedor para tu región o centro de datos.
3. ¿Qué muestra la consola? La consola web o serie muestra la pantalla de la máquina incluso sin red. Un kernel panic, «Out of memory: Killed process» en bucle o un arranque parado en la comprobación del sistema de archivos te dicen dónde está el problema.

Si la máquina está bloqueada, un reinicio desde la consola suele devolverla. Antes de reiniciar, haz una captura de la consola: después del reinicio, la pista desaparece. Si ya no arranca, la mayoría de los proveedores ofrecen un sistema de rescate desde el que montas el disco, lees los registros y corriges /etc/fstab o una configuración de red rota.

Paso 3: el ping responde, SSH no

La máquina está viva, así que la causa está en ella. Entra por la consola y revisa los sospechosos habituales:

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

Una regla de cortafuegos añadida con prisa, tu propia dirección IP bloqueada tras varias contraseñas erróneas o una configuración de SSH que no pasó su prueba son los bloqueos más frecuentes. Desbloquea tu dirección con sudo fail2ban-client set sshd unbanip TU_IP y ejecuta siempre sudo sshd -t antes de reiniciar SSH. Si SSH funciona pero va muy lento, el servidor está sobrecargado: sigue con el paso 4.

Paso 4: ya estás dentro, lee cuatro cifras

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• Carga (uptime): muy por encima del número de núcleos significa que la máquina está sobrecargada. top o htop muestra qué proceso es el culpable.
• Memoria (free -m): sin memoria libre ni swap, y con «Killed process» en dmesg, el kernel ha detenido un proceso para sobrevivir. Suele ser la base de datos o PHP.
• Disco (df -h): un disco lleno es la causa más frecuente de un servidor caído. Las bases de datos dejan de escribir, los registros se cortan, las sesiones fallan. df -i comprueba los inodos: un disco puede estar «lleno» con gigabytes libres si millones de archivos pequeños ocupan todos los inodos.
• Errores de E/S o un sistema de archivos de solo lectura en dmesg: el propio disco tiene un problema. Deja de escribir, haz una copia de lo que puedas y contacta con tu proveedor.

Para liberar espacio sin riesgo, empieza por el diario del sistema y los archivos antiguos:

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

Nunca borres archivos de la base de datos ni del sitio web para hacer sitio.

Paso 5: ¿qué servicio se ha detenido y por qué?

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed lista cada servicio que se detuvo con un error. Su registro da el motivo: un puerto ya ocupado, un error de sintaxis en un archivo de configuración, un certificado que falta, sin espacio. Prueba la configuración antes de cada reinicio (nginx -t, apachectl configtest, php-fpm -t) y después ejecuta sudo systemctl restart SERVICIO. Un reinicio sin prueba puede tumbar un servicio que aún funcionaba a medias.

Paso 6: ¿qué ha cambiado?

Las caídas tienen causas, y casi siempre es el último cambio. Búscalo:

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

Actualizaciones automáticas, un kernel nuevo que espera un reinicio, un despliegue, una tarea cron que llenó el disco de copias de seguridad, un certificado caducado o un cambio de configuración hecho por otra persona: si alguno coincide con el inicio de la caída, ya tienes la pista.

Cuando los mismos problemas vuelven

Un servidor que se cayó una vez por un disco lleno o una base de datos detenida volverá a hacerlo. La comprobación desde fuera te dice cuándo está caído; la comprobación desde dentro te avisa antes. El agente de servidor envía carga, memoria, discos y servicios desde la propia máquina y te avisa cuando un disco supera tu umbral o se detiene un servicio que marcaste, mientras aún hay tiempo para actuar. El monitoring de servidores con agente forma parte de los planes de pago.

Cuando no quieres hacer todo esto a las 3 de la mañana

Si tu servidor está caído y prefieres que lo reparen antes que buscar tú, una intervención rápida resuelve las causas habituales a precio fijo: reinicia un servicio detenido si la prueba de configuración es correcta, libera un disco lleno y renueva un certificado caducado, con copia de seguridad previa. Si no basta, una intervención a fondo toma el relevo las 24 horas, facturada en bloques de 15 minutos, con el precio visible antes de pedir. Las dos funcionan a través del Responder, SSH como root o acceso SSH a tu hosting compartido. Todos los detalles en la página soporte de servidor 24/7.