Verificador de Hora del Servidor

Muestra la hora del servidor de un sitio en vivo, al milisegundo

Introduce la dirección del sitio que quieres comprobar y verás su hora de servidor en vivo, con la mayor precisión posible en milisegundos. Útil para acertar el instante exacto en que se abre una venta o inscripción limitada.

Los navegadores no pueden leer directamente la hora exacta de otro sitio (restricciones CORS), así que nuestro servidor hace una sola solicitud a la dirección indicada solo para leer su hora — no se guarda nada más.

Cómo usarlo

  • Introduce la dirección del sitio y pulsa Comprobar para ver su hora de servidor.
  • La pantalla se pone ámbar en los últimos 5 segundos de cada minuto, roja en los últimos 2, y parpadea brevemente al dar la vuelta el minuto.
  • Pulsa Abrir en PIP para flotar el reloj en una ventana pequeña mientras usas otras pestañas o apps (Chrome/Edge de escritorio y Chrome para Android). Si el navegador rechaza PiP, pasa automáticamente a un reloj a pantalla completa que mantiene la pantalla encendida — lo habitual en Safari de iPhone.
  • Para que no se acumule desviación, el reloj se vuelve a sincronizar cada 60 segundos (aparece brevemente "corregido" debajo) y remide por completo el sitio objetivo cada 3 minutos. Las correcciones se aplican de forma gradual durante 1,5 segundos para que los dígitos no salten.
  • La precisión mostrada (±ms) depende del sitio y de la red — los sitios detrás de una caché CDN pueden mostrar un error mayor.

Acerca de Verificador de Hora del Servidor

Esta herramienta muestra, al milisegundo, qué hora cree tener el servidor de la dirección que escribes. Su única prueba es la cabecera Date que los servidores web añaden a cada respuesta HTTP. Esa cabecera tiene resolución de un segundo (Tue, 22 Sep 2026 11:00:02 GMT), así que la herramienta lanza peticiones solapadas para cazar el instante en que cambia el segundo, estima el desfase con precisión de milisegundos y muestra un ± que indica cuánto puedes fiarte.

Está pensada para páginas que abren a una hora exacta —entradas de conciertos, lanzamientos de zapatillas, matrícula universitaria— donde manda el reloj del servidor, no el tuyo. A continuación: qué mide de verdad, cómo descuenta el retardo de la red y hasta dónde puedes creerte la cifra.

Por qué la medición pasa por un intermediario

Cuando un script del navegador llama a otro sitio, las reglas CORS solo le dejan leer una lista corta de cabeceras de respuesta. Date no está en ella, así que salvo que el sitio la exponga expresamente (casi ninguno lo hace), una página web no puede verla. Por eso la herramienta pide a un Cloudflare Worker que haga peticiones HEAD de servidor a servidor (GET si HEAD se rechaza) y devuelva solo el valor de Date. Las peticiones llevan cabeceras no-cache para evitar respuestas cacheadas, y se rechazan direcciones privadas o de loopback.

Sacar milisegundos de una cabecera de un segundo

En cada sondeo el Worker anota, con su propio reloj, el instante s justo antes de enviar y r al recibir la respuesta. El servidor puso la fecha en algún momento entre s y r, y en ese momento su hora real estaba entre el valor d de la cabecera y d + 1 segundo. Por tanto, el desfase (reloj del destino menos reloj del Worker) está en el intervalo [d − r, d + 1000 − s]. Cada sondeo añade otro intervalo; al intersecarlos el rango se estrecha y la mitad de su anchura es la incertidumbre. Es el mismo razonamiento por intervalos que usa NTP al combinar muestras.

La medición tiene dos fases: hasta ocho sondeos separados unos 110 ms para acotar el cambio de segundo, y luego hasta cinco sondeos solapados alrededor del cambio estimado para afinarlo. Son como máximo 13 peticiones al destino por medición. Si los intervalos no se cruzan, señal de que se coló una Date cacheada, la herramienta sabe que los datos no cuadran y vuelve a precisión de un segundo.

En el último minuto antes de una venta masiva, mucha gente consulta el mismo sitio. El Worker comparte una medición entre usuarios durante unos 30 segundos. Como lo que guarda es la diferencia entre dos relojes sincronizados por NTP y no una hora absoluta, reutilizarla apenas cuesta precisión, y aun así se suma un margen de deriva según su antigüedad.

Tu propio retardo se mide aparte

