「サイトが開かない」と言われたとき、どこから調べますか。
Web サーバーのログをいきなり開く人、ブラウザを何度も再読み込みする人、とりあえずサービスを再起動する人。どれも当たることはありますが、外れたときに次の一手が決まりません。
この記事では、PC・ルーター・DNS・Web 2台・振り分け機(ロードバランサー)・ログサーバ・監視サーバ・クラウドがつながった構成で、5か所が同時に壊れている状態をどう切り分けるかを、順番に沿って書きます。新しいコマンドは出てきません。大事なのは「打つ順番」と「画面の知らせの読み方」です。
切り分けは下から順に
順番は次の4つです。
- 名前を引けるか(DNS)
- そこまで届くか(経路)
- 返事が来るか(待ち受け・フィルタ)
- 中身は正しいか(アプリ・ログ・監視)
上の段がおかしいと、下の段の結果はすべて当てになりません。名前が違う住所を指していれば、その先でいくら Web サーバーを調べても何も見つからないからです。
最初の3つは、PC から次のコマンドで確かめます。
getent hosts www.example.test
dig @192.0.2.131 www.example.test a
getent hosts は、PC が実際に使う名前解決の結果を見ます。dig は DNS サーバーに直接聞きます。2つが食い違えば、PC 側の設定かキャッシュを疑えます。
curl の終了コードで「どこで止まったか」を読む
返事が来るかどうかは curl で見ます。待ち時間を短くしておくと、黙って落ちる場合もすぐ分かります。
curl --connect-timeout 3
ここで出る2つの数字が、切り分けの大きな手がかりになります。
- (7) すぐ断られた: その住所までは届いているのに、その番号で待っているものが無い。名前が引けているなら、「引いた先が違う」ことが多い
- (28) 時間切れ: 途中で捨てられているか、帰り道が違う。ファイアウォール(クラウドならセキュリティグループ)を疑う
「すぐ断られる」と「待たされて終わる」は、どちらも「つながらない」ですが、原因の場所がまったく違います。ここを区別せずに再起動を始めると、時間だけが過ぎます。
「開くたびに結果が変わる」がいちばん厄介
振り分け機は、後ろの Web サーバーに交互に渡します。後ろの片方だけが壊れていると、半分の回だけおかしくなります。
1回開いて動いたら、そこで終わりにしたくなります。でも、それでは半分の確率で見落とします。直したあとも、何度か続けて開いて確かめます。
curl http://www.example.test/
curl http://www.example.test/
curl http://www.example.test/
curl http://www.example.test/
4回くらい続けて全部返ってくれば、両方の Web サーバーが答えています。
この演習では、片方の Web サーバーの既定の出口(デフォルトルート)が振り分け機を通っていないことが原因でした。振り分け機は宛先だけを書き換えて渡すので、Web から見た送り主は PC のままです。出口が振り分け機を通らないと、その Web に渡された回だけ返事が戻りません。
ip route
ip route replace default via 192.0.2.134
「外から見えない」はまず中から見る
クラウドのサーバーで時間切れ (28) が出たら、サーバーの中から自分自身を開いてみます。
curl -s http://127.0.0.1/
iptables -L INPUT -n --line-numbers
中からは見えるのに外からは時間切れになるなら、アプリは動いています。問題は手前で捨てている側です。ルールの一覧を番号つきで出すと、どの位置に許可を足せばいいかが分かります。
ページが出たら、ログと監視も見る
ページが開けると直った気になりますが、ここからが見落としやすいところです。ログと監視は、出ていないことに気づきにくいからです。
この演習の構成では、サーバー本体の rsyslog の設定は正しく、logger で送ったログは届いていました。ところが、コンテナのログは rsyslog を通らずに、コンテナを作ったときの設定で送り先が決まります。
docker inspect -f '{{.HostConfig.LogConfig.Config}}' web
送り先は作るときにしか決められないので、違っていればコンテナを作り直します。
監視も同じです。SNMP のエージェントが 127.0.0.1 だけで待っていると、合言葉も相手も合っているのに、監視サーバーからは Timeout になります。
cat /etc/snmp/snmpd.conf
systemctl restart snmpd
ss -ulnp
ss -ulnp で、どの住所で待っているかを見れば一目で分かります。
まとめ
- 切り分けは「名前 → 届くか → 返事が来るか → 中身」の順に、下から見る
-
curlの (7) と (28) は、止まった場所が違う。区別してから次の手を決める - 振り分け機の後ろは、何度か試さないと半分の故障を見落とす
- 「ページが出た」で終わらせず、ログと監視が届いているかを最後に確かめる
実際に手を動かすなら
この記事の構成は、ブラウザだけで動く練習用の疑似環境で、5か所の故障を自分で探して直せます。通信はせず、登録も要りません。
- 5か所の故障を探して直す演習: インフララボ10段目「壊れた構成を直す」
- 切り分けの順番だけを1台で練習するレッスン: つながらないときの切り分け順序(Linux)
この記事は生成AIで作成し、公開前に人が最終確認しています。掲載しているコマンドは、すべてプロ道の教材に載っているものから引用しています。