Tutoriales de VPS
Cómo leer los registros de un VPS (2026): journalctl, systemctl, Nginx y registros de aplicaciones para localizar problemas
Cuando un VPS falla, no basta con reiniciar servicios. Este artículo sigue el orden de systemctl, journalctl, los registros access/error de Nginx, Docker logs y los registros de la aplicación para explicar con claridad cómo localizar problemas de puertos, permisos, configuración, memoria y fallos de arranque a partir de los registros.
Muchos problemas de VPS en realidad ya están escritos con claridad en los registros; simplemente nadie los mira.
Conocí a un amigo cuyo servicio Node no dejaba de fallar al iniciar. Ejecutaba una y otra vez:
systemctl restart app
Tras reiniciar más de diez veces seguía sin funcionar. Al final echó un vistazo a los registros y allí decía claramente EADDRINUSE: address already in use: el puerto estaba ocupado por un proceso antiguo. El problema no era que el servidor fuera inestable ni ninguna rareza del código; era simplemente que no se miraban los registros.
Por eso este artículo no trata de monitorización compleja. Trata solo de lo más práctico: cuando un VPS falla, dónde mirar los registros primero, cómo leerlos y hacia dónde investigar cuando ves ciertas palabras clave.
Cuando un servicio falla, el primer comando suele ser:
systemctl status 服务名
Por ejemplo:
systemctl status nginx
systemctl status docker
systemctl status mysql
systemctl status app
Fíjate en estas líneas:
- Si
Active:está en running, failed o activating - Si
Main PID:tiene un proceso - Si las últimas líneas del registro tienen errores
- Cuál es el código de salida después de
code=exited - Si hay avisos como
permission denied,address already in use,cannot bind
systemctl status sirve para juzgar rápidamente el estado actual del servicio, pero solo muestra un pequeño fragmento del registro. Para ver el registro completo hay que usar journalctl.
Si el servicio lo gestiona systemd, el comando más habitual es:
journalctl -u 服务名 -n 100 --no-pager
Por ejemplo:
journalctl -u nginx -n 100 --no-pager
journalctl -u docker -n 100 --no-pager
journalctl -u app -n 100 --no-pager
Para ver los registros en tiempo real:
journalctl -u 服务名 -f
Para ver los registros a partir de un momento determinado:
journalctl -u 服务名 --since "1 hour ago"
journalctl -u 服务名 --since "2026-05-13 10:00:00"
Si el servicio acaba de fallar al reiniciar, yo suelo mirarlo así:
systemctl restart app
journalctl -u app -n 100 --no-pager
No mires solo la última línea. Muchas causas reales están una docena de líneas más arriba, por ejemplo, fallo al leer el archivo de configuración, variables de entorno ausentes o puerto ocupado.
Algunos problemas no son de un solo servicio, sino del arranque, del disco, de la memoria, de la red o del kernel.
Para ver los registros desde este arranque:
journalctl -b -n 200 --no-pager
Para ver los registros del arranque anterior:
journalctl -b -1 -n 200 --no-pager
Si el VPS se reinicia sin motivo o los servicios se caen de repente, puedes consultar:
last reboot
journalctl -b -1 -p warning --no-pager
Palabras clave habituales:
Out of memory: memoria insuficiente, terminado por OOMKilled process: el sistema mató un procesosegfault: el programa se bloqueóI/O error: problema de disco o sistema de archivosNo space left on device: disco llenopermission denied: problema de permisos
Esto es mucho más útil que "me parece que el servidor está inestable".
Los dos registros de Nginx que más se consultan:
/var/log/nginx/access.log
/var/log/nginx/error.log
Para ver los errores en tiempo real:
tail -f /var/log/nginx/error.log
Para ver los accesos recientes:
tail -n 100 /var/log/nginx/access.log
Si el navegador recibe un 502, mira primero el error log. Causas habituales:
- Puerto upstream equivocado
- La aplicación backend no está iniciada
- Nginx no tiene permiso para acceder al socket
- PHP-FPM está caído
- Tiempo de espera agotado en la conexión del proxy inverso
Si recibes un 404, mira el access log y el server block. Puede ser:
- El dominio entró en un server_name equivocado
- La ruta root está mal escrita
- Las reglas de rewrite no son correctas
- El archivo estático no existe
Si es un 403, lo habitual es un problema de permisos o de índice de directorio.
Después de modificar la configuración de Nginx, ejecuta primero:
nginx -t
systemctl reload nginx
No reinicies directamente. nginx -t puede avisarte de antemano si la configuración tiene errores de sintaxis.
Cuando un contenedor Docker se cae, mucha gente solo mira:
docker ps
Pero la causa real suele estar en los registros:
docker logs 容器名 --tail 100
docker logs -f 容器名
Si es docker compose:
docker compose ps
docker compose logs --tail 100 服务名
docker compose logs -f 服务名
Palabras clave habituales:
permission denied: permisos incorrectos en el directorio montadoconnection refused: el servicio dependiente no está levantado o la dirección es incorrectano such file or directory: ruta del archivo de configuración incorrectaaddress already in use: conflicto de puertosexit code 137: habitualmente terminado por falta de memoria
Cuando un contenedor se reinicia una y otra vez, no cambies solo restart: always. Solo hace que el contenedor se reinicie sin parar; no resuelve la causa raíz.
Las ubicaciones de los registros varían según la aplicación.
Ubicaciones habituales:
/var/log/应用名/
/opt/应用名/logs/
/home/用户名/app/logs/
pm2 logs
Si es Node + PM2:
pm2 status
pm2 logs --lines 100
Si es Python / Gunicorn:
journalctl -u gunicorn -n 100 --no-pager
Si es PHP-FPM:
journalctl -u php8.2-fpm -n 100 --no-pager
Cuando no encuentres los registros, mira primero el archivo de servicio:
systemctl cat 服务名
Normalmente se puede ver el comando de arranque, el directorio de trabajo y el archivo de variables de entorno. Muchas causas de "el programa no arranca" son en realidad un directorio de trabajo equivocado, variables de entorno no cargadas o una ruta de configuración incorrecta.
Aquí tienes una tabla de consulta rápida:
| Palabra clave del registro | Dirección habitual |
|---|---|
address already in use | Puerto ya en uso |
permission denied | Permisos de archivo, de directorio, de puerto |
connection refused | Servicio dependiente no iniciado, puerto inaccesible |
no such file or directory | Ruta incorrecta, archivo inexistente |
No space left on device | Disco lleno, inodos llenos |
Out of memory / Killed process | Memoria insuficiente, OOM kill |
bad gateway / upstream | Nginx no puede llegar al backend |
certificate / SSL | Problemas de certificado, dominio o configuración HTTPS |
authentication failed | Problemas de contraseña, permisos o usuario de base de datos |
timeout | Red lenta, dependencias bloqueadas, bloqueo del firewall |
Cuando veas una palabra clave, no te apresures a copiar todo el error y buscarlo. Primero juzga según el escenario: ¿es la fase de arranque, la fase de acceso, la fase de conexión a la base de datos o la fase de proxy inverso?
Si vas a abrir un ticket o pedir ayuda a alguien, los registros deben pegarse con precisión.
Se recomienda proporcionar:
systemctl status 服务名
journalctl -u 服务名 -n 80 --no-pager
nginx -t
ss -lntp
Si es un problema del sitio web, añade además:
tail -n 80 /var/log/nginx/error.log
tail -n 50 /var/log/nginx/access.log
No pegues directamente miles de líneas de registro. Los demás no pueden terminarlas de leer y es fácil que se pierdan los puntos clave.
Más importante aún: antes de pegar los registros, oculta:
- IP del servidor
- Contraseña de la base de datos
- API Key
- Token
- Cookie
- Correo del usuario
- Ruta del panel de administración
Los registros suelen contener información sensible, sobre todo las pilas de errores de la aplicación y las cabeceras de las peticiones. Antes de publicarlos en foros o chats de grupo, revísalos siempre.
Si un servicio de un VPS falla, yo suelo seguir este orden:
systemctl status 服务名journalctl -u 服务名 -n 100 --no-pagerss -lntppara ver los puertosdf -hpara ver el discofree -mpara ver la memoria- Nginx error log / access log
- Los registros propios de la aplicación
- Registros de Docker / PM2 / PHP-FPM
- Qué configuración se cambió la última vez
- Después decidir si reiniciar, revertir o cambiar la configuración
Esto es mucho más fiable que "probemos a reiniciar". Reiniciar a veces recupera temporalmente, pero también borra la escena. Sobre todo en problemas intermitentes, los registros son la prueba.
Cuando tengas un problema, pregúntate primero:
- ¿El estado del servicio es running o failed?
- ¿Hay errores evidentes en las últimas 100 líneas de
journalctl -u? - ¿Hay errores de puerto ocupado, permisos, rutas, disco o memoria?
- ¿El error log de Nginx tiene información de upstream / 502 / 403 / 404?
- ¿Docker o PM2 tienen registros propios?
- ¿Se ha cambiado recientemente la configuración, los certificados, las variables de entorno o las versiones de dependencias?
- ¿Se han ocultado los datos sensibles antes de enviar los registros a otra persona?
Lo peor en el diagnóstico de un VPS es guiarse por la intuición. Los registros no siempre te dan la respuesta directamente, pero te dicen dónde mirar a continuación. Mira primero los registros y luego actúa: te ahorrarás muchos rodeos.