ネットワーク疎通の切り分け
「つながらない」障害は、どの層で止まっているかを順に切り分けます。まず ping で相手まで届くかを確認し、応答がなければ経路や相手の死活を疑います。届くのに接続できないときは、相手側のサービスが目的のポートで待ち受けているかが問題です。ss -tlnp で自分のサーバが開いているポートとプロセスを確認し、ファイアウォールやサービスの起動状態を合わせて見ていくと、原因の層を絞り込めます。
「サーバにつながらない」「アプリから接続できない」――このネットワーク障害は、初学者にとって最大の難所だ。原因がどこにあるか分かりにくいからだ。
だが、見方を変えれば道は開ける。つながらない原因は「経路のどこか」「相手の死活」「相手のサービス」「ファイアウォール」など、いくつかの層に分かれている。
下の層から順に1つずつ確認していけば、必ずどこで止まっているかを切り分けられる。
当てずっぽうに設定を変える前に、どの層まで到達できているかを観測で確かめる。この層ごとの切り分けが、ネットワーク障害対応の核心だ。
📡 第一段階：そもそも相手まで届いているか
最初に確認するのは、そもそも相手のホストまでパケットが届くかどうかだ。これを調べるのが ping だ。
ping 192.168.1.10 や ping example.com のように相手を指定すると、相手に小さなパケットを送って応答が返るかを繰り返し試す。
応答が返れば、少なくともネットワークの経路は通じており、相手のホストは生きている（死活が正常）と分かる。
Linuxの ping は止めるまで送り続けるので、Ctrl + c で終了する。回数を決めたいときは ping -c 4 example.com のように -c で指定する。
終了時には、送ったパケット数・受け取った数・損失率（packet loss）と、往復にかかった時間（round-trip time）の統計が表示される。
損失率が0%で時間も安定していれば経路は健全、ときどき損失が出たり時間が大きくばらついたりするなら、経路のどこかが不安定だと読み取れる。
ping に応答がない場合、原因の候補は3つだ。「ネットワークの経路が切れている」「相手のホストが落ちている（死活異常）」「途中のルータやファイアウォールが ping を遮断している」のいずれかである。
ここで切り分けを進めるには、まず自分のサーバ自身のネットワーク設定（IPアドレスが正しく振られているか）を ip a で確認し、デフォルトゲートウェイなど近い相手には届くかを試して、どこから先で途切れるかを見る。
なお、セキュリティ上の理由で ping(ICMP) だけを意図的にブロックしているサーバも多い。そのため「ping が通らない＝完全にダウン」とは限らない点には注意する。その場合は次の段階のポート確認で判断する。
🚪 第二段階：相手は生きているのに、つながらない
ping は通る（相手は生きている）のに目的のサービスにつながらない――実際にはこれがもっとも多いパターンだ。
この場合、問題はネットワークそのものではなく、その上で動くサービスの層にある。確認すべきは「相手のサーバで、目的のサービスが、目的のポートで待ち受けているか」だ。
ポートとは、1台のサーバ上で複数のサービスを区別するための番号だ。たとえばWebのHTTPは80番、HTTPSは443番、SSHは22番、といったように、サービスごとに使う番号が決まっている。
相手にパケットは届いていても、そのポートで誰も待ち受けていなければ、接続は拒否される。
🔌 第三段階：そのポートで、誰が待ち受けているか
サーバ側で「どのポートが、どのプロセスによって待ち受けられているか」を確認する定番が ss（socket statistics）だ。
ソケットとは、ネットワーク通信の出入り口を表す抽象的な仕組みだ。Linuxではこのソケットもファイルと同じように扱われ、プロセスはソケットをファイルディスクリプタ（開いているファイルやソケットに割り振られる管理番号）として保持する。
ss はそうしたソケットの状態を高速に一覧する。よく使う組み合わせが ss -tlnp で、それぞれ -t（TCP）、-l（LISTEN＝待ち受け中のものだけ）、-n（ポートを名前に変換せず数字のまま速く表示）、-p（待ち受けているプロセス名とPIDも表示）を意味する。
これを実行すると、たとえば 0.0.0.0:80 で nginx が待ち受けている、といった行が並び、「目的のポートでサービスが上がっているか」を即座に確認できる。
ここでよくある原因が2つに切り分けられる。
1つは、目的のポートが ss -tlnp の一覧に出てこないケース。これはサービス自体が起動していない（あるいは別のポートで上がっている）ことを意味し、journalctl -u サービス名 でそのサービスの起動失敗ログを確認する。
もう1つは、ローカル（127.0.0.1）でだけ待ち受けていて、外部からのアドレス（0.0.0.0 など）で待ち受けていないケース。この場合、サーバ上からはつながるのに外部からはつながらない、という症状になるので、サービスの待ち受けアドレス設定を見直す。
どちらなのかは、待ち受けアドレスの欄（127.0.0.1:80 なのか 0.0.0.0:80 なのか）で判別できる。
🧱 第四段階：最後に残る容疑者、ファイアウォール
サービスは正しいポートで待ち受けている（ss で確認できる）のに外部からつながらない場合、残る容疑者がファイアウォールだ。
サーバ自身のファイアウォール（firewalld や iptables、ufw など）が目的のポートへの通信を遮断していると、サービスは上がっていても外から到達できない。
RHEL系なら firewall-cmd --list-all で現在許可されているポートやサービスを確認でき、目的のポートが許可されていなければ、それが原因だ。
クラウド環境では、サーバ自身のファイアウォールに加えて、クラウド側のセキュリティグループ（仮想ファイアウォール）でもポートを開ける必要があるため、両方を確認する。
🪜 4つの段階を一段ずつ上がる
ネットワーク障害は、必ず下の層から順に切り分ける。
まず ping で相手まで届くか（経路と死活）を見る。届くなら ss -tlnp で目的のポートが待ち受けているか（サービスの起動と待ち受けアドレス）を見る。待ち受けているのに外からつながらなければファイアウォール（firewall-cmd やセキュリティグループ）を確認する。
この階段を1段ずつ上がることで、漠然と「つながらない」だった問題が、「経路の問題」「サービスが落ちている」「待ち受けアドレスの設定ミス」「ポートが塞がれている」のどれなのかへと、明確に切り分けられる。
どの層まで到達できたかを毎回はっきりさせるのが、遠回りしないコツだ。