ネットワークの切り分け

勘ではなく順序で切り分ける

「サイトが開かない」と言っても、原因はケーブルの抜けからDNSの設定ミス、アプリの不具合まで様々です。あてずっぽうに設定をいじると、直ったか壊れたかも分からなくなります。

大切なのは 「どこまでは正常で、どこから異常か」を一段ずつ確かめる ことです。OSI参照モデルのように層を意識し、下（物理寄り）から上（アプリ寄り）へ順に潰していくと、原因の範囲を確実に狭められます。

• 下の層が壊れていれば、上の層は必ず影響を受ける
• だから下から確認すれば、無駄な調査を省ける

レイヤごとに確認する

各層で「ここまでは届くか」を確認していきます。順番に見ていくのがコツです。

確認する層	問い	主な手段
物理・リンク	ケーブル・Wi-Fi・IP取得はOKか	リンクランプ、ip addr
ネットワーク（到達性）	相手のIPまで届くか	ping
経路	どこで止まっているか	traceroute
名前解決	ドメインをIPに変換できるか	dig / nslookup
アプリ	サービスが正しく応答するか	curl

「IPでは届くのに名前で届かない」ならDNS、「pingは通るのにcurlで500」ならアプリ側、と切り分けが進みます。

基本コマンドの使いどころ

それぞれの役割を押さえると、症状から使うべき道具がすぐ決まります。

• ping … 相手のIPまでパケットが往復するかを確認。到達性とおおよそのレイテンシが分かる
• traceroute … 宛先までの経路を1ホップずつ表示。どこで途切れる・遅くなるかを特定（Windowsは tracert）
• dig … ドメイン名からIPへの名前解決を確認。応答するDNSサーバや返ってくるレコードまで見える
• curl … 実際にHTTPでアクセスし、ステータスコードやヘッダ、本文を確認。アプリ層の応答を直接見る

# 到達性を確認
ping example.com

# 経路のどこで止まるか
traceroute example.com   # Windows は tracert example.com

# 名前解決の確認
dig example.com

# アプリ層の応答を詳しく見る
curl -v https://example.com

範囲を狭める考え方

原因の範囲は「自分・経路・相手」の3つに分けて狭めると効率的です。

• 他のサイトは見られるか … 自分だけ全滅なら自分側、その相手だけなら相手側か経路
• 他の端末ではどうか … 同じ回線の別端末が正常なら、問題は自端末の設定に絞れる
• 時間帯で変わるか … 混雑時だけ遅いなら帯域・輻輳の可能性

「変えた直後に壊れたか」も強力な手がかりです。直近の変更（設定・更新・配線）を疑うと、原因に早く近づけます。

つまずきポイント

• ping が通らない＝故障とは限らない … ICMPを遮断しているだけのこともある。curl など別の手段でも確かめる
• キャッシュに惑わされる … DNSやブラウザのキャッシュで古い結果が出ることがある。クリアして再確認する
• 正常な状態を知らない … 普段の値（応答時間・経路）を把握しておくと、異常に気づきやすい

順序立てて「どこまでは正常か」を積み上げる癖をつけると、初見のトラブルでも落ち着いて原因にたどり着けます。