ポートと待ち受け状態の確認
サービスが正しく起動しても、想定したポートで待ち受けていなければ通信できません。ss コマンドで「いまどのポートが開いて待ち受けているか」を一覧できます。-l で待ち受け中（LISTEN）のソケット、-t でTCP、-n で名前解決せず番号表示、-p でどのプロセスかを確認します。Webサーバなら 80番、SSHなら 22番が LISTEN になっているのが正常です。
サービスを起動し、ファイアウォールも開けた。それでも通信できないとき、次に疑うべきはどこか。確かめるべきは「サービスが本当に、想定したポートで待ち受けているか」だ。
ここで鍵になるのがポートという概念である。1台のサーバには多数のサービスが同居できるが、ネットワークから届いた通信を、どのサービスが受け取るのかを区別するために、通信の窓口ごとに番号が割り当てられている。これがポート番号だ。
たとえばWebサーバ（HTTP）は80番、HTTPSは443番、SSHは22番、といった具合に、サービスごとに使うポートが決まっている。
サービスが起動すると、自分の担当ポートを開いて接続を待つ状態になる。この「接続を待っている状態」をLISTEN（待ち受け）と呼ぶ。
逆にいえば、LISTENになっていないサービスは、いくら外から叩いても返事をしてくれない。
🏷 ポート番号には縄張りがある
ポート番号は0番から65535番まであり、用途によって大きく3つの帯に分かれている。
0番から1023番は「ウェルノウンポート」と呼ばれ、HTTPの80番・HTTPSの443番・SSHの22番・DNSの53番のように、主要なサービスにあらかじめ割り当てられている。
この帯のポートで待ち受けるには管理者権限が必要で、一般ユーザの権限ではサービスを起動できない。
1024番以降はアプリケーションが比較的自由に使える帯で、たとえば開発中のWebアプリを8080番で動かす、といった使い方をする。
サーバを構築するときは「このサービスは何番を使うのか」を意識し、その番号で正しく待ち受けているか、そしてその番号がファイアウォールで開いているかを、セットで確認していくことになる。この2つがそろって初めて、外からの通信が届く。
🔍 何が待ち受けているかを覗く ss
いまサーバ上でどのポートが開いて待ち受けているか。それを見せてくれるのが ss コマンドだ。よく使うのは、いくつかのオプションを組み合わせた ss -ltnp という形である。
それぞれの意味は次のとおりだ。-l は待ち受け中（LISTEN）のソケットだけに絞る指定、-t はTCPのソケットを対象にする指定、-n はポートやアドレスを名前に変換せず番号のまま表示する指定、-p はそのポートをどのプロセスが使っているかを表示する指定だ。
-p はプロセス情報を見るため管理者権限が要ることが多く、一般ユーザでは sudo ss -ltnp のように sudo を付ける。
実行すると、Local Address:Port の列に 0.0.0.0:80 や *:22 のような形で待ち受けポートが並び、Process の列に nginx や sshd といったプロセス名が表示される。
UDPで待ち受けるサービス（DNSなど）も調べたいときは、-t の代わりに -u を使った ss -lunp とする。
👀 出力のどこを読むのか
まず注目するのは、State 列が LISTEN になっている行だ。これが「いま接続を待っている」ポートである。
Local Address:Port の見方も重要だ。0.0.0.0:80 や *:80 はすべてのネットワークインターフェースで80番を待ち受けていることを意味し、外部からも接続を受け付けられる状態だ。
一方 127.0.0.1:80 のように表示されている場合は、ループバック（自分自身）だけで待ち受けており、ほかの端末からは接続できない。
Webサーバが localhost からは見えるのに外から見えないとき、ファイアウォールだけでなく、この「待ち受けアドレスがローカルホストに限定されている」可能性も疑う必要がある。
IPv6 では :::80 のようにコロンが連なった表記になるが、考え方は同じだ。
Process 列を見れば、その80番を本当に意図したWebサーバが握っているのか、別のプロセスが横取りしていないかも分かる。意図しないプロセスがポートを握っていれば、それを止めてから本来のサービスを起動し直す、という対処につながる。
🟢 正常な姿を知っておく
正しく構築できているとき、ss の出力はどう見えるか。Webサーバを起動したサーバでは80番（HTTPSも設定していれば443番）が、SSHを有効にしたサーバでは22番が、それぞれ LISTEN で並んでいるのが正常な姿だ。
逆に、起動したはずのサービスのポートが ss の一覧に出てこなければ、そのサービスは実際には起動に失敗しているか、別のポートで待ち受けているか、設定で待ち受けが無効になっている、と判断できる。
特定のポートだけを手早く見たいときは ss -ltnp | grep :80 のように grep で絞り込むのが実務での常套手段だ。
すべてのソケットを状態込みで見たいときは ss -a、TCPの確立済み接続まで含めて眺めたいときは ss -t のように、目的に応じてオプションを足し引きする。
なお、ss はかつて広く使われた netstat の後継にあたるコマンドで、現在のRHEL系では ss を使うのが標準だ。netstat に慣れた人は netstat -ltnp と ss -ltnp がほぼ同じ意味になる、と読み替えると移行しやすい。
⚠ つまずいたら、まずこれ
切り分けの場面でありがちな失敗は、サービスの起動・ファイアウォール・待ち受け状態の3つを混同し、当たりをつけずに手当たり次第に設定をいじってしまうことだ。
ss はこの切り分けを一段はっきりさせてくれる。「ポートが LISTEN に出ているか」を見れば、問題がサービス側（そもそも起動・待ち受けできていない）なのか、ネットワーク側（待ち受けてはいるが外から届かない＝ファイアウォール等）なのかを、明確に分けられる。
実務での定番の手順はこうだ。まず systemctl status でサービスが動いているかを確かめ、次に ss -ltnp で狙ったポートが待ち受けているかを確認し、サーバ自身から curl http://localhost で応答が返るかを見て、それでも外部から繋がらなければファイアウォールを疑う。内側から外側へたどっていく。
「サービス→ポート→自分からの応答→ファイアウォール」と層を分けて確認する習慣が、原因切り分けの最短経路になる。