LinuxサーバーのIPアドレスが重複して2日間障害を調査し続けた話｜SE時代の教訓と現役講師が語るネットワーク診断の基本

「なぜかSSHは繋がるのにHTTPだけ応答しない。しかも5分後には何事もなかったように動いている。」

SE時代、私が経験した障害の中で最も「謎に見えた」ケースのひとつです。原因を探して丸2日間、Apacheの設定を見直し、ネットワーク設定を確認し、ファイアウォールのルールを何度も検証しました。しかし最終的に犯人は自分のサーバーではなく、ネットワーク上の「別のサーバーが同じIPアドレスを使っていた」という、まったく想定外の場所にありました。

この記事では、20年以上Linuxサーバーを運用してきた経験から、IPアドレス重複という「珍しいけれどはまると長い」トラブルの特徴と、arpingコマンドを使った確認方法、そして台帳管理という再発防止策をお伝えします。

あの日、サーバーが「気まぐれ」に見えていた

2004年頃、私はSEとして某製造業のシステム運用を担当していました。その日、社内の業務Webシステムにアクセスしていた社員から「たまに画面が開かない」と連絡が来たのがことの始まりです。

症状は奇妙でした。SSHでサーバーにログインすることは普通にできます。Apacheのプロセスも正常に動いている。なのに、ブラウザからアクセスすると「このサイトにアクセスできません」と出ることがある。しかも、しばらく待って再アクセスすると何もなかったように開ける。

「タイムアウトかな」「回線が混雑しているのかな」と最初は楽観視していましたが、1時間おきに同じ症状が出るとなると話は別です。社内の数十名が使うシステムが断続的に落ちている。これは放置できない問題でした。

まず私が動揺したのは、「エラーログにまったく何も残っていない」という事実でした。正常に動いているのにアクセスできない。これほど気持ち悪い状況はありません。当時の私は「どこかに原因があるはずだ」と信じて調査を続けましたが、最初の数時間で早くも方向性を見失っていました。

2日間の迷宮。Apacheもネットワークも問題なし

1. まずApacheのログと設定を疑った

障害の第一候補はWebサーバー本体です。/var/log/httpd/error_logとaccess_logを丁寧に確認しましたが、エラーは何も出ていません。接続が来ていないのではなく、接続自体がサーバーに届いていない様子でした。

Apacheの設定ファイルもひと通り確認しました。
ポートはちゃんとListenしているし、設定ファイルの文法エラーもない。Apacheは完全に正常でした。ポートの確認方法については「Linuxでポートの状態をss・lsofで確認する方法」も参考にしてください。

Apacheを再起動して様子を見ましたが、しばらくすると同じ症状が再現しました。再起動直後は問題ないが、しばらくするとまた断続的に繋がらなくなる。この「しばらく後に再発する」という挙動が、後に重要なヒントになるとは、このときの私にはまったくわかっていませんでした。

2. ネットワーク設定も問題なし

次にIPアドレスとルーティングを確認しました。
IPアドレスは正しく設定されています。ゲートウェイも問題なし。インタフェースはUP状態で、送受信のエラーカウントも増えていない。ネットワーク設定に異常は見つかりませんでした。

3. ファイアウォールも確認した

2004年当時はiptablesが主流でした。ルールを確認してみましたが、HTTPの80番ポートへのアクセスは正しく許可されています。iptablesのカウンタを確認すると、パケットは確かに通過している形跡がある。でも、なぜか一部のアクセスだけが届かない。

1日目が終わる頃、私はかなり頭を抱えていました。「どう見ても正常なのに、なぜ繋がらないのか」。当時の上司に「まだ原因がわかりません」と報告すると「続けて調査してくれ」という一言だけ。プレッシャーを感じながら帰路についたのを今でも覚えています。

翌朝も調査を再開しましたが、新しい手がかりは見つかりませんでした。Apacheのタイムアウト値を変更してみたり、カーネルのネットワークパラメータ（net.core.somaxconn等）を疑ったり。それでも症状は変わりません。「このサーバーには幽霊でもいるのか」と半ば本気で思い始めていました。

IPアドレス重複トラブルの全貌——犯人は別のサーバーにいた

1. arpingコマンドで二つのMACアドレスが見えた瞬間

2日目の午後、隣の席の先輩エンジニアに「ちょっと聞いてもいいですか」と声をかけました。状況を説明すると、先輩は少し考えてから「arpingで確認してみたか？」と言いました。

当時の私はarpingの存在を知ってはいましたが、「自サーバーにpingが通っているのに、ARPを確認する意味が？」と半信半疑でした。それでも言われるがままに、別のPCから対象サーバーのIPへarpingを実行してみると、衝撃的な結果が返ってきました。
MACアドレスが2種類、交互に返ってきています。[xx:xx:xx:AA:BB:01]と[xx:xx:xx:CC:DD:02]。これはIPアドレス重複のサインです。ネットワーク上に192.168.10.50を名乗るサーバーが2台存在していた、ということになります。

「わかった。IP重複だ」と先輩が言った瞬間、この2日間の謎がすべて解けた気がしました。パケットがどちらのサーバーに届くかは、そのときのARPキャッシュ（各機器がIPとMACアドレスの対応を一時的に保存する仕組み）の状態によって変わります。運よく業務サーバーにパケットが届けば正常に応答する。別のサーバーにパケットが届いてしまえば、HTTPレスポンスは返ってこない。ARPキャッシュが定期的に更新されるたびに、どちらに届くかが「くじ引き」のように変わっていた。これが「5分後には普通に動いている」という症状の正体でした。

