ssとnetstatの使い分け完全整理

URLをコピーしました！

Linuxで通信トラブルを調査する際、必ず登場するのが ss と netstat です。

しかし現場では、

どちらを使うべきか分からない
出力の違いが理解できていない
古い手順がそのまま残っている

といった理由で、調査が遠回りになるケースが少なくありません。

本記事では、ss と netstat の違い・役割・使い分けを、実務デバッグ視点で完全整理します。

結論：基本は ss、netstat は補助

先に結論です。

通常調査 → ss
古い手順・資料確認 → netstat

理由は後述しますが、ss は設計思想が新しく、情報が正確です。

ss と netstat の成り立ちの違い

netstat

古くから使われている
net-tools パッケージ
/proc を直接参照

現在は 非推奨（deprecated） 扱いです。

ss

iproute2 パッケージ
カーネル情報を直接取得
高速・正確

RHEL / Rocky / Ubuntu など、現在の主流は ss です。

表示速度と正確性の違い

接続数が多いサーバで実行すると違いが明確です。

# netstat（遅い）
netstat -an

# ss（高速）
ss -an

netstat が固まるが ss は即返る、という経験がある人も多いはずです。

基本的な対応コマンド比較

用途	netstat	ss
全接続表示	netstat -an	ss -an
TCPのみ	netstat -ant	ss -ant
LISTEN確認	netstat -lnt	ss -lnt
プロセス表示	netstat -anp	ss -anp

基本オプションは似ていますが、細かい意味は異なります。

実務でよく使う ss コマンド集

LISTENポート確認

ss -lntp

待受ポート
プロセス名・PID

ESTABLISHED 接続数確認

ss -ant state established

コネクション増加トラブル時の基本です。

特定ポートの接続確認

ss -ant '( sport = :443 or dport = :443 )'

netstat ではできない柔軟な条件指定が可能です。

TIME_WAIT / CLOSE_WAIT 調査での違い

netstat

netstat -ant | grep TIME_WAIT | wc -l

ss

ss -ant state time-wait | wc -l

ss の方が 状態指定が明確で、grep事故が起きません。

プロセス特定の精度差

大量接続時、netstat の -p は失敗することがあります。

netstat -anp

一方 ss は安定しています。

ss -anp

PID調査は ss 一択です。

netstat を使うべきケース

古い手順書・運用フローが netstat 前提
チーム内共通認識が netstat
一時的な確認

ただし、新規手順では使わない方が無難です。

ss を使うべきケース

大量接続環境
TIME_WAIT / CLOSE_WAIT 調査
Kubernetes / LB 配下
プロセス特定が必要

現代的なLinuxトラブルシュートは ss 前提です。

よくある誤解

「netstat の方が分かりやすい」→ 慣れの問題
「ss は情報が少ない」→ オプション不足

ss は出さないのではなく、要求しないと出さない設計です。

まとめ

ss は新標準、netstat は旧来ツール
正確性・速度・柔軟性は ss が上
実務調査は ss を軸に組み立てる

通信トラブル調査の精度は、
どのコマンドを使うかで大きく変わります。