Tutoriales de VPS
La hora del VPS no es correcta (2026): solución de problemas de NTP, chrony, systemd-timesyncd y sincronización de zona horaria
Una hora inexacta en el VPS afecta la validación de certificados, el orden de los registros, las tareas programadas, el estado de sesión JWT/inicio de sesión y las marcas de tiempo de la base de datos. Las causas comunes incluyen configuración incorrecta de la zona horaria, NTP no habilitado, fallos de chrony o systemd-timesyncd, UDP 123 bloqueado y deriva de hora en el host de virtualización. Este artículo diagnostica capa por capa usando timedatectl, el servicio NTP, chrony, la red y el impacto en el negocio.
Cuando la hora del VPS no es correcta, parece un problema menor, pero en la práctica puede desviar fácilmente la dirección del diagnóstico.
El certificado claramente no ha caducado, pero el programa informa un fallo de validación TLS; las tareas cron "no se ejecutan a la hora prevista"; el orden de los registros salta hacia adelante y hacia atrás; JWT, Cookie y el inicio de sesión OAuth dejan de funcionar de repente; las marcas de tiempo escritas en la base de datos difieren de la hora real en varias horas. En muchos casos, la causa raíz no es que la aplicación esté rota, sino un problema con la hora del sistema, la zona horaria o la sincronización NTP.
Este artículo sigue un orden de diagnóstico: primero confirmar la hora y la zona horaria del sistema, luego ver si NTP está habilitado y después revisar por separado systemd-timesyncd, chrony, la conectividad de red y el impacto en el lado del negocio.
Primero observa el estado actual de la hora:
timedatectl
Fíjate en estas líneas:
Local time: ...
Universal time: ...
Time zone: ...
System clock synchronized: yes/no
NTP service: active/inactive
Aquí hay que distinguir dos problemas:
- La zona horaria no coincide con lo que esperas: por ejemplo, el sistema usa UTC pero tú creías que era Asia/Shanghai.
- La hora del sistema en sí es inexacta: la hora UTC ya difiere de la hora real en decenas de segundos, varios minutos o incluso horas.
Una zona horaria inconsistente no es necesariamente un fallo. Muchos sistemas de producción usan UTC de forma uniforme, lo que resulta más claro. Lo realmente peligroso es la deriva del reloj del sistema, especialmente cuando supera varios minutos.
Si estás diagnosticando tareas programadas, también puedes leer este artículo: Tareas programadas del VPS que no se ejecutan: cron, crontab, systemd timer.
Ver zonas horarias disponibles:
timedatectl list-timezones | grep Shanghai
Configurar la zona horaria de Shanghái:
sudo timedatectl set-timezone Asia/Shanghai
Si prefieres usar UTC:
sudo timedatectl set-timezone UTC
Mi recomendación: usar UTC de forma uniforme dentro del servidor y convertir a hora local en la capa de visualización orientada al usuario. Pero si tu equipo, el sistema de registros y las ventanas de mantenimiento se comunican todos en hora de Pekín, usar Asia/Shanghai también es válido; la clave es la coherencia en toda la cadena.
No confundas "la zona horaria ya está bien" con "NTP está arreglado". Cambiar la zona horaria solo afecta la visualización y la interpretación de la hora local; no resuelve la deriva del reloj del sistema.
Habilitar NTP:
sudo timedatectl set-ntp true
Luego revisa el estado:
timedatectl status
Si ves:
System clock synchronized: yes
NTP service: active
significa que a nivel del sistema ya se considera que la sincronización de hora es normal.
Si aparece no o inactive, sigue revisando los servicios que se indican más abajo. Las distintas distribuciones usan componentes de sincronización de hora predeterminados diferentes:
- Ubuntu / Debian comúnmente:
systemd-timesyncd - RHEL / Rocky / AlmaLinux comúnmente:
chronyd - Algunas imágenes instalan el tradicional
ntpontpsec
No habilites varios servicios de sincronización de hora al mismo tiempo, ya que pueden entrar en conflicto entre sí.
En Debian / Ubuntu, primero revisa:
systemctl status systemd-timesyncd
Si no está iniciado:
sudo systemctl enable --now systemd-timesyncd
Ver detalles de sincronización:
timedatectl timesync-status
Las anomalías comunes incluyen:
- No hay ningún NTP Server disponible
- La red no puede acceder a UDP 123
- Fallo de resolución DNS
- La desviación de la hora local es demasiado grande y requiere una calibración manual previa
Revisa los registros:
journalctl -u systemd-timesyncd --since "2 hours ago"
Si en los registros hay problemas de resolución DNS, puedes consultar: Fallo de resolución DNS en el VPS.
Muchos servidores son más adecuados para chrony, especialmente entornos virtualizados y VPS donde la hora puede saltar.
Instalar:
sudo apt install chrony -y
O:
sudo dnf install chrony -y
Habilitar:
sudo systemctl enable --now chrony
En algunos sistemas el nombre del servicio es chronyd:
sudo systemctl enable --now chronyd
Ver fuentes de sincronización:
chronyc sources -v
Ver estado de seguimiento:
chronyc tracking
Debes fijarte especialmente en:
- Si hay una fuente de sincronización marcada con
* - Si
Last offsetes muy grande - Si
Leap statuses normal - Si
Stratumes razonable
Si todas las fuentes están en ^?, normalmente indica que las fuentes NTP no son accesibles o no responden.
NTP usa UDP 123 por defecto. Cuando el UDP saliente del VPS está restringido, la sincronización de hora puede fallar continuamente.
Primero confirma que DNS puede resolver:
getent hosts pool.ntp.org
Luego revisa las reglas del firewall:
sudo ufw status
sudo iptables -S
sudo nft list ruleset
En la mayoría de los casos, un VPS normal no bloquea el UDP 123 saliente. Pero algunos firewalls en la nube, grupos de seguridad, políticas de red empresariales o reglas de firewall en imágenes mínimas pueden bloquearlo.
Si usas reglas de firewall propias, primero permite el UDP 123 saliente y luego reinicia el servicio de sincronización:
sudo systemctl restart systemd-timesyncd
sudo systemctl restart chrony
Solo reinicia el servicio que realmente estés usando.
Si la hora del sistema difiere mucho, el servicio NTP a veces no la corrige suavemente de inmediato. Puedes calibrar manualmente primero y luego dejar que NTP la mantenga.
Usando chrony:
sudo chronyc makestep
Luego revisa:
chronyc tracking
timedatectl
Si no tienes chrony, también puedes establecer la hora temporalmente, pero con cuidado:
sudo date -s "2026-05-24 10:00:00"
El ajuste manual solo sirve para emergencias temporales. Al final, el servicio NTP debe seguir sincronizando; de lo contrario, volverá a desviarse en unos días.
La sincronización de hora no es "perfeccionismo de operaciones"; afecta directamente al negocio.
Los certificados TLS tienen tiempos Not Before / Not After explícitos. Si la hora del VPS está demasiado adelantada respecto a la hora real, puede considerar que el certificado "aún no es válido"; si está demasiado atrasada, puede considerar que el certificado "ya ha caducado".
Para problemas de renovación y validación de certificados, puedes consultar: Fallo de renovación del certificado Let's Encrypt en el VPS.
cron, systemd timer, scripts de copia de seguridad, renovación de certificados y tareas de informes dependen todos de la hora del sistema. Una zona horaria incorrecta hace que las tareas parezcan ejecutarse "antes/después"; la deriva de hora hace que el comportamiento de las tareas sea más difícil de juzgar.
Los tiempos de caducidad de JWT, OAuth, SAML y Cookie dependen de la hora del servidor. Una diferencia de unos minutos puede provocar:
- Un token recién emitido se considera aún no válido
- El usuario caduca justo después de iniciar sesión
- El código de verificación de autenticación de dos factores no coincide
- Fallo en la validación de la firma de la solicitud API
Una hora inexacta en los registros hace que el análisis posterior de incidentes sea muy doloroso. Especialmente cuando se diagnostican juntos varios VPS, bases de datos, CDN y almacenamiento de objetos, una línea de tiempo desordenada desvía directamente el juicio.
Si estás haciendo un análisis posterior de un incidente, primero asegúrate de que todas las máquinas tengan la hora sincronizada y luego revisa la cadena de registros.
Si tienes varias máquinas, no tengas una en UTC, otra en Asia/Shanghai y otra en la zona horaria predeterminada del proveedor. Como mínimo, unifica lo siguiente:
- Todos los servidores tienen NTP habilitado
- El sistema de registros usa UTC de forma uniforme o registra explícitamente la zona horaria
- El almacenamiento de hora en la capa de aplicación usa UTC de forma uniforme
- Convertir por región solo al mostrarlo al usuario
- Las alertas de monitorización y la documentación de tareas programadas indican claramente qué zona horaria se usa
En arquitecturas de varias máquinas, las diferencias de hora hacen que la replicación de bases de datos, la caducidad de caché, el retraso de colas, los bloqueos distribuidos y los registros de auditoría sean más difíciles de diagnosticar.
Cuando la hora del VPS no es correcta, revisa en este orden:
timedatectlpara ver la zona horaria, el estado de NTP y el estado de sincronización.- Confirma si es un problema de zona horaria o si la hora UTC en sí se ha desviado.
sudo timedatectl set-ntp truepara habilitar NTP.- En Debian / Ubuntu, revisa
systemd-timesyncd. - En RHEL / Rocky / AlmaLinux, revisa
chrony/chronyd. - Usa
chronyc sources -vychronyc trackingpara ver las fuentes de sincronización. - Revisa si DNS y el UDP 123 saliente están disponibles.
- Cuando la desviación de hora es demasiado grande, usa
chronyc makesteppara calibrar primero. - Verifica si HTTPS, cron, los registros, JWT y las marcas de tiempo de la base de datos han vuelto a la normalidad.
- Unifica la zona horaria y la política NTP en varias máquinas.
Cuando la hora del VPS no es correcta, en apariencia date se muestra mal, pero en realidad afecta a certificados, tareas programadas, estado de inicio de sesión, firmas de API, auditoría de registros y marcas de tiempo de la base de datos.
Primero usa timedatectl para distinguir la zona horaria de la deriva de hora, y luego confirma si el servicio NTP realmente está sincronizando. En el diagnóstico de una sola máquina, revisa systemd-timesyncd o chrony; en entornos de varias máquinas, unifica la política de hora. Una vez que la línea de tiempo es correcta, el diagnóstico posterior no se volverá cada vez más confuso.