Tutoriales de VPS
Qué hacer cuando los servicios del VPS no vuelven tras un reinicio (2026): diagnóstico de systemd, Docker, Nginx y arranque automático de bases de datos
Tras reiniciar el VPS, el sitio web, los contenedores Docker, Nginx o MySQL no arrancan: no te apresures a reinstalar el sistema. Revisa en orden systemd, enable, los registros, los puertos y las dependencias; normalmente podrás localizar el problema rápido.
Qué hacer cuando los servicios del VPS no vuelven tras un reinicio (2026): diagnóstico de systemd, Docker, Nginx y arranque automático de bases de datos
He visto bastantes fallos de VPS que no eran "el servicio se cayó", sino que los servicios simplemente no arrancaron automáticamente después de reiniciar la máquina.
Los escenarios más habituales son estos:
- El proveedor hizo mantenimiento y el VPS se reinició una vez
- Actualizaste el kernel tú mismo y ejecutaste
rebootsin pensarlo - La máquina se quedó colgada y pulsaste reinicio forzado en el panel
- Entre Docker, Nginx, MySQL, Redis y demás, siempre hay uno que no vuelve
Si sigues delante del ordenador, no pasa nada: entras por SSH y ejecutas manualmente systemctl start nginx para recuperarlo. El problema es un reinicio automático de madrugada y descubrir al día siguiente que el sitio estuvo caído toda la noche.
Este artículo sigue mi propio orden de diagnóstico: primero confirmar si el servicio está levantado, luego ver si está configurado para arrancar al inicio y, por último, averiguar por qué falló el arranque automático.
Que no puedas acceder tras un reinicio no significa necesariamente que sea el mismo problema.
| Síntoma | Problema más probable |
|---|---|
systemctl status muestra inactive | El servicio no está configurado para arrancar al inicio, o se deshabilitó |
| Muestra failed | El servicio intentó arrancar, pero falló |
| El servicio está active, pero el sitio no abre | Problema de puerto, firewall, configuración de Nginx o servicio upstream |
| Los contenedores Docker no arrancaron | No se configuró la restart policy del contenedor, o Docker mismo no arrancó |
| La base de datos no arrancó | Error de configuración, disco lleno, problema de permisos, salida anómala la última vez |
Así que el primer paso no es adivinar: entra por SSH y mira el estado real.
systemctl status nginx
systemctl status docker
systemctl status mysql
systemctl status redis
Si tu sistema usa PostgreSQL o MariaDB, el nombre del servicio puede ser:
systemctl status postgresql
systemctl status mariadb
Si no estás seguro del nombre del servicio, puedes buscarlo:
systemctl list-units --type=service | grep -i nginx
systemctl list-units --type=service | grep -i mysql
Mucha gente solo hace este paso al desplegar un servicio por primera vez:
systemctl start nginx
Esto solo significa "iniciar ahora", no "iniciar en el próximo arranque".
La forma correcta es:
systemctl enable nginx
systemctl enable docker
systemctl enable mysql
Para confirmar si se configuró bien:
systemctl is-enabled nginx
systemctl is-enabled docker
systemctl is-enabled mysql
Solo cuando ves enabled significa que arrancará junto con el sistema.
Si la salida es disabled, eso lo explica: todo funciona bien después de iniciarlo manualmente, pero en cuanto el VPS se reinicia, no vuelve por sí solo.
Ahora, después de desplegar un servicio, hago una comprobación rápida:
systemctl is-enabled nginx docker mysql
Es muy simple, pero evita muchos problemas.
Si en systemctl status ves failed, ya no es simplemente que falte el arranque automático.
En ese caso, no mires solo la última línea: mira el registro completo:
journalctl -u nginx -b --no-pager
journalctl -u docker -b --no-pager
journalctl -u mysql -b --no-pager
El -b de aquí es muy útil: solo muestra los registros desde este arranque, así no se mezclan errores antiguos.
Primero prueba la configuración:
nginx -t
Si hay un problema, normalmente te dice exactamente qué línea está mal. Por ejemplo:
- Falta un punto y coma
server_nameestá en el lugar equivocado- La ruta del certificado no existe
- La dirección upstream del proxy inverso está mal escrita
Después de corregirlo, ejecuta:
systemctl restart nginx
systemctl status nginx
Cuando MySQL / MariaDB no arranca tras un reinicio, normalmente reviso primero esto:
df -h
journalctl -u mysql -b --no-pager
ls -ld /var/lib/mysql
Si el disco está lleno, la base de datos puede fallar fácilmente al arrancar. Una vez me pasó: el problema real no era la configuración de MySQL, sino que los registros llenaron el disco y la base de datos no podía ni escribir archivos temporales.
En PostgreSQL puedes revisar:
journalctl -u postgresql -b --no-pager
systemctl status postgresql
No te apresures a reinstalar solo porque la base de datos no arranca: primero encuentra el primer error claro en el registro.
Docker es otro punto conflictivo.
Mucha gente inicia contenedores con docker run sin añadir una política de reinicio. El contenedor funciona en ese momento, pero tras reiniciar el VPS no vuelve automáticamente.
Primero mira el estado de los contenedores:
docker ps -a
Luego mira la política de reinicio de un contenedor concreto:
docker inspect 容器名 --format '{{.HostConfig.RestartPolicy.Name}}'
Si la salida es no, no se reiniciará automáticamente.
Solución habitual:
docker update --restart unless-stopped 容器名
Si usas Docker Compose, añade esto en compose.yml:
services:
app:
image: your-image
restart: unless-stopped
Luego reinicia:
docker compose up -d
Aquí recomiendo más unless-stopped que usar always sin pensar. Porque un contenedor que detuviste manualmente suele ser uno que no quieres que vuelva a levantarse por su cuenta.
Esto también es muy común.
Que systemctl status nginx muestre active no significa que el sitio sea necesariamente accesible. También tienes que ver si el puerto está escuchando:
ss -lntp
Fíjate en:
:80:443- El puerto propio de la aplicación, como
:3000,:8000,:8080
Si Nginx está levantado pero la aplicación backend no, al acceder puede aparecer un 502.
En ese caso, revisa en orden:
systemctl status nginx
systemctl status your-app
ss -lntp
curl -I http://127.0.0.1
Si se puede acceder localmente pero no desde internet, revisa el firewall:
ufw status
iptables -S
El proveedor cloud también tiene una capa de security group; no lo olvides. Mucha gente tiene todo bien configurado dentro de la máquina, pero el security group del panel no permite 80/443, y pierden mucho tiempo diagnosticando.
Algunos servicios arrancan bien manualmente, pero fallan al arrancar automáticamente porque arrancan demasiado pronto.
Por ejemplo:
- La aplicación arranca antes que la base de datos
- Nginx arranca antes que el directorio donde se monta el certificado
- El disco del que depende el contenedor Docker aún no está montado
- La red aún no está lista del todo y el servicio ya empezó a conectar con APIs externas
En este tipo de problemas, normalmente se ven errores como "connection failed", "directory does not exist" o "port unavailable" en journalctl.
Los servicios de systemd pueden añadir dependencias, por ejemplo:
[Unit]
After=network-online.target mysql.service
Wants=network-online.target
Después de modificar el archivo unit, ejecuta:
systemctl daemon-reload
systemctl restart your-service
Si usas Docker Compose, puedes usar depends_on, pero ten en cuenta: depends_on solo garantiza el orden de arranque, no que la base de datos esté completamente lista. La forma realmente rigurosa es que la propia aplicación soporte reintentos de conexión.
Si este VPS ejecuta un sitio web de producción, normalmente hago un simulacro manual.
Primero confirmo que todos los servicios están configurados para arrancar al inicio:
systemctl is-enabled nginx docker mysql
Luego reinicio:
reboot
Espero 1-2 minutos, vuelvo a entrar y compruebo:
systemctl --failed
systemctl status nginx docker mysql
ss -lntp
curl -I https://你的域名
Si es un proyecto Docker, además reviso:
docker ps
Esta comprobación no es complicada, pero es muy útil. Porque cuando de verdad ocurre un problema, puede que no estés conectado en ese momento.
La próxima vez que los servicios no se recuperen tras reiniciar el VPS, puedes seguir este orden:
systemctl status 服务名: confirmar si está inactive, failed o activesystemctl is-enabled 服务名: ver si arranca al iniciojournalctl -u 服务名 -b --no-pager: mirar los registros de este arranquesystemctl --failed: listar todos los servicios fallidosss -lntp: confirmar si el puerto está escuchandodocker ps -a: si usas Docker, ver si los contenedores arrancarondf -h: para problemas de base de datos y registros, revisa primero el discocurl -I http://127.0.0.1: distinguir entre problemas del servicio local y problemas de acceso desde internet
No reinstales el sistema de inmediato, ni te limites a pulsar reiniciar en el panel. Muchos problemas son en realidad un enable que falta o un orden de arranque incorrecto de algún servicio.
El hábito que de verdad hay que cultivar es: después del despliegue, hacer un simulacro de reinicio de forma proactiva.
Un VPS que aguanta un reinicio manual tiene más probabilidades de aguantar situaciones imprevistas como mantenimientos nocturnos del proveedor, actualizaciones del kernel o migraciones de host.