Su sitio web está caído: cómo leer los logs del VPS antes de reiniciar todo

Son las 9:12 de la mañana.

Un cliente le envía un mensaje:

El sitio web está caído.

Abres la página y ves un error 502 Bad Gateway.

El primer instinto suele ser reiniciar Nginx, reiniciar PHP, reiniciar MySQL o reiniciar todo el VPS.

A veces eso hace que el sitio web regrese.

También puede borrar la pista más útil que tenías.

Un reinicio le indica que reiniciar ayudó. No le dice por qué falló el servicio.

Los servidores Linux suelen dejar un rastro. Los servidores web escriben errores. PHP registra fallas. MySQL informa fallas y problemas de inicio. El sistema operativo registra eventos de servicio. El desafío es saber dónde buscar y cómo leer sólo las pocas líneas que importan.

Esta guía muestra un método práctico para solucionar problemas de un VPS Linux sin probar comandos aleatorios.

No es necesario ser un experto en Linux.

necesita tres cosas:

1. la hora aproximada en que comenzó el problema;
2. el nombre del servicio involucrado;
3. un pequeño grupo de comandos para leer registros.

Eso es suficiente para resolver una sorprendente cantidad de problemas de alojamiento.

Si está eligiendo dónde alojar esta infraestructura, compare nuestros planes VPS con el hosting compartido. Un VPS le da control del sistema operativo; nuestra comparación de hosting explica cómo cambian sus responsabilidades administrativas.

Primera regla: no reiniciar antes de recopilar pruebas

Un reinicio no es un diagnóstico.

Si el servidor está completamente congelado o es inaccesible, es posible que sea inevitable reiniciarlo. Pero si SSH aún funciona, primero tómate unos minutos para recopilar información.

Antes de cambiar algo, registre:

date
uptime
df -h
free -h

Estos cuatro comandos responden preguntas útiles.

date confirma la hora del servidor.

uptime muestra cuánto tiempo ha estado funcionando el servidor y proporciona una vista rápida de los promedios de carga.

df -h muestra el uso del disco.

free -h muestra memoria e swap.

Un sistema de archivos completo puede dañar las aplicaciones incluso cuando la CPU y la RAM se ven bien. Un servidor que casi no tiene memoria disponible puede interrumpir procesos o comportarse con lentitud. Un sitio que falló inmediatamente después de un reinicio puede tener un servicio que no se inició automáticamente.

Guarde el resultado en algún lugar antes de comenzar a realizar cambios.

Comience con el estado del servicio

Ubuntu, Debian, AlmaLinux, Rocky Linux y muchas otras distribuciones modernas utilizan systemd para administrar servicios.

El comando:

systemctl status SERVICE

le da una vista rápida.

Para Nginx:

sudo systemctl status nginx

Para Apache en Ubuntu o Debian:

sudo systemctl status apache2

Para MySQL:

sudo systemctl status mysql

Un servicio saludable normalmente muestra:

Active: active (running)

Un servicio fallido puede mostrar:

Active: failed

La salida del estado a menudo incluye algunas líneas de registro recientes.

No se detenga ahí.

Las últimas cinco líneas pueden mostrar el síntoma final pero no el motivo por el que comenzó el problema.

Ahí es donde resulta útil journalctl.

Conoce a Journalctl

En los sistemas Linux basados en systemd, el diario recopila mensajes de muchos servicios.

Ubuntu documenta journalctl como el comando utilizado para imprimir las entradas de registro almacenadas por systemd-journald.

Corriendo:

sudo journalctl

puede producir miles de líneas.

Rara vez eso es lo que quieres.

La habilidad útil es filtrar.

Para ver registros de Nginx:

sudo journalctl -u nginx

Para MySQL:

sudo journalctl -u mysql

Para SSH:

sudo journalctl -u ssh

La opción -u filtra por unidad systemd.

Ahora el resultado es sobre el servicio que realmente le interesa.

Mostrar solo registros recientes

Si el sitio web falló hace diez minutos, probablemente no necesite los registros del mes pasado.

Prueba:

sudo journalctl -u nginx --since "30 minutes ago"

O:

sudo journalctl -u mysql --since today

También puede utilizar una hora exacta:

