ヘルスチェック型DNS が期待どおりに動いているかは、「確認用の URL が正しく応答しているか」「ヘルスチェッカーからどう見えているか」「DNS が正しいアドレスを返しているか」「障害時に何分で切り替わるか」の4段階に分けて確かめると、どこに問題があるかを切り分けられます。この記事では Amazon Route 53 のヘルスチェックとフェイルオーバーのレコードを例に、各段階で使うコマンドと見るべき値、よくある誤判定の原因を説明します。他の DNS サービスでも、確かめる順番は同じです。
確認は4つの段階に分けて行う
ヘルスチェック型DNS は、次の流れで動いています。
チェッカー（複数の地域） ─→ 確認用URL（各サーバー）
│ 判定結果
▼
権威DNS ─→ 公開リゾルバー（キャッシュ） ─→ 利用者どこか一か所が想定と違うと、「サーバーは正常なのに外れた」「止まっているのに外れない」といった症状になります。上流から順に確かめると、原因を一つずつ消していけます。
段階1：確認用の URL が正しく応答しているか
まず、ヘルスチェックの対象と同じ条件で URL を開きます。curl の --resolve を使うと、DNS を通さずに特定のサーバーへ、正しいホスト名で接続できます。
curl -sS -o /dev/null \
-w 'code=%{http_code} time=%{time_total}s\n' \
--resolve www.example.com:443:192.0.2.10 \
https://www.example.com/wp-json/dnshc/v1/ping
# 本文とヘッダーも確かめる
curl -sS -i --resolve www.example.com:443:192.0.2.10 \
https://www.example.com/wp-json/dnshc/v1/pingここで見る点は次のとおりです。
- ステータスコードが 200 で、本文に設定した文字列（例:
"status":"ok"）が含まれているか - 応答時間に余裕があるか。ヘルスチェックには待ち時間の上限があり、遅い応答は失敗と判断されます
Cache-Control: no-storeなど、キャッシュされない設定になっているか- リダイレクトしていないか。
http://からhttps://へ、あるいは別のホスト名へ転送されると、文字列一致の判定で失敗します
サーバーが複数ある場合は、アドレスを変えてすべてのサーバーで同じ確認をします。
段階2：ヘルスチェッカーからどう見えているか
Route 53 では、複数の地域にあるチェッカーが別々に確認しています。地域ごとの最新の結果は次のコマンドで見られます。
aws route53 get-health-check-status --health-check-id your-health-check-id
# 直近の失敗の理由
aws route53 get-health-check-last-failure-reason --health-check-id your-health-check-id結果の StatusReport に、地域ごとの成功や失敗と、その理由（接続できない、タイムアウト、文字列が見つからないなど）が出ます。特定の地域だけが失敗しているなら、経路かファイアウォールの問題を疑います。すべての地域で失敗しているなら、段階1の確認からやり直します。
サーバーのアクセスログでも、チェッカーからの要求が届いているかを確かめられます。チェッカーの User-Agent には Route 53 のヘルスチェックであることを示す文字列が入るので、それで絞り込みます。
grep -i 'route53' /var/log/nginx/access.log | tail -n 20ログに要求が一件もなければ、手前の WAF やファイアウォールで止まっています。要求は届いていて 403 が返っているなら、セキュリティ系のプラグインや国別のアクセス制限が原因であることが多いです。
段階3：DNS が正しいアドレスを返しているか
判定の結果は、まず権威DNS の応答に反映されます。公開リゾルバーのキャッシュの影響を除くため、権威サーバーに直接問い合わせます。
# 権威サーバーを調べる
dig +short NS example.com
# 権威サーバーに直接聞く（キャッシュを通さない）
dig @ns-123.awsdns-45.com www.example.com A +norecurse
# 公開リゾルバーの応答と残りの TTL を比べる
dig @1.1.1.1 www.example.com A
dig @8.8.8.8 www.example.com A権威サーバーが正しい値を返していて、公開リゾルバーが古い値を返している場合は、キャッシュが切れるのを待つ段階です。応答の TTL の欄が残り時間なので、その秒数が過ぎれば新しい値に変わります。
Route 53 には、ホストゾーンがどう応答するかを確かめるコマンドもあります。
aws route53 test-dns-answer --hosted-zone-id your-zone-id \
--record-name www.example.com --record-type A段階4：障害を起こして切り替わりの時間を測る
最後に、実際に主のサーバーを異常にして、切り替わるまでの時間を測ります。本番で行う場合は、アクセスの少ない時間帯を選び、関係者に知らせてから実施します。
権威サーバーの応答を10秒ごとに記録するスクリプトを、手元の端末で動かしておきます。
#!/bin/bash
# 権威サーバーの応答を10秒ごとに記録する
NS=$(dig +short NS example.com | head -n 1)
while true; do
printf '%s %s\n' "$(date +%T)" \
"$(dig @"$NS" www.example.com A +short +norecurse | tr '\n' ' ')"
sleep 10
done主のサーバーで確認用 URL を一時的に無効にします。mu-plugin のファイル名を変えると、URL は 404 を返すようになり、ヘルスチェックは失敗します。
cd /var/www/html/wp-content/mu-plugins
mv dnshc.php dnshc.php.off # 異常にする
# 切り替わりを確認したら元に戻す
mv dnshc.php.off dnshc.php記録から、次の三つの時間を読み取ります。
- ファイル名を変えてから、権威サーバーの応答が副のアドレスに変わるまで
- そこから、公開リゾルバーの応答が変わるまで（TTL の範囲内に収まるか）
- 元に戻してから、主のアドレスに戻るまで
確認の間隔 30秒・失敗の回数 3回なら、1 はおおよそ1〜2分、2 は TTL までが目安です。大きく外れる場合は設定値を見直します。
よくある誤判定と原因
正常なのに異常と判定されるときは、可能性の高い順に次を確かめます。
- 送信元の遮断：WAF、fail2ban、セキュリティプラグイン、国別のアクセス制限が、海外のチェッカーを止めている。段階2のアクセスログで確かめ、AWS が公開しているチェッカーのアドレス範囲を許可します。
- ホスト名の不一致：IP アドレスだけを指定してホスト名を入れていないため、別のサイトや既定のページが返っている。ヘルスチェックの設定にホスト名を入れ、HTTPS なら SNI を有効にします。
- 応答の遅さ：バックアップや更新の時間帯にデータベースが遅れる。確認用 URL の処理を軽くし、失敗とみなす回数を見直します。
止まっているのに外れないときは、次を確かめます。
- キャッシュの応答を見ている：ページキャッシュや CDN が古い成功の応答を返している。確認用 URL をキャッシュの対象から外し、サーバーへ直接向けます。
- レコードとの結び付けが無い：主のレコードにヘルスチェックが付いていない、エイリアスでターゲットの状態を評価する設定がオフになっている。
- ヘルスチェックが無効になっている：Route 53 では、無効にしたヘルスチェックは正常として扱われる仕様です。保守で無効にしたまま戻し忘れていないかを確かめます。
確認の結果を記録しておく
確認した日、各段階の結果、測った切り替え時間を残しておくと、設定を変えたときに比べられます。サーバーの追加、WAF の設定変更、CDN の導入のあとは、段階1と段階2をもう一度行います。画面の表記や CLI の出力の項目名は変わることがあるため、作業時は AWS のドキュメントで確認してください（2026年10月現在）。
まとめ
- 動作確認は「確認用 URL → チェッカーからの見え方 → 権威DNS の応答 → 切り替え時間」の順に行うと、問題のある段階を特定できます。
curl --resolveでサーバーごとに確かめ、get-health-check-statusで地域ごとの結果を見ます。- DNS の応答は、権威サーバーに
+norecurseで直接聞いて、キャッシュの影響と分けて見ます。 - 誤判定の多くは送信元の遮断、ホスト名の不一致、キャッシュ、レコードとの結び付けの漏れが原因です。