Qué es una comprobación de drift NTP
Una comprobación de drift NTP mide la diferencia entre el reloj de tu ordenador, el de nuestro servidor y cuatro servidores NTP públicos. Nuestro servidor envía un pequeño paquete UDP a cada uno por el puerto 123, lee los timestamps y calcula el offset (cuántos milisegundos se desvía tu reloj) y el retardo de ida y vuelta.
Obtienes una vista con la hora de tu máquina, la hora de nuestro servidor, la hora de referencia NTP y un gráfico de barras con la deriva por servidor. No hay nada que instalar, no hace falta admin: recargas la página y listo.
Cómo se usa
- Abre la herramienta. En segundos verás tres cifras grandes: hora de tu ordenador, hora de nuestro servidor y hora de referencia NTP (mediana de los cuatro servidores).
- Debajo obtienes dos lecturas: tu ordenador frente a NTP y nuestro servidor frente a NTP. Un valor positivo significa que tu reloj va más lento que el NTP. Negativo = más rápido.
- A la derecha tienes un gráfico de barras con el drift por servidor (pool.ntp.org, time.cloudflare.com, time.google.com, time.windows.com). Útil para confirmar que coinciden entre sí.
- Activa autorefresco cada 10 segundos con el interruptor de arriba. Desactivado significa medición única, igual que pulsar "Actualizar".
- Si un servidor reporta error: timeout, no respondió en 3 segundos. Suele ser un filtro UDP en la ruta. Los otros tres siguen dando una imagen útil.
- La columna "stratum" muestra cuán cerca de la fuente está ese servidor. 1 = reloj atómico o GPS, 2 = un servidor que consulta a un stratum 1, y así. Cuanto menor el número, más autoridad.
Cuándo es útil
Seis situaciones en las que el drift de reloj duele de verdad:
- TOTP / 2FA falla ("código inválido" pese al secreto correcto) porque el reloj del móvil o el servidor se desvió más de 30 segundos. Ves al instante si el problema es tuyo.
- Certificados TLS marcados como inválidos o "aún no válidos" porque el reloj del servidor va minutos desviado en cualquier dirección y todo se rompe.
- Correlación de logs entre microservicios: si cada nodo tiene una deriva distinta, los eventos en Grafana y Loki se alinean en orden equivocado y depurar se vuelve adivinanza.
- Kerberos / Active Directory rechaza tickets cuando la diferencia entre cliente y controlador de dominio supera 5 minutos (la tolerancia por defecto).
- Bases de datos multi-master (Cassandra, ScyllaDB, CockroachDB) usan timestamps para resolver conflictos de escritura: un reloj malo significa last-write-wins con la escritura equivocada.
- Smart contracts y RPCs blockchain suelen validar que block.timestamp sea razonable respecto a ahora. Reloj mal en tu nodo = transacciones rechazadas.
Relacionadas: reloj mundial, conversor de zonas horarias, Unix timestamp, DNS lookup.
Preguntas frecuentes
Network Time Protocol es un protocolo de 1985 (RFC 5905) que permite a los ordenadores sincronizar su reloj por red con precisión de milisegundos en una LAN y de unas decenas de ms por internet. El cliente envía un pequeño paquete UDP a un servidor NTP, el servidor responde con timestamps y el cliente calcula offset y retardo. Todo tu sistema operativo corre un cliente NTP en segundo plano: en Windows es W32Time, en Linux normalmente chrony o systemd-timesyncd, en macOS timed.