疎通確認の方法
「相手とつながっているか」を確かめる基本が疎通確認です。ping は相手へ小さなパケットを送って応答時間を測り、到達できるかを調べます。経路の途中で止まっている場合は traceroute で、どのルータまで届いているかを段階的に確認します。Webサービスの応答までまとめて見たいときは curl が便利です。
設定を変えたあと、サービスが応答しないとき、「つながらない」と相談されたとき。こうした場面で、ベテランが真っ先にやるのは、あれこれ設定を見直すことではない。
まず相手まで届くかどうかをはっきりさせる、疎通確認だ。どこまで通信できていて、どこで止まっているか。これを切り分ければ、調べるべき範囲をぐっと狭められる。やみくもに設定をいじるのは、地図を見ずに歩き回るようなものだ。
疎通確認には ping・traceroute・curl といった道具があり、それぞれ「届くか」「どの道を通るか」「サービスが応答するか」という別の角度から状況を教えてくれる。これらを手を動かして使えるようになることが、ネットワークのトラブル対応の土台だ。
📣 こだまは返ってくるか
もっともよく使われるのが ping だ。山に向かって声を出し、こだまが返れば道がつながっていると分かる。ping はまさにそれをやる。
相手へICMPという制御用プロトコルの小さなパケット（エコー要求）を送り、相手から応答（エコー応答）が返ってくるかを調べ、あわせて往復にかかった時間を測る。
書式は ping 相手のIPアドレスまたはホスト名 で、たとえば ping -c 4 192.168.1.1 とすると4回だけ試して止まる。-c で回数を指定しない場合、Linuxでは応答が返り続けるかぎり送信を続けるので、確認できたら Ctrl と C を同時に押して停止する（Windowsの ping は既定で4回試して自動で終わる）。
返ってきたこだまの読み方も押さえておこう。64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.45 ms のような行が返り、最後に 4 packets transmitted, 4 received, 0% packet loss と出れば、相手まで届いて応答も返ってきた、つまり経路が生きていて相手も動いている、と判断できる。
time の値は往復時間（ミリ秒）で、これが極端に大きかったり、応答がときどき抜けたりする「ばらつき」も、不安定さを示す重要な手がかりだ。
逆に応答がなく 100% packet loss や Destination Host Unreachable が出る場合は、相手が起動していない・IPやゲートウェイの設定が違う・経路が切れている、などが疑われる。その場合は、まず自分のIP設定（ip addr）とデフォルトゲートウェイ（ip route）を見直すのが定石になる。
⚠ pingが返らない＝故障、とは限らない
ここで、初心者がよく踏む地雷を一つ外しておきたい。ping が返らない＝必ず故障、とは限らないのだ。
経路の途中の機器や相手自身が、セキュリティのためにICMPをブロックする設定になっていることがあり、その場合は通信自体は可能でも ping には応答しない。一部のサーバはわざとICMPに答えない設定になっている。
したがって、ping が通らないときは、それだけで断定せず、別の手段と組み合わせて切り分けるのが正しい姿勢だ。とくにWebサーバなど特定のサービスが動いている相手なら、後述の curl でそのポートへ接続できるかを試すほうが、生死の判断として確実なことがある。
逆に ping が通れば、少なくともそのIPアドレスまでの経路と相手の稼働は確認できるので、その先はより上の層（サービスやファイアーウォール）を疑う、という切り分けに進める。
🧭 どこまで行けて、どこで止まったのか
ping が「届くか／届かないか」だけを見るのに対し、traceroute は「どの道を通って相手まで行くか」を1ホップずつ見せてくれる。
traceroute 相手のホスト名 とすると、自分のすぐ外のルータ（デフォルトゲートウェイ）から順に、経由したルータのアドレスと往復時間が番号付きで並ぶ。
これはパケットのTTL（寿命）を1ずつ増やしながら送り、どのルータで寿命が尽きたかを順に調べる仕組みだ。前に学んだTTLが、ここでは道案内の道具に化ける。どこまで番号が進んでいるかで「経路のどこまで通信できているか」が分かるため、途中で止まっている障害の切り分けに有効だ（Windowsでは tracert という名前）。経路の途中に * * * が出ても、そのルータが応答を返さない設定なだけのことも多いので、最終的に目的地まで到達できているかで判断する。
一方、Webサービスの応答までまとめて確認したいときは curl が便利で、curl -I https://例.example/ とすればステータス行とヘッダだけが返り、接続が成立したか、サーバが正常に応答しているか（200番台か、404や500番台か）を一度に確かめられる。
🩺 つまずいたら、まずここ
実務での疎通確認には、定石の「順番」がある。近いところから遠いところへ、一歩ずつたどるのだ。
まず ping 127.0.0.1 で自機のIP通信機能を確かめ、次に同じネットワーク内の相手やデフォルトゲートウェイへ ping して足元が健全かを見て、それから外のサーバへ ping や traceroute を試す。こうすると、どの段階で初めて失敗するかで原因の所在が浮かび上がる。たとえばゲートウェイまでは通るのにその先が通らないなら、問題は自分の外側の経路にある、と絞り込める。
ping・traceroute・curl はいずれも相手の状態を「見る」だけのコマンドなので、安心して何度でも試しながら、つながりの全体像をつかんでいけばいい。
さらに上を目指すなら道具も増える。ping と traceroute を合体させて各ホップの遅延や損失を連続表示する mtr というツールを使えば、どのホップで品質が落ちているかを一目で把握できる。
また、ICMPがブロックされていて ping が通らないサーバでも、nc -zv 相手 ポート のようにTCPで特定ポートへ接続できるかを試せば、Web（80番・443番）やSSH（22番）が開いている相手なら生死を確認できる。「ただ繋がるか」だけでなく「どこがどう遅い・落ちているか」まで見えるようにしておくと、原因にたどり着く速さが大きく変わる。