Cuando un servidor web cae, lo primero es mantener la calma y seguir un protocolo ordenado. Actuar al azar — reiniciar servicios sin saber por qué fallaron — puede empeorar la situación o borrar evidencia valiosa para el diagnóstico.
Esta guía cubre los pasos exactos que debes seguir: desde confirmar que el servidor está realmente caído hasta restaurar el servicio y evitar que vuelva a ocurrir.
Paso 1: Confirma que el problema es real
Antes de entrar en pánico, verifica que la caída no sea local. Tu conexión a internet, un ISP intermediario o un error de DNS pueden hacer que tú no veas el sitio aunque el servidor esté perfectamente activo.
- Usa Down For Everyone Or Just Me o isitdownrightnow.com para verificar desde fuera.
- Ejecuta
curl -I https://tudominio.comdesde un servidor o VPS diferente. - Pide a un colega en otra red que intente acceder.
Si el sitio está caído para todos, entonces el problema es en tu servidor. Continúa al paso 2.
Paso 2: Revisa el estado del servidor con SSH
Conéctate al VPS o servidor dedicado por SSH. Si no puedes conectarte, el problema es grave (kernel panic, OOM killer, hardware) y necesitas usar la consola de emergencia de tu proveedor.
Una vez dentro, corre estos comandos de diagnóstico básico:
# Carga del sistema en los últimos 1, 5 y 15 minutos
uptime
# Uso de RAM y swap
free -h
# Espacio en disco
df -h
# Procesos que más consumen CPU/RAM
top -bn1 | head -20
# Últimas líneas del log del kernel
dmesg | tail -30
Un load average muy alto (mayor que el número de CPUs × 2), RAM agotada o disco al 100% son causas comunes de caída. Anótalos antes de actuar.
Paso 3: Identifica qué servicio falló
Un servidor web generalmente falla porque uno de sus servicios principales se detuvo. Los sospechosos habituales son Apache/Nginx, PHP-FPM, MySQL/MariaDB o el propio sistema operativo.
Verifica el estado de los servicios
# Para sistemas con systemd (CentOS 7+, Ubuntu 16+)
systemctl status apache2 # o httpd en CentOS
systemctl status nginx
systemctl status php8.2-fpm # ajusta la versión
systemctl status mariadb
# Ver si hay errores recientes
journalctl -u apache2 --since "10 minutes ago"
Revisa los logs de errores
Los logs son tu mejor aliado. Las rutas más comunes:
- Apache:
/var/log/apache2/error.logo/var/log/httpd/error_log - Nginx:
/var/log/nginx/error.log - MySQL/MariaDB:
/var/log/mysql/error.logo/var/log/mariadb/mariadb.log - PHP-FPM:
/var/log/php-fpm/error.log
tail -100 /var/log/apache2/error.log
Busca mensajes como "out of memory", "can't create thread", "no space left on device" o "connection refused". Cada uno apunta a una causa distinta.
Paso 4: Acciones de recuperación según la causa
Una vez identificada la causa, actúa de forma dirigida:
| Causa detectada | Acción inmediata |
|---|---|
| Servicio web detenido (sin errores claros) | systemctl restart apache2 / nginx |
| RAM agotada / OOM killer actuó | Identifica el proceso que consumió RAM, mátalo, luego reinicia el servicio |
| Disco lleno (100%) | Libera espacio: limpia logs viejos, backups temporales, cache; luego reinicia servicios |
| Base de datos caída | systemctl restart mariadb; verifica integridad con mysqlcheck |
| Proceso zombie / loop infinito | Identifica el PID con ps aux y mata con kill -9 <pid> |
| No puedes conectarte por SSH | Usa la consola VNC/KVM del panel de tu proveedor para acceso de emergencia |
Liberar espacio en disco rápidamente
# Encuentra los directorios más pesados
du -sh /* 2>/dev/null | sort -rh | head -20
# Limpia logs de Apache antiguos (ajusta la ruta)
find /var/log/apache2 -name "*.gz" -mtime +7 -delete
# Vacía la cache de paquetes (Debian/Ubuntu)
apt-get clean
Paso 5: Prevención para que no vuelva a ocurrir
Resolver la crisis es solo el primer paso. Lo que diferencia a un administrador reactivo de uno proactivo es lo que hace después de la caída.
- Configura alertas de monitoreo para CPU, RAM, disco y disponibilidad HTTP (ver nuestra guía de monitoreo de VPS para herramientas recomendadas).
- Activa logrotate para que los logs no llenen el disco.
- Ajusta los límites de memoria de PHP-FPM y MySQL para evitar que consuman toda la RAM.
- Programa backups automáticos diarios y verifica que funcionen al menos una vez al mes.
- Documenta la causa y la solución en un runbook interno, aunque sea un archivo de texto.
Si tu infraestructura crece, considera contratar un VPS administrado donde el equipo técnico del proveedor aplique estas configuraciones por ti. Agencias como elenlace.com ofrecen servicios de mantenimiento y monitoreo proactivo para que tú te concentres en tu negocio.
Conclusiones clave
- Antes de actuar, confirma que la caída es real y no un problema local de red o DNS.
- Conéctate por SSH y revisa carga, RAM y disco como primer diagnóstico.
- Los logs de errores (Apache, Nginx, MySQL, PHP-FPM) son la fuente de verdad para identificar la causa.
- Actúa de forma dirigida: reiniciar a ciegas puede ocultar el problema real.
- Después de resolver, implementa monitoreo y logrotate para evitar repetir la situación.
¿Tu equipo no tiene tiempo para gestionar incidentes de servidor? En elenlace.com ofrecemos soporte técnico y administración de VPS para que tus sitios estén siempre en línea, sin que tengas que ser el experto de guardia.
Preguntas frecuentes
¿Qué hago si no puedo conectarme al servidor por SSH?
Usa la consola de emergencia que ofrece tu proveedor de hosting (generalmente llamada consola VNC, KVM o IPMI). Desde ahí puedes iniciar sesión como si estuvieras físicamente frente al servidor y ejecutar los mismos comandos de diagnóstico.
¿Cuánto tiempo tarda normalmente en recuperarse un servidor caído?
Si la causa es un servicio detenido (sin daño de datos), la recuperación puede tomar de 2 a 10 minutos. Si el disco está lleno o hubo corrupción de base de datos, puede llevar de 30 minutos a varias horas dependiendo del volumen de datos.
¿El reinicio del servidor soluciona la mayoría de las caídas?
Un reinicio puede devolver el servicio temporalmente, pero no resuelve la causa raíz. Si reinicias sin diagnosticar, el servidor volverá a caer. Siempre identifica el porqué antes (o inmediatamente después) de reiniciar.
¿Cómo sé si fue un ataque DDoS o un problema interno?
Un DDoS generalmente se manifiesta como tráfico de red muy alto (netstat -an | grep ESTABLISHED | wc -l mostrará miles de conexiones) con el servidor respondiendo lento pero sin errores de proceso. Un problema interno (disco lleno, OOM, proceso caído) muestra los síntomas descritos en esta guía. Tu proveedor puede confirmar el diagnóstico de red.
Para saber más
Otros proveedores y guías que vale la pena comparar:
