サーバー時刻チェッカー
入力したサイトのサーバー時刻をms単位でリアルタイム表示
確認したいサイトのアドレスを入力すると、そのサイトのサーバー時刻をミリ秒単位でできるだけ正確にリアルタイム表示します。先着順の予約や受講申込みなど、正確なタイミングが必要な場面で便利です。
ブラウザは他サイトの正確な時刻を直接読み取れないため(CORS制限)、入力されたアドレスに弊社サーバーが代わりに一度だけリクエストして時刻情報のみ確認します — それ以外は何も保存しません。
使い方
- 確認したいサイトのアドレスを入力し、確認を押すとそのサイトのサーバー時刻が表示されます。
- 毎分切り替わる5秒前から黄色、2秒前から赤色で強調表示され、正確な瞬間に一瞬点滅します。
- PIPボタンを押すと小さなウィンドウで表示され、他のタブやアプリを見ながらでも時計を確認できます(デスクトップ Chrome・Edge、Android Chrome)。ブラウザがPIPを拒否した場合は、画面が消えない全画面の大きな時計に自動で切り替わります — iPhone Safari は通常こちらになります。
- 長時間表示していても誤差が蓄積しないよう60秒ごとに時計を合わせ直し(補正時は下に「補正しました」が一瞬表示されます)、3分ごとに対象サイトの時刻を測定し直します。補正は数字が飛ばないよう1.5秒かけて反映されます。
- 表示される精度(±ms)は対象サイトやネットワーク状況によって変わります。CDNキャッシュを使うサイトは誤差が大きくなることがあります。
処理中…
0.0
停止していません。計算が終わると結果が表示されます。
サーバー時刻チェッカーについて
このツールは、入力したサイトのサーバーが認識している「今」をミリ秒単位で表示します。根拠はWebサーバーがすべてのHTTPレスポンスに付けるDateヘッダーだけです。このヘッダーは秒単位(例:Tue, 22 Sep 2026 11:00:02 GMT)なので、ツールはリクエストを重ねて送り、秒が切り替わる瞬間を絞り込むことでミリ秒レベルのオフセットを推定し、その信頼度を±誤差で示します。
チケットの先着販売、大学の履修登録、限定品の抽選応募のように決まった時刻に開くページでは、自分のPCではなくそのサーバーの時計が基準です。以下では、ツールが実際に何を測り、ネットワーク遅延をどう差し引き、表示をどこまで信じてよいかを説明します。
ブラウザで直接測らず中継サーバーを使う理由
ブラウザのスクリプトから別サイトへリクエストしても、CORSの規則で読めるレスポンスヘッダーは一部に限られます。Dateはその一覧になく、サイト側が明示的に公開しない限り(ほぼ公開されません)ページからは見えません。そこでこのツールはCloudflare Workerからサーバー間でHEADリクエスト(拒否されたらGET)を送り、Dateヘッダーだけを読み取ります。キャッシュされた応答が混ざりにくいようno-cacheを付け、プライベートアドレスやループバックには送りません。
秒単位のヘッダーからミリ秒を取り出す
Workerは毎回、送信直前の時刻sと応答受信時刻rを自分の時計で記録します。対象サーバーがDateを付けた瞬間は必ずsとrの間にあり、その瞬間の本当の時刻はDateの値dからd+1秒の間です。したがってオフセット(対象の時計−Workerの時計)は[d − r, d + 1000 − s]の区間に入ります。何度も測ってこの区間の共通部分を取ると幅が狭まり、その幅の半分が誤差半径になります。NTPが複数の標本を扱うのと同じ考え方です。
測定は2段階です。まず約110ミリ秒間隔で最大8回送って秒の境界をおおまかに挟み、次に推定した境界付近へ最大5回を重ねて送り、さらに絞ります。1回の測定で対象へ送るのは最大13回です。区間が重ならなければ(キャッシュされたDateが混ざった場合)値を信用できないと判断し、±1秒精度で表示します。
販売開始直前に同じサイトへ人が集中すると、測定結果を約30秒間複数の利用者で共有します。保存しているのは絶対時刻ではなく2つの時計の差なので、少し再利用しても精度はほとんど変わらず、ツールは再利用した時間ぶんのドリフト余裕を誤差に加えています。
自分の端末までの遅延は別に補正する
ここまでで分かるのは「Workerの時計に対する対象の時計」です。画面に表示するには「自分のブラウザに対するWorkerの時計」も必要で、これは軽い同期リクエストで別に測ります。往復時間の中間でWorkerが時計を読んだとみなし、複数の標本のうち往復が最も短いものを採用します。往復が短いほど途中の待ち行列で待った時間が少ないので、平均より最小値のほうが正確です。
画面の±は、対象の測定誤差にこの往復時間の半分を足したものです。時計は60秒ごとに再同期し、3分ごとに対象を測り直します。0.4秒未満の補正は1.5秒かけて少しずつ反映し、数字が逆戻りしないようにしています。
正確に合わせても先着が保証されない理由
それでも役に立つのは、数秒ずれていることも珍しくないPCやスマートフォンの時計を基準にしてしまう失敗をなくせるからです。「この端末の時計より0.482秒進んでいます」といった表示がその差で、50ミリ秒未満は一致として表示します。
- 測っているサーバーが判定するサーバーとは限りません。販売サイトの入口はCDNやWebサーバーが応答し、実際の座席確保は別のサーバーが行います。通常は同じくNTPで同期していて差は小さいものの、ツールが保証するのは入力したアドレスのDateヘッダーまでです。販売ページと同じドメインを入れてください。
- ボタンを押してからリクエストがサーバーに届くまでにも時間がかかります。国内なら通常数十ミリ秒ですが、Wi-Fiの状態や端末の負荷で変わります。
- 多くの販売サイトは開始時刻に待合室(キュー)を設けており、順番が到着時刻だけで決まるとは限りません。早く押しすぎると「開始前」のページが出て、再読み込みの間にかえって遅れることもあります。
- 誤差半径が±100ミリ秒なら、本当の時刻はその幅のどこかです。最後の桁まで信じず、余裕を持ってください。
例
共通部分でオフセットを絞る
- 入力
probe1:s=.300、r=.380、Date=:01/probe2:s=.480、r=.540、Date=:02/probe3:s=.430、r=.500、Date=:01(Workerの時計、10:00:00台)- 結果
[+620, +1700] ∩ [+1460, +2520] ∩ [+500, +1570] = [+1460, +1570] → 対象は1.515秒進んでいる、±55ミリ秒
probe2はすでに:02、少し前に送ったprobe3はまだ:01だったため、秒の境界が110ミリ秒の幅に絞られました。
画面の誤差半径
- 入力
対象測定±55ミリ秒、ブラウザ↔Workerの最短往復40ミリ秒- 結果
±75ミリ秒
55 + 40/2 = 75。モバイル回線のように往復が長いと大きくなります。
PCの時計との差
- 入力
サーバー10:00:00.000のときPCは09:59:58.700- 結果
「この端末の時計より1.300秒進んでいます」
PCの時計で10:00:00に押すと、実際には1.3秒遅れて押したことになります。
使い方
- チケットや履修登録のページと同じドメインを入力します(https://は省略可)。
- 時計が動き始めたら、±誤差と自分の時計との差を確認します。
- PIPで表示したまま販売ページを開き、毎分0秒前後の色の変化を目安に押します。
よくある質問
NICTの時報や時計サイトと何が違いますか?
時報は国の標準時、このツールは入力したサイトのサーバーの時計です。多くのサーバーはNTPで標準時に合わせてあり近い値ですが、判定はそのサーバー基準なので直接測るほうが確実です。
±誤差が大きく出ます。
モバイル回線や混雑したWi-Fiでは往復時間が長く、誤差が広がります。しばらく開いておくと、より狭い測定値が得られたときに切り替わります。
±1秒精度でしか表示されません。
対象がキャッシュされた応答や一貫しないDateヘッダーを返しているため、秒の境界を絞り込めません。同じドメインの別ページを試してください。
何秒前に押せばいいですか?
サイトによります。開始前のリクエストを拒否するなら開始直後、待合室があるなら開始時刻ちょうどが一般的です。ツールが示せるのはサーバーの時刻までです。
出典
- RFC 9110 – HTTP Semantics, §6.6.1 Date
- Fetch Standard – CORS-safelisted response header name
- RFC 5905 – Network Time Protocol Version 4
基準日: