chronyは、LinuxなどのUnix系OSで時刻をNTPサーバーに合わせるためのオープンソースのソフトウェアです。常駐するデーモンのchronydと、状態を確かめる操作用コマンドのchronycの2つで構成され、2026年8月27日に4.9が公開されました。RHEL系やAmazon Linux 2023では標準の時刻同期デーモンで、Ubuntuも25.10から既定をchronyへ切り替えています。
この記事では、chrony.confの主要な行の意味、chronyc sourcesとchronyc trackingの読み方、AWS EC2でAmazon Time Sync Serviceへ向ける設定を、コピーして動かせる形で扱います。後半では、NTSとうるう秒の扱いで詰まる箇所と、サーバー構築で設定を標準化すべき条件を示します。
まとめ：chronyの導入前に決める同期先・ステップ補正・確認コマンド
先に結論です。同期先はクラウド上ならそのクラウドのリンクローカルな時刻源、オンプレミスなら社内NTPサーバーか公開NTPを2〜4台指定し、起動直後の大きなずれだけをmakestepで一気に直す設定にしてください。あとはchronyc trackingのSystem timeを監視に載せれば、運用で困る場面はほぼ防げます。
- 構成：chronydが時刻を合わせ、chronycが状態を表示・操作する。設定ファイルはRHEL系が
/etc/chrony.conf、Ubuntu系が/etc/chrony/chrony.conf - 同期先：AWS EC2は
169.254.169.123をpreferで1行追加する。外部への通信が無いサブネットでも届く - 補正方式：通常は時計を少しずつ進め遅らせる「スルー」で直し、
makestep 1 3で起動直後の1秒超のずれだけ即時に合わせる - 確認：
chronyc sourcesで^*の行と到達率377を見て、chronyc trackingでずれの量を読む - 詰まる箇所：Ubuntu 25.10以降のNTS既定は4460/tcpを使う。うるう秒をスミアする時刻源とスミアしない時刻源を混ぜない
chronyとはchronydとchronycで構成されるLinuxのNTP実装
サーバーの時計は、放っておくと水晶発振子の個体差や温度で1日あたり数百ミリ秒から1秒程度ずれていきます。NTP（Network Time Protocol）は、ネットワーク越しに正確な時刻を持つサーバーへ問い合わせ、その差を少しずつ打ち消す仕組みです。chronyはこのNTPを実装したソフトウェアで、GitLabで開発され、GNU GPL v2で配布されています。
役割は2つのプログラムに分かれています。chronydはOS起動時から常駐し、NTPサーバーとの通信と時計の補正を受け持つデーモンです。chronycは管理者が打つコマンドで、同期先の一覧や現在のずれを表示し、設定の再読み込みなども実行できます。Linuxのサービス管理の中でどう常駐するかは、Linuxの仕組みとサーバー用途を扱った解説とあわせて読むと位置づけがつかめます。
ntpdやsystemd-timesyncdとの違いと主要ディストリの既定
chronyの前は、NTPの参照実装であるntpdが長く使われてきました。公式FAQは、chronyを「より幅広い条件で動くよう設計され、通常はより速く同期し精度も高い」と説明しています。ネットワークが途切れがちな環境や、停止と再開を繰り返す仮想マシンで差が出る設計です。
もう1つの比較対象がsystemd-timesyncdです。systemdに同梱された軽量なクライアントで、時刻を受け取ることはできますが、他のマシンへ時刻を配ることはできません。サービス管理の土台であるsystemdの役割をまとめた記事のとおり、timesyncdは「最低限合っていればよい」端末向けの部品です。
| 項目 | chrony | ntpd | systemd-timesyncd |
|---|---|---|---|
| 時刻の配信 | できる | できる | できない |
| NTS（暗号化認証） | 対応 | 非対応 | 非対応 |
| 主な採用先 | RHEL系 AL2023 Ubuntu 25.10以降 |
旧来の環境 | Ubuntu 25.04以前など |
Ubuntuのドキュメントは、25.10からchronyを既定にしたと明記したうえで、25.04以前からアップグレードした環境ではtimesyncdが動いたままの場合があると注意しています。同じUbuntuでも、新規構築とアップグレードで時刻同期の担い手が違う点は、構築手順書に書き分けておく必要があります。
2026年8月公開の4.9系までに加わったNTSと権限分離の機能
最新の4.9では、OpenBSDへの対応と、NTPをPTPの上で運ぶ機能をRFC 10030の最終仕様に合わせる変更が入りました。1つ前の4.8（2025年8月27日公開）では、到達できない時刻源の選択を制限するmaxunreachオプションと、chronycをroot権限なしで動かす-uオプションが追加されています。
業務サーバーで押さえるべき機能はNTSです。RFC 8915で規格化されたNetwork Time Securityの略で、NTPの応答が本物のサーバーから来たことを暗号で確かめられます。従来のNTPは応答の偽装を防ぐ手段が弱く、時刻をずらされると証明書の有効期限判定やログの前後関係が崩れます。インターネット上の公開NTPを使う構成なら、NTS対応の時刻源を選ぶのが現在の標準です。
chrony.confでNTPサーバーを指定しchronydを起動する手順
導入はディストリビューションのパッケージで完結します。RHEL系やAmazon Linuxでは最初から入っていることが多く、Ubuntu 25.04以前ではaptで追加します。
# RHEL系・Amazon Linux 2023
sudo dnf install -y chrony
sudo systemctl enable --now chronyd
# Ubuntu・Debian系（サービス名は chrony）
sudo apt update
sudo apt install -y chrony
sudo systemctl enable --now chrony
# 版と同期状態を確かめる
chronyc -v
chronyc trackingサービス名がRHEL系はchronyd、Ubuntu系はchronyと異なる点に注意してください。Ansibleなどで両方の系統をまとめて扱うときは、ここを変数に分けておかないとタスクが片方で失敗します。
RHEL系とUbuntu系で異なる設定ファイルの場所と再読み込み
設定ファイルの場所も系統で分かれます。RHEL系とAmazon Linuxは/etc/chrony.confの1ファイルです。Ubuntuの手順書によると、Ubuntu系は本体が/etc/chrony/chrony.confで、同期先は/etc/chrony/sources.d/、追加設定は/etc/chrony/conf.d/に分けて置く構成です。
同期先だけを差し替えるなら、Ubuntu系ではsources.dにファイルを置き、sudo chronyc reload sourcesでデーモンを止めずに反映できます。makestepなど本体の設定を変えた場合はsystemctl restartが必要です。構成管理ツールで配るなら、本体は触らずsources.dとconf.dにファイルを足す方式にすると、パッケージ更新時の設定ファイル衝突を避けられます。
pool・server・iburst・makestepの意味と書き換える行
実務で書き換えるのは、同期先の行と補正方式の行がほとんどです。次は社内NTPサーバー2台と公開NTPを組み合わせた例です。
# /etc/chrony.conf（RHEL系の例）
# 社内NTPサーバーを優先し、外部の公開NTPを予備にする
server ntp1.example.internal iburst prefer
server ntp2.example.internal iburst
pool ntp.nict.jp iburst maxsources 2
# 起動直後の3回の更新に限り、1秒を超えるずれは即時に合わせる
makestep 1 3
# 周波数のくせを保存し、再起動後の収束を早める
driftfile /var/lib/chrony/drift
# ハードウェアクロック（RTC）にも定期的に書き戻す
rtcsyncserverは1台のサーバーを、poolはDNSで複数のアドレスが返る名前を指定する行です。chrony.confのリファレンスによると、poolから使うサーバー数を決めるmaxsourcesの既定は4、上限は16です。iburstを付けると起動時に4〜8回の問い合わせをまとめて送り、最初の補正が早まります。問い合わせ間隔の既定は最短64秒（minpoll 6）、最長1024秒（maxpoll 10）です。
makestepは補正方式を決める行です。chronydは通常、時計を少しずつ速めたり遅らせたりする「スルー」で合わせ、時刻を巻き戻しません。ただし起動直後に数分ずれていると、スルーでは追いつくまで長くかかります。公式FAQが推奨するmakestep 1 3は、最初の3回の更新で1秒を超えるずれがあれば時刻を飛ばして合わせる指定です。運用中に時刻が飛ぶとログの順序やタイマーが乱れるため、回数の制限は外さないでください。ntp.nict.jpはNICTの公開NTPで、利用者側の精度はネットワーク環境により数ミリ秒から数百ミリ秒まで変わると案内されています。
chronyc sourcesとtrackingの出力から同期状態を読む方法
設定を入れたら、同期できているかを2つのコマンドで確かめます。-Nを付けると、逆引きしたホスト名ではなく設定に書いた名前で表示されるため、どの行がどの設定に対応するかを読み取りやすくなります。
$ chronyc -N sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp1.example.internal 2 6 377 35 -120us[ -151us] +/- 2ms
^+ ntp2.example.internal 2 6 377 34 +310us[ +310us] +/- 3ms
^- ntp.nict.jp 1 6 377 33 +1204us[+1204us] +/- 12ms
$ chronyc tracking
Reference ID : 0A000A01 (ntp1.example.internal)
Stratum : 3
System time : 0.000081204 seconds slow of NTP time
Last offset : -0.000031022 seconds
Leap status : Normal上の出力は読み方の説明用に値を置いた例です。自分の環境では、^*の行があるか、Reachが377か、System timeが何秒かの3点を見れば足ります。
sourcesの記号と到達率377が示す同期の健全性と確認の観点
先頭の2文字は、1文字目が接続方式、2文字目が選択状態です。chronycのマニュアルによると、^はサーバー、#はローカルの参照クロックを表します。2文字目の意味は次のとおりです。
*：いま同期に使っている最良の時刻源。この行が1本も無ければ同期できていない+：最良の時刻源と組み合わせて使われている時刻源-：候補としては有効だが、今は使われていない時刻源?：到達できないなどの理由で使えない時刻源。設定直後やファイアウォールで遮断されているときに出るxと~：他と食い違う、またはばらつきが大きすぎると判定された時刻源
Reachは直近8回の問い合わせに応答があったかを8進数で表した値で、377なら8回とも応答ありです。設定直後は1、3、7、17と増えていき、377で落ち着きます。377にならず途中の値を行き来するなら、パケットの取りこぼしを疑ってネットワーク経路を調べます。
trackingのSystem timeで監視の閾値を決める考え方
chronyc trackingのSystem timeは、chronydが正しいと考える時刻とOSの時計との差です。Leap statusが「Not synchronised」なら同期が外れています。監視に載せるなら、この2項目を定期的に取得してしきい値を超えたら通知する形が簡単です。
しきい値はシステムの要件から逆算して決めてください。ワンタイムパスワード（TOTP）は30秒刻みでコードが変わり、Kerberos認証は既定で5分を超える時刻差を拒否します。これらを使うシステムでは、数秒のずれでも認証失敗として表に出るという問題があります。一般的なWebシステムなら0.1秒、分散データベースやログの突き合わせを厳密に行うシステムならミリ秒単位を目安に置き、外部からの死活確認と組み合わせてください。監視項目の分担は外形監視と内部監視の違いを整理した記事で扱っています。
AWS EC2でAmazon Time Sync Serviceへ同期させる設定
EC2では、インターネット上の公開NTPではなく、AWSが各インスタンスに用意している時刻源へ向けるのが基本です。EC2ユーザーガイドによると、Amazon Time Sync ServiceにはリンクローカルアドレスのIPv4 169.254.169.123で届き、VPCの設定を変えずに使えます。IPv6のfd00:ec2::123はNitroベースのインスタンスでのみ使えます。
169.254.169.123をpreferで指定する1行とIPv6の扱い
AL2023と最近のAmazon Linux 2は、最初からこの時刻源を使う設定です。UbuntuやRHELのAMIでは、既存のserverやpoolの行より前に次の1行を足します。
# Ubuntu系は /etc/chrony/chrony.conf、RHEL系は /etc/chrony.conf
server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4
# 反映して確認する（^* が 169.254.169.123 なら完了）
sudo systemctl restart chrony # RHEL系は chronyd
chronyc sources -v | grep -F '^*'minpoll 4 maxpoll 4は16秒ごとに問い合わせる指定です。リンクローカルの時刻源は経路が短く、頻繁に聞いても負荷が問題になりません。ただしガイドには、リンクローカルアドレス宛ての通信はDNSの問い合わせやインスタンスメタデータの取得と合算して毎秒1024パケットまでという制限が書かれています。IPv4とIPv6の両方を書いても精度は上がらないと明記されているため、どちらか一方にします。
Ubuntu 25.10以降のNTS既定が閉じたサブネットで失敗する理由
Ubuntu 25.10以降を新規に入れると、同期先はsources.d/ubuntu-ntp-pools.sourcesに次のように書かれています。
pool 1.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool 2.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool 3.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool 4.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool ntp-bootstrap.ubuntu.com iburst maxsources 1 nts certset 1ntsが付いた時刻源は、時刻の問い合わせ（123/udp）の前に鍵交換を4460/tcpで行います。Ubuntuの手順書にある注意点は、このポートが塞がれているとchronyが時刻を合わせられないことです。NATゲートウェイを持たないプライベートサブネットや、外向き通信を許可リストで絞ったセキュリティグループでは、この鍵交換が通らず、chronyc sourcesが?だけになります。
EC2ではNTSの外部プールを使う理由がほぼありません。前の見出しの1行をsources.dに別ファイルで置き、ubuntu-ntp-pools.sourcesの行はコメントアウトしてください。リンクローカルの時刻源はVPCの外へ出ないため、偽装の心配も外部NTPより小さくなります。NTSが確立しているかはsudo chronyc -N authdataでModeがNTSになっているかで確かめられます。
社内NTPサーバー化とうるう秒スミアの混在で詰まる箇所と設定上の注意点
chronyはsystemd-timesyncdと違い、そのまま社内向けのNTPサーバーになれます。オンプレミスで数十台のサーバーを抱える環境では、外部へ問い合わせるのを2台の社内NTPサーバーに限り、残りはそこへ同期させる構成がよく取られます。
allowで配信を許可するときのfirewall設定と4460番ポート
配信側のサーバーでは、allowで問い合わせを受け付けるネットワークを指定します。公式FAQのとおり、サブネットを書かないallowはIPv4とIPv6のすべてのアドレスを許可してしまうため、必ず範囲を付けます。
# /etc/chrony.conf（社内NTPサーバー側）
pool ntp.nict.jp iburst maxsources 4
allow 10.0.0.0/16
makestep 1 3
driftfile /var/lib/chrony/drift
rtcsync
# firewalld で 123/udp を開ける
sudo firewall-cmd --permanent --add-service=ntp
sudo firewall-cmd --reload
# どのクライアントが問い合わせているかを確認する
sudo chronyc clients社内NTPサーバーを1台にすると、その1台の故障や時刻の狂いが全サーバーへ波及します。最低2台、できれば3台用意し、クライアント側では全台をserver行に並べてください。3台あれば1台が狂っても多数決で外すことが可能です。停止を許容できる時間と台数の考え方は稼働率の計算と高可用性の設計を扱った記事が参考になります。NTSで配信する場合は、123/udpに加えて4460/tcpも開けます。
うるう秒をスミアするソースとしないソースを同期先に混ぜない設計
うるう秒が挿入される日には、時刻源によって扱いが分かれます。EC2ユーザーガイドは、Amazon Time SyncのNTPソースがうるう秒を「スミア」した時刻を返すと明記しています。スミアとは、1秒を一気に挿入せず、前後の長い時間に薄く分散させて吸収する方式です。一方、うるう秒をそのまま挿入する時刻源もあります。
この2種類を同じchronyの同期先に並べると、うるう秒の前後で時刻源どうしが最大1秒食い違い、chronydが一部をxと判定して外したり、選ばれる時刻源が切り替わったりします。AWS上ではAmazon Time Syncだけに寄せ、オンプレミスと混在する環境では、社内NTPサーバー側で扱いを1つに揃えてから配る設計にしてください。自前でスミアしたい場合、リファレンスにはleapsecmode slew、maxslewrate 1000、smoothtime 400 0.001024 leaponlyを組み合わせる例が載っています。
受託開発のサーバー構築でchronyの設定を標準化する条件と見送る場面
ここからは判断です。chronyはどのディストリビューションでも既定の設定で動き始めるため、全案件で手を入れる必要はありません。次のどれかに当てはまるシステムでは、同期先と監視を構築手順に明記して標準化します。
- 時刻のずれが認証失敗になる：TOTP、Kerberos、署名付きURLやJWTの有効期限を使う
- 複数台のログや記録を時刻で突き合わせる：分散データベース、監査ログ、決済や受発注の順序を後から検証する
- 外向き通信を絞ったネットワークに置く：プライベートサブネットのEC2、閉域網のオンプレミス。既定の同期先に届かない
逆に、単体で動く小規模なWebサーバーや検証環境で、AL2023のように最初からクラウドの時刻源を向いている場合は、既定のままで十分です。この場合はchronyc sourcesで^*を確認する1行を構築後チェックに入れるだけにとどめ、独自設定は足さないでください。設定を足すほど、OSの更新時に差分を見直す手間が増えます。
クラウドとオンプレミスをまたぐ構成で時刻源を一本化するための設計
判断が難しいのは、AWSのEC2とオンプレミスのサーバー、別のクラウドが混在する構成です。前章のスミアの違いに加え、閉域網ではNTSの鍵交換が通らないこともあり、時刻源の選び方がネットワーク設計と絡みます。どこを時刻の基準にし、どの経路で配るかは、サーバーを置く場所を決める段階で一緒に決めておくのが手戻りの少ない進め方です。社内で設計の手が足りない場合は、一創のインフラ構築（AWS・Google Cloud・Azure）で、ネットワークと時刻同期を含めた基盤の設計から相談できます。
よくある質問
chronyの設定と運用について、検索で多い質問に答えます。
chronyとntpdはどちらを使えばよいですか？
新しく構築するならchronyを選んでください。RHEL系、Amazon Linux 2023、SUSE Linux Enterprise Server 15以降、Ubuntu 25.10以降はchronyが既定の時刻同期デーモンです。公式FAQは、chronyのほうが同期が速く精度も高いと説明しています。暗号化認証のNTSにも対応したソフトウェアです。ntpdの設定をchronyへ移す場合、server行の書式はほぼ同じなので、同期先の行はそのまま流用できます。
chronyで今すぐ時刻を合わせるコマンドはありますか？
sudo chronyc makestepを引数なしで実行すると、その場で時刻を飛ばして合わせます。ただし時刻が急に進んだり戻ったりすると、ログの順序やタイマー処理が乱れる恐れがあります。本番環境では、まずchronyc trackingでずれの量を確かめ、1秒未満ならスルーで自然に収束するのを待つのが安全です。スクリプトで同期完了を待つならchronyc waitsyncが使えます。
chronyが使うポート番号は何番ですか？
通常のNTPは123/udpです。社内NTPサーバーとして配信する場合は、この番号を受信側で開けます。NTSを使う場合は、鍵交換（NTS-KE）に4460/tcpも必要です。Ubuntu 25.10以降の既定設定はNTSのため、外向きの4460/tcpが塞がれた環境では同期に失敗します。chronycからデーモンへの操作は、既定ではローカルのソケット経由でのみ受け付けます。
timedatectlとchronycはどう使い分けますか？
timedatectlはタイムゾーンの設定や、時刻同期が有効かどうかの確認に使うsystemdのコマンドです。表示される「System clock synchronized: yes」で同期の有無は分かりますが、どの時刻源に何秒ずれているかまでは分かりません。同期先の状態やずれの量を調べるときはchronyc sourcesとchronyc trackingを使います。
chrony.confを変更したあとは再起動が必要ですか？
同期先の追加や削除だけなら、Ubuntu系ではsources.dにファイルを置いてsudo chronyc reload sourcesを実行すれば、デーモンを止めずに反映できます。makestepやallowなど本体の設定を変えた場合は、RHEL系ならsudo systemctl restart chronyd、Ubuntu系ならsudo systemctl restart chronyで再起動してください。反映後はchronyc sourcesで確認します。
関連記事
- Linuxコマンド一覧｜用途別早見表48選とUbuntu 26.04での変更点：chronycと一緒に使うサービス管理やネットワーク確認のコマンドを引けます
- Ansibleとは？エージェントレスの仕組みとメリット・デメリット、Red Hat AAPの制約：chrony.confを複数台へ同じ内容で配る手段として使えます
- 冗長化とは？二重化との違い・種類と構成、企業の設計判断まで解説【2026年版】：社内NTPサーバーを複数台に分ける考え方の土台になります
- MTTRとは？計算式・MTBFとの違いと稼働率への影響、短縮策を実装目線で解説【2026年版】：障害調査でログの時刻をそろえることが復旧時間にどう効くかが分かります
- OpenSSHとは？最新バージョンの確認方法とアップデート手順【2026年版】：chronyと並んでサーバー構築時に版と設定を確認するソフトウェアです
