疎通確認の方法
「相手とつながっているか」を確かめる基本が疎通確認です。ping は相手へ小さなパケットを送って応答時間を測り、到達できるかを調べます。経路の途中で止まっている場合は traceroute で、どのルータまで届いているかを段階的に確認します。Webサービスの応答までまとめて見たいときは curl が便利です。
ネットワークの調査で最初に行う基本動作が、相手と「つながっているか」を確かめる疎通確認です。設定を変えたあと、サービスが応答しないとき、つながらないと相談されたとき——いずれの場面でも、まず相手まで届くかどうかをはっきりさせることが、原因究明の出発点になります。やみくもに設定を見直す前に、どこまで通信できていてどこで止まっているかを切り分ければ、調べるべき範囲をぐっと狭められます。疎通確認には ping・traceroute・curl といった道具があり、それぞれ「届くか」「どの道を通るか」「サービスが応答するか」という別の角度から状況を教えてくれます。これらを手を動かして使えるようになることが、ネットワークのトラブル対応の土台です。
ping で到達を確かめる
もっともよく使われるのが ping です。ping は相手へICMPという制御用プロトコルの小さなパケット（エコー要求）を送り、相手から応答（エコー応答）が返ってくるかを調べ、あわせて往復にかかった時間を測ります。書式は ping 相手のIPアドレスまたはホスト名 で、たとえば ping -c 4 192.168.1.1 とすると4回だけ試して止まります。-c で回数を指定しない場合、Linuxでは応答が返り続けるかぎり送信を続けるので、確認できたら Ctrl と C を同時に押して停止します（Windowsの ping は既定で4回試して自動で終わります）。山に向かって声を出し、こだまが返れば道がつながっていると分かる——その仕組みに似ています。
ping の結果は次のように読みます。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アドレスまでの経路と相手の稼働は確認できるので、その先はより上の層（サービスやファイアーウォール）を疑う、という切り分けに進めます。
traceroute と curl
ping が「届くか／届かないか」だけを見るのに対し、traceroute は「どの道を通って相手まで行くか」を1ホップずつ見せてくれます。traceroute 相手のホスト名 とすると、自分のすぐ外のルータ（デフォルトゲートウェイ）から順に、経由したルータのアドレスと往復時間が番号付きで並びます。これはパケットのTTL（寿命）を1ずつ増やしながら送り、どのルータで寿命が尽きたかを順に調べる仕組みで、どこまで番号が進んでいるかで「経路のどこまで通信できているか」が分かるため、途中で止まっている障害の切り分けに有効です（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番）が開いている相手なら生死を確認できます。「ただ繋がるか」だけでなく「どこがどう遅い・落ちているか」まで見えるようにしておくと、原因にたどり着く速さが大きく変わります。