sudo journalctl -u nginx --since "2026-10-01 08:30:00"

Este es uno de los hábitos de resolución de problemas más útiles que puede desarrollar.

Conecte siempre el error a una marca de tiempo.

Si el cliente dice que el problema comenzó alrededor de las 8:45, comience a leer alrededor de las 8:40.

Cinco minutos de registros enfocados son más útiles que 50.000 líneas no relacionadas.

Antes de investigar un servicio, compruebe si el nombre resuelve al servidor previsto con nuestra consulta DNS. Esta herramienta consulta DNS público; para conocer el estado de Nginx, PHP o MySQL necesita los logs del servidor. Nuestra guía de nameservers y propagación ayuda a distinguir un cambio DNS de una caída de la aplicación.

Mira un registro en vivo

A veces, el sitio falla en este momento y desea ver qué sucede cuando actualiza la página.

Para un servicio systemd:

sudo journalctl -u nginx -f

La opción -f sigue los mensajes nuevos a medida que llegan.

Prensa:

Ctrl+C

para parar.

Esto es especialmente útil al probar un cambio de configuración.

Abra el registro en una ventana SSH.

Abra el sitio web en su navegador.

Actualiza la página.

Mira lo que aparece.

El servidor a menudo le dice exactamente lo que no le gusta.

Los archivos de registro tradicionales siguen siendo importantes

No todos los mensajes útiles se encuentran únicamente en el diario systemd.

Las aplicaciones y servidores web suelen escribir archivos tradicionales en:

/var/log/

Lista el directorio:

sudo ls -lah /var/log

Es posible que vea directorios de Nginx, Apache, MySQL y otros servicios.

Los nombres exactos de los archivos dependen de su distribución de Linux, versión de software y configuración.

No asuma que todos los VPS tienen rutas idénticas.

Registros de Nginx

En muchos sistemas Ubuntu y Debian, Nginx suele escribir:

/var/log/nginx/access.log
/var/log/nginx/error.log

El registro de acceso registra las solicitudes.

El registro de errores suele ser más útil cuando el sitio web no funciona.

Lea las últimas 50 líneas:

sudo tail -n 50 /var/log/nginx/error.log

Síguelo en vivo:

sudo tail -f /var/log/nginx/error.log

Busca una palabra:

sudo grep -i "error" /var/log/nginx/error.log

Busque un dominio en particular:

sudo grep "example.com" /var/log/nginx/error.log

Un error 502 puede mostrar mensajes que involucran un servicio ascendente, un socket Unix, PHP-FPM o una conexión rechazada.

Eso inmediatamente le indica dónde investigar.

registros de apache

En Ubuntu y Debian, Apache usa comúnmente:

/var/log/apache2/access.log
/var/log/apache2/error.log

Leer errores recientes:

sudo tail -n 100 /var/log/apache2/error.log

En los sistemas de la familia RHEL, como AlmaLinux o Rocky Linux, Apache suele denominarse httpd y las ubicaciones de registro suelen utilizar:

/var/log/httpd/

Es por eso que copiar comandos de un tutorial aleatorio sin verificar su distribución puede generar confusión.

Primero identifique su sistema operativo:

cat /etc/os-release

Luego utilice rutas apropiadas para ese sistema.

Registros PHP-FPM

Los problemas de PHP a menudo aparecen como errores del servidor web porque Nginx o Apache están esperando que PHP responda.

Primero identifique los servicios PHP instalados:

systemctl list-units --type=service | grep -i php

Es posible que vea algo como:

php8.3-fpm.service

Luego inspeccione:

sudo systemctl status php8.3-fpm

Y lea los registros recientes:

sudo journalctl -u php8.3-fpm --since "30 minutes ago"

Su versión de PHP puede ser diferente.

No escriba ciegamente php8.3-fpm si su servidor ejecuta otra versión.

Los errores de PHP también se pueden escribir en archivos de registro específicos de la aplicación o del grupo, según la configuración.

Si WordPress, WHMCS u otra aplicación PHP de repente comienza a devolver errores 500, verifique tanto el registro del servidor web como los registros del servicio PHP-FPM.

