ss vs netstat：どちらのLinuxポート確認コマンドを使うべきか

結論から言えばssを使いましょう。すべてのモダンなLinuxディストリで現行の標準であり、netstatはそこではレガシーです。 Ubuntu、Fedora、Debianではnetstatバイナリは任意パッケージのnet-toolsに追いやられ、一方ssはiproute2に組み込まれ、どこにでも入っています。さらにssはビジーなサーバで速い——/procをファイル単位でなぞるのではなく、カーネルからソケット統計を直接読むためです。難点は構文。-tulpnの意味は環境ごとに同じとは限らず、このガイドでは正確なフラグ対応表、覚えておく価値のあるコマンド、そして深夜2時のインシデント最中に出てくる疑問への答えを提供します。

netstatは非推奨なのか？

Linuxでは、実質的にYes。netstat、ifconfig、routeを含むnet-toolsパッケージは何年もモダンなカーネル機能を追いかけておらず、主要ディストリのどれでもデフォルトではインストールされません。存在はし、動きもしますし、アンインストールすべきものでもありません。ただ、新機能が降りてくるのはiproute2（ssとipの背後にあるパッケージ）だけです。

実務上の帰結は3つ：

1. 新規インストールには存在しない。 デフォルトのUbuntu 24.04やFedoraサーバには、手動でnet-toolsを入れるまでnetstatがありません。「netstatの代替」を探す人が多いのは、バイナリが単純に無いからです。
2. モダンなソケット情報が取れない。 netstatはTCP Fast Openやサブフローレベルのソケット統計、cgroup単位のソケット帰属といった機能より前の産物です。ssはこれらをネイティブにレポートします。
3. Windowsは例外。 Windowsではnetstatは健在で、netstat -anoは今もPIDとリッスンポートを対応付ける標準手法です。非推奨の物語はLinuxだけの話です。

Linuxのssコマンドとは何か？

ssは「socket statistics」の略です。TCP、UDP、Unixソケットすべてに関するカーネルの見方——状態、アドレス、ポート、プロセス、タイマー、キューの深さ——をダンプします。主力の形はこれ：

# リッスン中のすべてと、それを占有するプロセス
sudo ss -tulpn

フラグを分解すると、TCP（-t）、UDP（-u）、リッスン中ソケットのみ（-l）、プロセス表示（-p）、名前解決しない数値出力（-n）。-pにはsudoが効いてきます。root権限がなければ、ポートは見えても自分が所有しないソケットのプロセス名は出ません。

ほとんどの仕事をカバーする、あと2つのワンライナー：

# ポート443との確立済み接続すべて、プロセス付き
sudo ss -tnp 'sport = :443 or dport = :443'

# サマリー表示：各状態のソケット数
ss -s

このフィルタ構文は、netstatの「grepして祈る」方式に対する本物のアップグレードです。カーネル内で実行されるため、テキストマッチではなく正確に絞り込めます。

ポートを使っているプロセスを調べるには？

これが両ツールに手を伸ばすきっかけとして最も多い問い合わせです。ssなら：

sudo ss -ltnp 'sport = :8080'

開発サーバが動いているマシンでの出力例：

State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN  0       511     *:8080              *:*               users:(("node",pid=214113,fd=18))

users:(...)フィールドにプロセス名とPIDが直接入っています。2本目のコマンドは不要です。ポートは塞がっているのにプロセスが表示されない場合、たいてい別のネットワーク名前空間（コンテナ）がソケットを掴んでいるケースです。ホスト側からsudo ss -ltnpを実行してプロセス列が空のポートを探し、docker psと照らし合わせるか、nsenterでコンテナの名前空間に入りましょう。

専用ツールがお好みなら、sudo lsof -i :8080 -sTCP:LISTENが同じ仕事をします。macOSと多くのBSDで同じように動くため、ランブックに生き残り続けているのです。ただしLinuxでは、ssは最初から入っています。

ssとnetstatの違いは何か？

同じ仕事、違う配管。netstatはユーザー空間でproc/net/tcpを漁り、ssはnetlinkでカーネルに直接問い合わせます。だからソケット5万本のサーバでssはミリ秒で返り、netstatは返りません。日々の運用で効いてくるのはフラグの違いです。モニターに貼る価値のある対応表がこれ：

したいこと	netstat	ss
リッスン中のTCPポート＋プロセス	netstat -tlpn	ss -tlpn
すべてのTCP＋UDP接続	netstat -tulpna	ss -tulpna
ルーティングテーブル	netstat -r	ip route
インターフェース統計	netstat -i	ip -s link
カーネルのソケットサマリー	—	ss -s
ポートでカーネル内フィルタ	—	ss -tnp 'sport = :22'

最初の2行が同一であることに注目してください。幸運なことに、ssの短いフラグはよくあるケースでnetstatと揃っているため、筋肉の記憶はだいたい移行を生き延びます。下の行こそnetstatに答えの無い領域です。ルーティングとインターフェースの仕事はipコマンドへ移り、サマリーとフィルタの行はssにしか存在しません。

それでもnetstatを使うべき場面は？

正直なところ2ケース。第一に移植性です。Linux、AIX、古めのBSDが混在するフリートでは、netstatが唯一どこにもいる構文です。第二に、古いランブックでの筋肉記憶の連続性。ランブックがnetstat -tlpnと書いていて、箱にnet-toolsが入っていれば、普通に動きます。

それ以外ではssに寄せてランブックを更新しましょう。サーバ上でランブックを書き直す作業の傍らにあると便利なのがjournalctlチートシートです。起動しないサービスを診るとき、ポート確認と自然にペアになります：/en/blog/2026-09-02/journalctl-cheat-sheet。

ssコマンドが見つからないのはなぜ？

あなたが非常に古いディストリ（2007年以前、iproute2が標準になる前）にいるか、それよりずっと可能性が高いのですが——そもそもLinuxにいないからです。ssはmacOSのコマンドではありません。macOSはlsofとnetstatを積んでいますがssは無い。BSDもだいたい同じです。Windowsではnetstat -anoかPowerShellのGet-NetTCPConnectionを使いましょう。

本当にLinux上にいてssが無いなら、iproute2を入れます：

sudo apt install iproute2    # Debian/Ubuntu
sudo dnf install iproute2    # Fedora/RHEL

30秒でわかる結論

Linuxではnetstatよりss、毎回です。プリインストール済み、より速い、カーネル内フィルタ可能。netstat -tlpnはss -tlpnへ、プロセス探しはsudo ss -ltnp 'sport = :PORT'へ、ルーティングテーブルは今やip routeの領分。netstatはクロスプラットフォームのスクリプトと古い筋肉記憶のために取っておき、フラグ対応表はこのページに取っておきましょう。