Lo anterior da el reloj del destino respecto al Worker. Para dibujar el reloj en tu navegador hace falta además el del Worker respecto al tuyo, que se obtiene con peticiones de sincronización ligeras. Se supone que el Worker leyó su reloj a mitad del viaje de ida y vuelta y, entre varias muestras, se queda con la de ida y vuelta más corta: cuanto más corta, menos tiempo pasó en colas por el camino, así que el mínimo es mucho más fiable que la media.

El ± de la pantalla es la incertidumbre del destino más la mitad de esa ida y vuelta. El reloj se resincroniza cada 60 segundos y vuelve a medir el destino cada tres minutos. Las correcciones de menos de 0,4 segundos se aplican poco a poco durante 1,5 segundos para que los dígitos nunca retrocedan.

Por qué un reloj perfecto no garantiza ser el primero

Lo que sí aporta es evitar un error muy común: guiarse por el reloj del móvil o del ordenador, que puede ir un segundo o más desviado. La línea «0,482s por delante del reloj de este dispositivo» muestra justo esa diferencia; por debajo de 50 ms se muestra como coincidente. Más allá de eso, hay cosas que ningún reloj controla.

  • El servidor que mides puede no ser el que decide. La portada de una ticketera suele servirla una CDN o un servidor web, y las butacas las asigna otro sistema. Normalmente están sincronizados por NTP y muy cerca, pero la herramienta solo responde de la cabecera Date de la dirección que escribes: usa el mismo dominio que la página de venta.
  • Tu clic también tiene que viajar. Dentro de un mismo país suelen ser decenas de milisegundos, según el Wi-Fi y la carga del dispositivo.
  • Muchas ventas ponen una sala de espera delante, y el puesto en la cola no siempre depende solo de la hora de llegada. Pulsar antes de tiempo suele devolver una página de «todavía no está abierto» y recargar puede costar más de lo ganado.
  • Una incertidumbre de ±100 ms significa que la hora real está en esa franja. Deja margen en lugar de fiarte del último dígito.

Ejemplos

Acotar el desfase por intersección

Entrada
sondeo1: s=.300, r=.380, Date=:01 · sondeo2: s=.480, r=.540, Date=:02 · sondeo3: s=.430, r=.500, Date=:01 (reloj del Worker, todos a las 10:00:00)
Resultado
[+620, +1700] ∩ [+1460, +2520] ∩ [+500, +1570] = [+1460, +1570] → el destino va 1,515 s adelantado, ±55 ms

El sondeo 2 ya vio :02 y el 3, enviado un poco antes, aún vio :01: el cambio de segundo queda encerrado en 110 ms.

Qué significa el ± de la pantalla

Entrada
Medición del destino ±55 ms; mejor ida y vuelta navegador↔Worker 40 ms
Resultado
±75 ms

55 + 40/2 = 75. Con datos móviles congestionados, la ida y vuelta y el ± crecen.

Tu reloj frente al servidor

Entrada
Servidor 10:00:00.000 mientras el portátil marca 09:59:58.700
Resultado
«1,300s por delante del reloj de este dispositivo»

Pulsar cuando el portátil marca las 10:00:00 sería en realidad 1,3 segundos tarde.

Cómo se usa

  1. Escribe el mismo dominio que la página de venta o matrícula (https:// opcional).
  2. Cuando el reloj arranque, fíjate en el ± y en la diferencia con tu propio reloj.
  3. Ponlo en imagen dentro de imagen junto a la página de venta y guíate por el cambio de color al final de cada minuto.

Preguntas frecuentes

¿En qué se diferencia de la hora oficial del Real Instituto y Observatorio de la Armada o de time.is?

Esas muestran la hora oficial; esta muestra el reloj del sitio que escribes. La mayoría de servidores se sincronizan por NTP y van muy cerca, pero decide el reloj del propio sitio, así que medirlo directamente elimina dudas.

¿Por qué el ± es tan grande?

Idas y vueltas largas o irregulares, típicas de datos móviles o Wi-Fi saturado, lo ensanchan. Déjala abierta: cambia a una medición más precisa cuando llega una.

Solo muestra precisión de un segundo.

El destino devolvió cabeceras Date cacheadas o incoherentes y no se pudo acotar el cambio de segundo. Prueba otra página del mismo dominio, como la de inicio de sesión.

¿Con cuánta antelación debo pulsar?

Depende del sitio. Si rechaza peticiones antes de abrir, justo después de la hora; si hay sala de espera, a la hora exacta. La herramienta solo puede decirte la hora del servidor.

Fuentes

Revisado el:

Privacidad y tratamiento de datos