/etc/hostsが原因で起きる障害パターン集

  • URLをコピーしました!

/etc/hosts は一見シンプルな設定ファイルですが、
DNSよりも優先されるという特性から、気づきにくい障害の原因になりがちです。

本記事では、実務でよく遭遇する /etc/hosts 起因の障害パターン を整理し、
切り分け方法 → 確認コマンド → 解決策 までを具体的に解説します。

目次

/etc/hosts の基礎(なぜ障害を引き起こすのか)

Linuxの名前解決は、/etc/nsswitch.conf の設定に従って行われます。 多くの環境では以下のようになっています。

hosts: files dns

この設定では、

  • files → /etc/hosts
  • dns → DNS問い合わせ

の順で解決されるため、/etc/hosts に書かれている内容が最優先されます。

障害パターン①:古いIPが残り続けて通信できない

症状

  • DNS上は正しいIPに更新されている
  • 特定のサーバだけ通信できない
  • LB配下の一部ノードだけ疎通不可

原因

過去の検証や暫定対応で追加した hosts エントリが残り、
古いIPへ通信している

確認方法

# 名前解決結果の確認
getent hosts example.com

# hostsファイルの確認
grep example.com /etc/hosts

対策

  • 不要な hosts エントリを削除
  • 一時対応で書いた行には必ずコメントを残す

障害パターン②:IPv4 / IPv6 の解決順で通信できない

症状

  • ping は通るがアプリ通信が不安定
  • IPv6環境でのみ障害が発生

原因

/etc/hosts に IPv6 アドレス(::1 や fe80::)が定義され、
アプリが IPv6 を優先して接続してしまう。

確認方法

# IPv4/IPv6の解決順確認
getent ahosts example.com

対策

  • 不要なIPv6定義を削除
  • アプリ側で IPv4 固定(JVMオプション等)
# Javaの場合
-Djava.net.preferIPv4Stack=true

障害パターン③:localhost 定義の誤りによるサービス起動失敗

症状

  • サービスが起動しない
  • 起動時に localhost 解決エラー

原因

127.0.0.1 localhost が削除・改変されている。

確認方法

# localhostの解決確認
getent hosts localhost

対策

127.0.0.1   localhost localhost.localdomain

最低限この定義は残すのが安全です。

障害パターン④:クラスタ・分散システムでノード間通信が失敗

症状

  • クラスタ参加に失敗
  • ノード間通信が不安定

原因

各ノードの /etc/hosts に記載されている IP / ホスト名が不一致。

確認方法

# 全ノードでhostsを比較
diff /etc/hosts node1:/etc/hosts

対策

  • 構成管理ツールで hosts を統一管理
  • クラスタ用途での手書き編集を避ける

障害パターン⑤:検証用hostsが本番に残る

症状

  • 本番だけ挙動が違う
  • 他サーバでは再現しない

原因

個人検証用に追加した hosts が本番に残存。

対策(運用ルール)

  • hosts編集時は必ずコメントを付ける
  • デプロイ前チェックに hosts 差分確認を入れる

/etc/hosts 起因かどうかを素早く切り分けるチェックリスト

  • getent hosts の結果は期待通りか
  • 他サーバと結果が違わないか
  • IPv6が絡んでいないか
  • 一時対応の記載が残っていないか

まとめ

  • /etc/hosts は DNSより優先される
  • 小さな記述ミスが大きな障害につながる
  • 「通信できない時はまず hosts を疑う」

障害対応では 「疑う順番」 が重要です。
/etc/hosts は最初に確認すべきポイントの一つです。

目次