本ページの位置づけ
サイト運用中に実際に発生した、Webサーバー本体ではなく手前のリバースプロキシ(Caddy)に起因する障害の記録です。攻撃ランキングや対策・対応の記録と同様、現在の防御設定の具体的な数値は記載していません。
第1章：発見の経緯
日々のログ確認の中で、Caddyのエラーログに接続タイムアウトの記録を発見しました。特定のドメイン宛のアクセスに対し、バックエンドへの接続が3秒でタイムアウトし、クライアントには502(Bad Gateway)が返っていました。
第2章：原因と影響範囲
Caddyの設定ファイルを確認したところ、サイト本体宛のリクエストの転送先が、実際には存在しない古いIPアドレスを指したままになっていることが判明しました。おそらく過去の構成変更の際に更新し忘れた設定が残っていたものです。
影響範囲: 詳しくログを遡ると、少なくとも1日半にわたって断続的にこの502エラーが発生していました。対象は実際の閲覧者(複数のブラウザ・OSから)と、検索エンジン・AI検索エンジンのクローラー(クローラー紹介で扱っているような正規のもの)の双方でした。つまり、実際の訪問者もクローラーも、この間サイトを正常に閲覧・巡回できていなかったことになります。
第3章：見落としの理由
この障害の発見が遅れた最大の理由は、内部ネットワークからの動作確認では問題が再現しなかったためです。社内(LAN内)のDNS解決の都合上、内部からのアクセスはリバースプロキシを経由せず、Webサーバー本体へ直接届いていました。そのため「動作確認は正常」という結果が、実際には外部からの見え方を反映していない状態でした。
教訓
内部関係者だけがアクセスできる経路での動作確認は、外部の一般利用者から見た状態を保証しません。公開サービスの疎通確認は、可能な限り実際の外部経路(モバイル回線等)で行う必要があります。
第4章：修正とその副作用
4-1. 一次修正
転送先を、固定IPではなく「コンテナホスト自身を指す」動的な名前解決の仕組みに変更しました。固定IPは、環境が変化すると今回のように陳腐化するリスクがあるため、より環境の変化に強い指定方法に変更した形です。
4-2. 副作用の発生
ところが、この変更に伴い、リバースプロキシからWebサーバー本体への接続経路が変わり、アクセスログに記録される訪問者の送信元IPが、本来のIPではなく、内部の中継アドレス1つに集約されてしまうという別の問題が発生しました。原因は、リバースプロキシを構成するコンテナの仮想ネットワークの制約(同じネットワークインターフェースを共有するホスト自身には直接到達できないという既知の制約)により、経路がもう一段別の内部ネットワークを介するようになったためです。
この状態が続くと、外部からの不審なアクセスを送信元IPで検知・遮断する仕組み(ログベースの自動遮断)が、実質的に機能しなくなるという実害があります。あわせて、仮に「その中継アドレスが不審だ」と誤認して遮断してしまうと、リバースプロキシ自体がブロックされてサイト全体が止まる、という危険もありました。
4-3. 副作用の修正
Webサーバー本体側で、信頼するプロキシの範囲を「単一の固定IP」ではなく「該当する内部ネットワークの範囲全体」を信頼するよう変更しました。単一IPへの依存が今回の問題の一因だったため、経路が今後多少変化しても壊れにくい設定にする狙いです。
検証状況
修正の効果は、外部からの実際のアクセスで確認する必要がありますが、内部ネットワークからのテストでは(第3章の理由により)検証にならないため、記事執筆時点では最終確認待ちの状態です。
第5章：教訓
- 固定IPへの依存は壊れやすい。環境や構成が変われば陳腐化する前提で、可能な限り動的な名前解決や範囲指定を使う。
- 1つの修正が別の層に副作用を及ぼすことがある。ネットワーク経路を変えれば、その経路を前提にしていた別の設定(今回はログの送信元IP信頼設定)も連動して見直す必要がある。
- 内部からの動作確認だけでは不十分。公開サービスは、外部からの視点での確認を組み込んだ運用にする。