SSHセッションが安定していた理由もこれで説明がつきます。SSHはセッション確立後はTCPレベルで接続を維持するため、ARPキャッシュが切り替わっても既存のセッションは安定します。しかし新しいHTTP接続はリクエストのたびに「くじ引き」が発生する。だからSSHは繋がるのにHTTPだけ断続的に落ちていたのです。

2. なぜIPアドレス重複が起きたのか

すぐにネットワーク担当者に確認を取りました。事情を調べると、前日に別の部署が新しい検証用サーバーを一時的に起動した際、IPアドレスを手動で「たぶん使っていない番号」として192.168.10.50を割り当てていたことが判明しました。

当時のネットワークにはIPアドレスの管理台帳がなく、担当者がそれぞれの「記憶」と「感覚」でIPを割り当てていました。2001年～2006年頃の多くの中小企業の現場では、これが普通でした。セミナーで受講生と話すと、「うちの会社も最近まで台帳がなかった」という声をよく聞きます。

検証用サーバーの電源を切ると、症状はぴたりと止まりました。そのあまりにも呆気ない解決に、2日間費やした疲労感が一気に押し寄せてきたのを覚えています。

この経験から現場で実践し続けていること

1. ネットワークトラブルは「まずarpingで確認」——これが鉄則

断続的な接続障害が起きたとき、私が最初に確認するのはarpingです。通常のping（ICMP）が通っていても、ARPレイヤーで複数のMACアドレスが応答していれば、IPアドレス重複を疑う根拠になります。

arpingコマンドはシンプルです。-Iオプションでネットワークインタフェースを指定し、対象のIPアドレスを渡すだけです。返ってくるMACアドレスが常に1種類であれば、IPアドレスの重複はありません。複数種類のMACアドレスが混在して応答していれば、すぐにネットワーク担当者を呼ぶべき状況です。

注意：arpingコマンドはディストリビューションによってはデフォルトで未インストールの場合があります。RHEL/CentOS系では `yum install iputils`、Debian/Ubuntu系では `apt install arping` でインストールできます。

「何を調べてもサーバー側に問題がない」と感じたとき、私はarpingを思い出すようにしています。あの2日間が刻み込んだ反射行動です。

2. IP割り当て台帳を整備する

あの経験以来、私が関わるシステムではIPアドレスの割り当て台帳を必ず整備するようにしています。専用のツールを使う必要はありません。スプレッドシートで十分です。

最低限、次の列を持たせると管理が楽になります。

・IPアドレス: 割り当て済みのIP
・MACアドレス: NICのMACアドレス（NIC交換時の変更追跡のため）
・ホスト名: そのサーバーの識別子
・用途: 業務システム、検証用、開発用など
・担当者: 誰が管理しているか
・最終確認日: 台帳の鮮度を保つために必須

台帳があれば、新しいサーバーを追加するとき「このIPは使えるか」を5秒で確認できます。また、台帳とDNSの整合性を合わせて管理することで、名前解決まわりのトラブルも減らせます。DNSとの連携については「LinuxサーバーのDNS設定をresolv.confとnmcliで管理する方法」も参考にしてください。

3. 「原因は別のサーバーにある」という仮説を常に持つ

ネットワーク障害の調査でよくある落とし穴は、「自分のサーバーだけを疑い続ける」ことです。特にIPアドレス重複やスイッチのループのような「ネットワーク基盤レベルの問題」は、自サーバー内をいくら調べても見つかりません。

私がセミナーで受講生に伝えているのは、障害調査の「対象範囲の広げ方」です。

・まず自サーバーの設定・プロセス・ログを確認する
・次にネットワーク設定（IP・ルーティング・ファイアウォール）を確認する
・問題が見つからなければ、ネットワーク機器やほかのサーバーへ調査範囲を広げる

20年以上サーバーを運用してきた経験から言うと、自サーバーで証明が取れないなら、ためらわずに「ネットワーク担当を呼ぶ」判断も大切です。あの2日間で私が最も後悔したのは、先輩に声をかけるのが遅かったことでした。「もう少し自分で調べてから相談しよう」という遠慮が、2日間の迷宮の真の原因だったかもしれません。

まとめ

LinuxサーバーのIPアドレス重複は、症状が断続的で自サーバーの設定に問題がないため、原因特定が非常に難しい障害です。あの2日間が教えてくれた教訓を整理すると次のようになります。

状況	確認・対処方法
断続的な接続失敗がある	arping -I eth0 対象IP でMACアドレスを確認
複数MACアドレスが返ってくる	ネットワーク上にIPアドレスが重複するサーバーがある
重複サーバーを特定する	スイッチのMACアドレステーブルと台帳を照合する
再発防止策	IP割り当て台帳（スプレッドシートでも可）を整備・定期更新

セミナーで3,100名以上を指導してきた中で、「ネットワーク障害の調査は自分のサーバーだけを見ていて長時間詰まっていた」という経験を持つ方は少なくありません。障害の原因が「別のサーバー」や「ネットワーク機器」にあることも多い。そのことを頭の片隅に置いておくだけで、調査にかかる時間は大きく変わります。

arpingとIP台帳。地味に見える2つのツールが、あの2日間の迷宮から私を救い出した本当の武器です。
IPアドレス管理を含めたLinuxサーバー運用の基礎を体系的に身につけたい方は、ぜひ下のリンクから無料マニュアルを受け取ってください。

---

• 前のページへ：LinuxサーバーのCPUが突然100%になった日の話｜現役講師が語る原因特定とtopコマンドへの向き合い方
• この記事の属するカテゴリ：Linux学習ガイドへ戻る