Una advertencia TLS requiere una investigación distinta de un error 502. Nuestra página de certificados SSL explica las opciones, y el decodificador CSR permite revisar los nombres y la clave pública de una solicitud de certificado. No demuestra que el certificado instalado sea válido o confiable; consulte qué certificado SSL necesita para orientar esa revisión.

Registros de MySQL

Un sitio web puede parecer un problema de servidor web cuando el problema real es la base de datos.

Consulta el servicio:

sudo systemctl status mysql

Entonces:

sudo journalctl -u mysql --since "30 minutes ago"

Los síntomas comunes incluyen:

• MySQL se detuvo inesperadamente;
• el disco está lleno;
• los permisos impiden el inicio;
• un cambio de configuración no es válido;
• la presión de la memoria provocó la muerte del proceso;
• La aplicación ha agotado las conexiones.

Las ubicaciones de los registros difieren según la distribución y la configuración, por lo que el diario es una buena primera parada.

Si desea aprender cómo instalar y administrar un servidor MySQL básico, lea Cómo instalar MySQL en un VPS de Ubuntu y crear su primera base de datos.

Aprenda cuatro comandos de lectura de registros

No necesita un gran vocabulario de comando.

Comience con estos.

cola

Mostrar el final de un archivo:

tail -n 50 file.log

Sigue nuevas líneas:

tail -f file.log

menos

Abra un archivo grande sin imprimir todo:

less file.log

Claves útiles:

Space       next page
b           previous page
/word       search
n           next match
q           quit

grep

Encuentra texto coincidente:

grep -i "error" file.log

-i hace que la búsqueda no distinga entre mayúsculas y minúsculas.

Puede buscar varios términos útiles:

grep -Ei "error|failed|fatal|denied" file.log

diarioctl

Leer registros de servicios estructurados:

sudo journalctl -u nginx --since "1 hour ago"

Estas cuatro herramientas resuelven un gran porcentaje de las tareas básicas de resolución de problemas de VPS.

¿Qué errores HTTP comunes intentan decirle?

El error del navegador no siempre es la causa principal, pero le ayuda a elegir el primer registro.

403 Prohibido

El servidor recibió la solicitud pero no entregará el contenido.

Las posibles causas incluyen:

• permisos de archivos;
• permisos de directorio;
• reglas de acceso al servidor web;
• archivos de índice faltantes;
• reglas de seguridad.

Comience con el registro de errores del servidor web.

404 no encontrado

El servidor no puede encontrar el recurso solicitado.

Comprobar:

• raíz del documento;
• Reglas de reescritura de URL;
• rutas de aplicación;
• si el archivo existe;
• si el dominio apunta al host virtual esperado.

500 Error interno del servidor

La aplicación o el servidor web encontró una falla interna.

Comprobar:

• registros de PHP;
• registros de aplicaciones;
• Registros de errores de Apache o Nginx;
• cambios de configuración recientes.

502 Puerta de enlace incorrecta

Un proxy como Nginx no pudo obtener una respuesta válida del servicio ascendente.

Los ejemplos comunes incluyen:

• PHP-FPM se detuvo;
• la ruta del socket PHP cambió;
• una aplicación de backend no funciona;
• Los permisos de conexión son incorrectos.

Servicio 503 no disponible

El servicio existe pero actualmente no puede manejar la solicitud.

Las posibles causas incluyen:

• mantenimiento de aplicaciones;
• trabajadores exhaustos;
• sobrecarga de backend;
• una dependencia detenida.

Utilice el código de estado como señal, no como diagnóstico final.

Un ejemplo práctico 502

Supongamos que el navegador muestra:

502 Bad Gateway

No reiniciar.

Comience con:

sudo systemctl status nginx

Nginx está activo.

Ahora:

sudo tail -n 50 /var/log/nginx/error.log

Encuentra un mensaje que muestra que Nginx no puede conectarse al socket PHP-FPM.

Verifique los servicios PHP:

systemctl list-units --type=service | grep -i php

Luego inspeccione el servicio que se muestra en su sistema.

Por ejemplo:

sudo systemctl status php8.3-fpm

Ha fracasado.

Ahora lee:

sudo journalctl -u php8.3-fpm --since "30 minutes ago"

El registro apunta a un error de configuración de PHP introducido durante un cambio reciente.

Ahora sabes qué arreglar.

