Tutoriais de VPS
Hora do VPS incorreta (2026): solução de problemas de NTP, chrony, systemd-timesyncd e sincronização de fuso horário
Uma hora incorreta no VPS afeta a validação de certificados, a ordenação de logs, as tarefas agendadas, o estado de sessão JWT/login e os timestamps do banco de dados. As causas comuns incluem configuração incorreta de fuso horário, NTP não habilitado, falhas no chrony ou no systemd-timesyncd, UDP 123 bloqueado e deriva de hora no host de virtualização. Este artigo diagnostica camada por camada usando timedatectl, o serviço NTP, chrony, rede e impacto no negócio.
Quando a hora do VPS está incorreta, parece um problema pequeno, mas na prática pode facilmente desviar a direção do diagnóstico.
O certificado claramente não expirou, mas o programa reporta falha de validação TLS; as tarefas cron "não executam no horário"; a ordem dos logs pula para frente e para trás; JWT, Cookie e login OAuth param de funcionar de repente; os timestamps gravados no banco de dados diferem da hora real em várias horas. Em muitos casos, a causa raiz não é a aplicação estar quebrada, mas sim um problema com a hora do sistema, o fuso horário ou a sincronização NTP.
Este artigo segue uma ordem de diagnóstico: primeiro confirmar a hora e o fuso horário do sistema, depois verificar se o NTP está habilitado e, em seguida, inspecionar separadamente systemd-timesyncd, chrony, a conectividade de rede e o impacto no lado do negócio.
Primeiro veja o estado atual da hora:
timedatectl
Preste atenção nestas linhas:
Local time: ...
Universal time: ...
Time zone: ...
System clock synchronized: yes/no
NTP service: active/inactive
Aqui é preciso distinguir dois problemas:
- O fuso horário não corresponde ao que você espera: por exemplo, o sistema usa UTC, mas você achava que era Asia/Shanghai.
- A hora do sistema em si está incorreta: a hora UTC já difere da hora real em dezenas de segundos, vários minutos ou até horas.
Um fuso horário inconsistente não é necessariamente uma falha. Muitos sistemas de produção usam UTC de forma uniforme, o que na verdade é mais claro. O realmente perigoso é a deriva do relógio do sistema, especialmente quando ultrapassa vários minutos.
Se você está diagnosticando tarefas agendadas, também pode ler este artigo: Tarefas agendadas do VPS que não executam: cron, crontab, systemd timer.
Ver fusos horários disponíveis:
timedatectl list-timezones | grep Shanghai
Configurar o fuso horário de Xangai:
sudo timedatectl set-timezone Asia/Shanghai
Se você prefere usar UTC:
sudo timedatectl set-timezone UTC
Minha recomendação: usar UTC de forma uniforme dentro do servidor e converter para hora local na camada de exibição voltada ao usuário. Mas se sua equipe, o sistema de logs e as janelas de manutenção se comunicam todos no horário de Pequim, usar Asia/Shanghai também é válido; o importante é a consistência em toda a cadeia.
Não confunda "o fuso horário está correto" com "o NTP está corrigido". Alterar o fuso horário afeta apenas a exibição e a interpretação da hora local; não resolve a deriva do relógio do sistema.
Habilitar NTP:
sudo timedatectl set-ntp true
Depois veja o status:
timedatectl status
Se você vir:
System clock synchronized: yes
NTP service: active
isso significa que, no nível do sistema, a sincronização de hora já é considerada normal.
Se aparecer no ou inactive, continue verificando os serviços abaixo. Distribuições diferentes usam componentes de sincronização de hora padrão diferentes:
- Ubuntu / Debian comumente:
systemd-timesyncd - RHEL / Rocky / AlmaLinux comumente:
chronyd - Algumas imagens instalam o tradicional
ntpountpsec
Não habilite vários serviços de sincronização de hora ao mesmo tempo, pois eles podem entrar em conflito entre si.
No Debian / Ubuntu, primeiro verifique:
systemctl status systemd-timesyncd
Se não estiver iniciado:
sudo systemctl enable --now systemd-timesyncd
Ver detalhes da sincronização:
timedatectl timesync-status
As anomalias comuns incluem:
- Nenhum NTP Server disponível
- A rede não consegue acessar a UDP 123
- Falha na resolução DNS
- A defasagem da hora local é muito grande e precisa de uma calibração manual primeiro
Verifique os logs:
journalctl -u systemd-timesyncd --since "2 hours ago"
Se houver problemas de resolução DNS nos logs, você pode consultar: Falha na resolução DNS do VPS.
Muitos servidores são mais adequados ao chrony, especialmente ambientes virtualizados e VPSs onde a hora pode saltar.
Instalar:
sudo apt install chrony -y
Ou:
sudo dnf install chrony -y
Habilitar:
sudo systemctl enable --now chrony
Em alguns sistemas o nome do serviço é chronyd:
sudo systemctl enable --now chronyd
Ver fontes de sincronização:
chronyc sources -v
Ver status de rastreamento:
chronyc tracking
Você deve prestar atenção principalmente em:
- Se há uma fonte de sincronização marcada com
* - Se
Last offsetestá muito grande - Se
Leap statusestá normal - Se
Stratumé razoável
Se todas as fontes estiverem em ^?, isso geralmente indica que as fontes NTP estão inacessíveis ou não respondem.
O NTP usa UDP 123 por padrão. Quando a UDP de saída do VPS está restrita, a sincronização de hora pode falhar continuamente.
Primeiro confirme que o DNS consegue resolver:
getent hosts pool.ntp.org
Depois verifique as regras de firewall:
sudo ufw status
sudo iptables -S
sudo nft list ruleset
Na maioria dos casos, um VPS comum não bloqueia a UDP 123 de saída. Mas alguns firewalls de nuvem, grupos de segurança, políticas de rede corporativas ou regras de firewall em imagens mínimas podem bloquear.
Se você usa regras de firewall próprias, primeiro permita a UDP 123 de saída e depois reinicie o serviço de sincronização:
sudo systemctl restart systemd-timesyncd
sudo systemctl restart chrony
Reinicie apenas o serviço que você realmente está usando.
Se a hora do sistema estiver muito diferente, o serviço NTP às vezes não a corrige suavemente de imediato. Você pode calibrar manualmente primeiro e depois deixar o NTP mantê-la.
Usando chrony:
sudo chronyc makestep
Depois veja:
chronyc tracking
timedatectl
Se você não tiver chrony, também pode definir a hora temporariamente, mas com cuidado:
sudo date -s "2026-05-24 10:00:00"
A configuração manual serve apenas para emergências temporárias. No final, o serviço NTP ainda precisa continuar sincronizando; caso contrário, voltará a derivar em alguns dias.
A sincronização de hora não é "perfeccionismo de operações"; ela afeta diretamente o negócio.
Os certificados TLS têm horários explícitos de Not Before / Not After. Se a hora do VPS estiver muito adiantada em relação à hora real, ele pode considerar que o certificado "ainda não é válido"; se estiver muito atrasada, pode considerar que o certificado "já expirou".
Para problemas de renovação e validação de certificados, você pode consultar: Falha na renovação do certificado Let's Encrypt no VPS.
cron, systemd timer, scripts de backup, renovação de certificados e tarefas de relatórios dependem todos da hora do sistema. Um fuso horário errado faz as tarefas parecerem executar "antes/depois"; a deriva de hora torna o comportamento das tarefas mais difícil de avaliar.
Os tempos de expiração de JWT, OAuth, SAML e Cookie dependem da hora do servidor. Uma diferença de alguns minutos pode causar:
- Um token recém-emitido ser considerado ainda não válido
- O usuário expirar logo após fazer login
- O código de verificação de autenticação de dois fatores não corresponder
- Falha na validação da assinatura da requisição API
Uma hora incorreta nos logs torna a análise pós-incidente muito dolorosa. Especialmente ao diagnosticar juntos vários VPSs, bancos de dados, CDNs e armazenamento de objetos, uma linha do tempo desordenada desvia diretamente o julgamento.
Se você está fazendo uma análise pós-incidente, primeiro garanta que todas as máquinas tenham a hora sincronizada e depois analise a cadeia de logs.
Se você tem várias máquinas, não deixe uma em UTC, outra em Asia/Shanghai e outra no fuso horário padrão do provedor. No mínimo, unifique o seguinte:
- Todos os servidores com NTP habilitado
- O sistema de logs usando UTC de forma uniforme ou registrando explicitamente o fuso horário
- O armazenamento de hora na camada de aplicação usando UTC de forma uniforme
- Converter por região apenas ao exibir para o usuário
- Alertas de monitoramento e documentação de tarefas agendadas indicando claramente qual fuso horário é usado
Em arquiteturas com várias máquinas, diferenças de hora tornam a replicação de banco de dados, a expiração de cache, o atraso de filas, os locks distribuídos e os logs de auditoria mais difíceis de diagnosticar.
Quando a hora do VPS está incorreta, verifique nesta ordem:
timedatectlpara ver o fuso horário, o status do NTP e o status de sincronização.- Confirme se é um problema de fuso horário ou se a hora UTC em si derivou.
sudo timedatectl set-ntp truepara habilitar o NTP.- No Debian / Ubuntu, verifique
systemd-timesyncd. - No RHEL / Rocky / AlmaLinux, verifique
chrony/chronyd. - Use
chronyc sources -vechronyc trackingpara ver as fontes de sincronização. - Verifique se o DNS e a UDP 123 de saída estão disponíveis.
- Quando a defasagem de hora for muito grande, use
chronyc makesteppara calibrar primeiro. - Verifique se HTTPS, cron, logs, JWT e timestamps do banco de dados voltaram ao normal.
- Unifique o fuso horário e a política NTP em várias máquinas.
Quando a hora do VPS está incorreta, na aparência date está exibindo errado, mas na prática afeta certificados, tarefas agendadas, estado de login, assinaturas de API, auditoria de logs e timestamps do banco de dados.
Primeiro use timedatectl para distinguir o fuso horário da deriva de hora e depois confirme se o serviço NTP está realmente sincronizando. No diagnóstico de uma única máquina, verifique systemd-timesyncd ou chrony; em ambientes com várias máquinas, unifique a política de hora. Com a linha do tempo correta, o diagnóstico posterior não ficará cada vez mais confuso.