ネットワーク疎通の切り分け
「つながらない」障害は、どの層で止まっているかを順に切り分けます。まず ping で相手まで届くかを確認し、応答がなければ経路や相手の死活を疑います。届くのに接続できないときは、相手側のサービスが目的のポートで待ち受けているかが問題です。ss -tlnp で自分のサーバが開いているポートとプロセスを確認し、ファイアウォールやサービスの起動状態を合わせて見ていくと、原因の層を絞り込めます。
「サーバにつながらない」「アプリから接続できない」というネットワークの障害は、原因がどこにあるか分かりにくく、初学者がもっとも苦手意識を持ちやすい領域です。しかし、つながらない原因は「経路のどこか」「相手の死活」「相手のサービス」「ファイアウォール」など、いくつかの層に分かれており、下の層から順に1つずつ確認していけば、必ずどこで止まっているかを切り分けられます。当てずっぽうに設定を変える前に、どの層まで到達できているかを観測で確かめる——この層ごとの切り分けが、ネットワーク障害対応の核心です。
第一段階：ping で相手まで届くか
最初に確認するのは、そもそも相手のホストまでパケットが届くかどうかです。これを調べるのが 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 に応答がない場合、原因の候補は「ネットワークの経路が切れている」「相手のホストが落ちている（死活異常）」「途中のルータやファイアウォールが ping を遮断している」のいずれかです。ここで切り分けを進めるには、まず自分のサーバ自身のネットワーク設定（IPアドレスが正しく振られているか）を ip a で確認し、デフォルトゲートウェイなど近い相手には届くかを試して、どこから先で途切れるかを見ます。なお、セキュリティ上の理由で ping(ICMP) だけを意図的にブロックしているサーバも多いため、「ping が通らない＝完全にダウン」とは限らない点には注意します。その場合は次の段階のポート確認で判断します。
第二段階：ホストは生きているのにつながらない
ping は通る（相手は生きている）のに目的のサービスにつながらない、というのが実際にはもっとも多いパターンです。この場合、問題はネットワークそのものではなく、その上で動くサービスの層にあります。確認すべきは「相手のサーバで、目的のサービスが、目的のポートで待ち受けているか」です。ポートとは、1台のサーバ上で複数のサービスを区別するための番号で、たとえばWebのHTTPは80番、HTTPSは443番、SSHは22番、といったように、サービスごとに使う番号が決まっています。相手にパケットは届いていても、そのポートで誰も待ち受けていなければ、接続は拒否されます。
第三段階：ss で待ち受けポートを確認する
サーバ側で「どのポートが、どのプロセスによって待ち受けられているか」を確認する定番が 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 で現在許可されているポートやサービスを確認でき、目的のポートが許可されていなければ、それが原因です。クラウド環境では、サーバ自身のファイアウォールに加えて、クラウド側のセキュリティグループ（仮想ファイアウォール）でもポートを開ける必要があるため、両方を確認します。
実務での使いどころ
ネットワーク障害は、必ず下の層から順に切り分けます。まず ping で相手まで届くか（経路と死活）→ 届くなら ss -tlnp で目的のポートが待ち受けているか（サービスの起動と待ち受けアドレス）→ 待ち受けているのに外からつながらなければファイアウォール（firewall-cmd やセキュリティグループ）を確認、という順序です。この階段を1段ずつ上がることで、漠然と「つながらない」だった問題が、「経路の問題」「サービスが落ちている」「待ち受けアドレスの設定ミス」「ポートが塞がれている」のどれなのかへと、明確に切り分けられます。どの層まで到達できたかを毎回はっきりさせるのが、遠回りしないコツです。