Si hubiera reiniciado todo el servidor primero, es posible que PHP hubiera regresado temporalmente o hubiera fallado nuevamente sin que usted entendiera por qué.

Los registros convierten las conjeturas en pruebas.

Revisa el disco antes de culpar a la aplicación.

Un disco lleno puede producir fallos extraños.

Ejecutar:

df -h

Busque sistemas de archivos cercanos al 100 por ciento.

Verifique también el uso de inodos:

df -i

Un sistema de archivos puede tener gigabytes libres pero no inodos libres si contiene una enorme cantidad de archivos pequeños.

Si /var, /tmp o el sistema de archivos raíz están llenos, es posible que las aplicaciones no puedan crear archivos temporales, registros, archivos de bases de datos, sesiones PHP, sockets o archivos de paquetes.

No empieces a eliminar archivos aleatorios.

Primero identifique qué consumió el espacio.

Por ejemplo:

sudo du -xh /var | sort -h | tail -n 30

Utilice los comandos de limpieza de disco con cuidado en los servidores de producción.

Comprobar la memoria cuando los servicios desaparecen

Ejecutar:

free -h

Luego busque en el diario del kernel eventos de falta de memoria:

sudo journalctl -k | grep -Ei "out of memory|oom|killed process"

Si Linux eliminó MySQL o PHP porque el servidor se quedó sin memoria, reiniciar el servicio puede restaurar el sitio pero no resolverá el problema de capacidad.

Es necesario determinar qué consumió la memoria.

El registro muestra el evento.

El seguimiento muestra la tendencia.

Lea el primer error, no solo el último error

Un error común es leer la línea final.

Imagina esta secuencia:

09:02 Configuration file contains invalid directive
09:02 Service startup failed
09:03 Restart scheduled
09:03 Service startup failed
09:04 Too many restart attempts

La última línea dice demasiados intentos de reinicio.

Ese no es el problema original.

La primera línea es.

Al solucionar problemas, mire un poco antes de la falla obvia.

La causa suele aparecer antes de la cascada de mensajes secundarios.

Guardar evidencia antes de editar

Antes de cambiar un archivo de configuración, cree una copia de seguridad:

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup

Utilice pruebas de configuración cuando el software las admita.

Para Nginx:

sudo nginx -t

Para Apache en Ubuntu:

sudo apache2ctl configtest

Una prueba de sintaxis es mucho más segura que reiniciar un servidor web de producción y esperar.

Si la prueba falla, primero arregle la configuración.

No publicar registros completos públicamente

Los registros pueden contener información confidencial.

Antes de pegarlos en un foro, ticket, chat o tema público, busque:

• direcciones IP;
• nombres de usuario;
• direcciones de correo electrónico;
• rutas del sistema de archivos;
• nombres de bases de datos;
• tokens API;
• encabezados de autorización;
• identificadores de sesión;
• cadenas de consulta;
• datos del cliente.

Comparta las líneas mínimas necesarias para diagnosticar el problema.

Nunca publique contraseñas, claves privadas, credenciales de bases de datos ni tokens de acceso.

Cree una rutina sencilla de resolución de problemas

Cuando un sitio web falla, utilice el mismo orden siempre.

Paso 1: confirma el síntoma

Consulte el sitio web desde su navegador.

Registre el error HTTP y la hora.

Paso 2: revisa el VPS

date
uptime
df -h
free -h

Paso 3: consulta el servicio correspondiente

sudo systemctl status nginx

o el servicio que utiliza.

Paso 4: lea los registros de servicio recientes

sudo journalctl -u nginx --since "30 minutes ago"

Paso 5: lea los registros específicos de la aplicación

Ejemplos:

sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/apache2/error.log

Paso 6: identificar el primer error significativo

Buscar por marca de tiempo.

Paso 7: pruebe la solución propuesta

Utilice comprobaciones de sintaxis o configuración antes de reiniciar.

Paso 8: reinicia solo el servicio que lo necesita

Por ejemplo:

sudo systemctl restart nginx

Paso 9: verificar

Comprobar:

sudo systemctl status nginx

Luego cargue el sitio web nuevamente.

Paso 10: documente lo sucedido

Anota la causa y soluciona.

El próximo incidente será más rápido.