netstat/ss入門 - ポートと接続状態の確認方法

netstat/ss入門 - ポートと接続状態の確認方法
読了時間: 約9分 難易度: 中級

この記事で解決できること

  • netstat と ss の 使い分けと違い が分かる
  • 「どのポートで待ち受けているか」「誰が掴んでいるか」を 即確認 できる
  • 接続状態（LISTEN / ESTAB / TIME-WAIT 等）を 読み解く型 が身につく

結論（実務の型）

  • 待ち受け確認は ss -tlnp（netstat -tlnp の後継）
  • 確立済み接続は ss -tnp、全体サマリは ss -s
  • netstat が command not found でも壊れていない。ss を使えばよい

前提（対象環境）

  • OS：Ubuntu / RHEL 系など一般的な Linux
  • iproute2（ss コマンド）は標準インストール済み
  • プロセス名表示（-p）には sudo または管理権限が必要

netstat と ss は何が違うのか？

netstat は旧 net-tools パッケージ付属の古いコマンドで現在は非推奨。ss（socket statistics）は後継の iproute2 が提供し、同じ情報をより高速に取得できる。新しい環境では ss を使う。

項目 netstat（net-tools） ss（iproute2）
ステータス 非推奨・保守停止 現行・推奨
デフォルト導入 多くのモダン環境で未導入 標準導入
大量接続時の速度 遅い（/proc を逐次走査） 高速（カーネル API）
状態フィルタ 不可 state で絞り込み可

netstat が command not found になるのは故障ではなく net-tools が未導入なだけ。sudo apt install net-tools で入るが、まず ss を使うのが正攻法。

待ち受けポートはどう確認するのか？

ss -tlnp で「どのポートで何のプロセスが待ち受けているか」を一覧表示する。サービスを起動したのに繋がらない時、まずここを見れば待受の有無が一発で分かる。

$ sudo ss -tlnp
State   Recv-Q  Send-Q  Local Address:Port   Peer Address:Port  Process
LISTEN  0       4096          0.0.0.0:22          0.0.0.0:*      users:(("sshd",pid=812,fd=3))
LISTEN  0       511         127.0.0.1:3000        0.0.0.0:*      users:(("node",pid=1340,fd=18))

読みどころ:

  • LISTEN … そのポートで待ち受け中
  • 0.0.0.0:22 … 全インターフェースで 22 番を待受（外部から到達可能）
  • 127.0.0.1:3000 … ループバックのみ。外部からは繋がらない（後述）
  • Process … 掴んでいるプロセス名と PID（-p + sudo で表示）

UDP も含めて見るなら -u を足す。

$ sudo ss -tulnp

オプション -tulpn は何を意味するのか？

ss の主要オプションは1文字ずつ独立した意味を持つ。-tulpn は「TCP と UDP の待受を、名前解決せず、プロセス付きで表示」を1語にまとめた定番の組み合わせ。

オプション 意味
-t TCP ソケット
-u UDP ソケット
-l LISTEN（待ち受け）状態のみ
-n 名前解決しない（数値表示・高速）
-p 掴んでいるプロセスを表示（要 sudo）
-a 全状態（LISTEN + 確立済み等）

順番は任意で ss -tlnp と ss -plnt は同じ。-n を付けないと DNS 逆引きで遅くなるため、調査時は基本付ける。

確立済み接続はどう見るのか？

ss -tnp で現在 ESTAB（確立済み）の TCP 接続を一覧表示する。「誰がこのサーバに繋いでいるか」「アプリが外部 API へ接続できているか」を確認する時に使う。

$ sudo ss -tnp
State  Recv-Q Send-Q   Local Address:Port    Peer Address:Port  Process
ESTAB  0      0        192.168.1.20:22      203.0.113.5:51324   users:(("sshd",pid=2210,fd=4))
ESTAB  0      0        192.168.1.20:48210   10.0.0.8:5432       users:(("node",pid=1340,fd=22))
  • Local Address:Port … 自サーバ側の接続元
  • Peer Address:Port … 接続先（相手）
  • 1行目 … 203.0.113.5 から SSH（22）でログインされている
  • 2行目 … node アプリが PostgreSQL（5432）へ接続中

接続数だけ素早く把握したいなら ss -s（summary）が便利。

$ ss -s

特定ポート/プロセスはどう絞り込むのか？

ss はフィルタ式を直接書ける。grep で探す前に、sport（送信元ポート）/ dport（宛先ポート）/ state でカーネル側に絞らせると速く正確。

特定ポートで待ち受けているか:

$ sudo ss -tlnp 'sport = :80'
$ sudo ss -tlnp sport = :443

特定状態だけ抽出:

$ ss -tn state established
$ ss -tn state time-wait

特定の宛先への接続を見る:

$ ss -tn dst 10.0.0.8

127.0.0.1:3000 でしか待っていないアプリは、サーバ内部からしか到達できない。外部公開したいなら 0.0.0.0:3000（または特定 IP）で待つようアプリ側の bind 設定を変更する。ss の Local Address が 127.0.0.1 のままなら、いくらファイアウォールを開けても繋がらない。

接続状態（State）はどう読むのか？

TCP の状態は接続のライフサイクルを表す。トラブル時に頻出するのは LISTEN / ESTAB / TIME-WAIT / CLOSE-WAIT の4つ。意味を押さえると原因の当たりが付く。

State 意味 読みどころ
LISTEN 待ち受け中 サービスが上がっている
ESTAB 接続確立済み 正常に通信中
TIME-WAIT 切断後のクールダウン 大量にあっても通常は正常（短命接続が多い）
CLOSE-WAIT 相手は閉じたが自分が未close 大量増加はアプリのソケットクローズ漏れ疑い
SYN-SENT 接続要求を送って応答待ち 大量なら相手不達・FW 遮断を疑う

CLOSE-WAIT が増え続けるのはアプリのバグ（ソケットを close していない）のサイン。ss -tn state close-wait で件数とプロセスを確認する。TIME-WAIT の大量発生は多くの場合は正常で、慌てて net.ipv4.tcp_tw_reuse 等をいじらない。

netstat → ss 移行チートシート

netstat の手癖が残っていても、ss の同等コマンドを覚えれば移行できる。下表を手元に置けば困らない。

やりたいこと 旧（netstat） 新（ss）
TCP 待受一覧 netstat -tlnp ss -tlnp
TCP/UDP 待受 netstat -tulnp ss -tulnp
全接続表示 netstat -an ss -an
確立済み接続 netstat -tnp ss -tnp
接続数サマリ netstat -s ss -s
ルーティング表 netstat -rn ip route 
# コピペ用：状態把握ワンライナー
sudo ss -tulnp && ss -s

ss -tlnp | grep ':80 ' のような grep 併用も有効だが、ss -tlnp 'sport = :80' の方がカーネル側で絞れて速く誤検出も少ない。

次に読む