サーバーを運用していて、「あのポートは本当に開いているのか？」「通信がうまくいかないのはポートのせいなのか？」と疑問に思ったことはありませんか。
セキュリティ設定やサービスの動作確認をするうえで、ポート状態を把握することは欠かせません。
そこで登場するのが、Linuxで使える便利なコマンドである「ss」と「netstat」です。どちらもポートの状態や通信の様子を確認できるツールですが、RHEL系Linuxでは少し事情が異なります。
実は「netstat」は古い仕組みに依存しており、現在は非推奨となっているのです。その代わりに登場した「ss」は、より高速で詳細な情報を取得できるコマンドとして公式に推奨されています。
では、具体的にどのような違いがあり、どんな場面で使うべきなのでしょうか。
本記事では、RHEL系環境を前提に「ss」と「netstat」を比較しながら、ポート状態を確認する実践的な方法を解説していきます。
Linuxの基礎知識
└─【Linuxの基礎知識】ネットワーク系でよくあるトラブルと解決の入口
├─ 【Linuxの基礎知識】ネットワーク設定とトラブルシューティングを徹底解説！
├─ 【Linuxの基礎知識】tcpdumpの使い方と通信トラブルの本質的な見方
├─ 【Linuxの基礎知識】ping / tracerouteでわかるネットワーク診断の基本
├─ 【Linuxの基礎知識】dig / host / nslookupの違いとDNSトラブル調査法
├─ 【Linuxの基礎知識】nmapの使い方とセキュリティ確認の実践
└─ 【Linuxの基礎知識】ss / netstatでポート状態を確認する方法
ss / netstatコマンドとは？
Linuxのサーバー管理では「特定のポートが開いているか」「どのプロセスが利用しているか」を確認することがよくあります。
一般的によく使われるのが「ss」と「netstat」というコマンドです。
RHEL系Linuxではssを前提とした記述に触れる機会がある一方で、既存のシステムでは今でもnetstatが使われています。実務の現場ではssとnetstatの両方に関する知識が求められる場面があり、どちらか一方しか知らないと対応が難しくなることがあります。
本記事では、そうした背景を踏まえてnetstatにも触れながら、現在利用されることが多いssを中心に解説していきます。
基本概要と位置づけ
netstatは古くから使われてきたコマンドで、ソケットやルーティング情報を確認するために広く利用されてきました。既存の資料やスクリプトで目にする機会も多く、今でも実務で遭遇することがあります。
ssはiproute2に含まれるコマンドで、netstatと同様の情報をより高速かつ柔軟に取得できます。RHEL系Linuxでは標準で導入されており、現在の環境で主に利用されるコマンドになっています。
取得できる情報の種類
ssとnetstatはいずれもソケットやポートに関する情報を得るために使います。代表的な情報は以下のとおりです。
| 情報の種類 | 説明 |
|---|---|
| 待ち受けポート | サービスがどのポートで待機しているかを確認 |
| 接続中のセッション | クライアントとサーバー間の通信状態を確認 |
| プロセスとの対応 | どのプロセスがポートを利用しているかを確認 |
| 統計情報 | TCPやUDPのセッション数を集計 |
利用するメリットと違い
ssは動作が軽く、詳細なフィルタリングや追加情報の表示に優れています。netstatは古いながらも使い慣れている管理者が多く、既存の運用資料に記載されている場合に理解しておく必要があります。
| 項目 | ss | netstat |
|---|---|---|
| 速度 | 高速 | 比較的遅い |
| 情報量 | 詳細な出力が可能 | 基本的な出力に限られる |
| 現場での位置づけ | 現在の標準 | 既存システムに残存 |
ss / netstatの導入手順
ここではRHEL系Linuxでssとnetstatを利用するための導入手順を説明します。ssは標準で含まれていることが多いですが、環境によっては確認が必要です。netstatは別途パッケージの導入が必要になります。
ssの導入手順
ssはiproute2パッケージに含まれており、RHEL系Linuxでは通常デフォルトで導入されています。まずはバージョン情報を確認して利用可能か確かめます。
ss -V
【出力例:】
ss utility, iproute2-ss200127
もしコマンドが見つからない場合は、iproute2パッケージをインストールすることで利用できます。
dnf install -y iproute
【出力例:】
Dependencies resolved.
===================================================================
Package Arch Version Repository Size
===================================================================
Installing: iproute x86_64 5.18.0-3.el9 baseos 1.2 M
Transaction Summary
Install 1 Package
インストール後に再度バージョンを確認すれば、導入が完了していることを確認できます。
ss -V
netstatの導入手順
netstatはnet-toolsパッケージに含まれます。RHEL8以降では標準でインストールされていないため、必要に応じて導入します。
dnf install -y net-tools
【出力例:】
Dependencies resolved.
===================================================================
Package Arch Version Repository Size
===================================================================
Installing: net-tools x86_64 2.0-0.62.20160912git.el8 baseos 322 k
Transaction Summary
Install 1 Package
導入後に動作を確認します。
netstat --version
【出力例:】
net-tools 2.0
初期動作確認
両方のコマンドが正しく利用できるか、簡単に動作を確認します。
ss --help
【出力例:】
Usage: ss [ OPTIONS ] [ FILTER ]
-h, --help this message
-V, --version output version information
-a, --all display all sockets
netstat --help
【出力例:】
usage: netstat [-vWeenNcCF] [] -r
netstat [-vWnNcaeol] [ ...]
ss / netstatの基本的な使い方
ここではssとnetstatを使ったポート確認方法を紹介します。オプションについては共通するものを一覧表にまとめ、それ以外の具体的な利用例は両者を完全に分けて解説します。
| 用途 | ss | netstat | 説明 |
|---|---|---|---|
| 全ソケットの表示 | -a | -a | すべてのソケットを表示します。LISTEN状態とESTABLISHED状態を含みます。 |
| 待ち受けポートの表示 | -l | -l | サービスが待機しているポートを確認します。 |
| 数値での表示 | -n | -n | ホスト名やサービス名に変換せず、数値で表示します。 |
| TCPのみ | -t | -t | TCPソケットに限定して表示します。 |
| UDPのみ | -u | -u | UDPソケットに限定して表示します。 |
| プロセス情報 | -p | -p | 各ソケットを利用しているプロセスを表示します。 |
| 統計情報 | -s | -s | ソケットの利用状況を統計的に表示します。 |
ssコマンドの使い方
ssは現在のRHEL系Linuxで広く利用されているソケット調査ツールです。表示が高速で、詳細な情報を得られるのが特徴です。
接続中ソケットの確認（ss）
ss -tn
【出力例:】
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 192.168.1.10:22 192.168.1.20:54321
ESTAB 0 0 192.168.1.10:443 192.168.1.30:50211
待ち受けポートの確認（ss）
ss -lnt
【出力例:】
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:*
プロセスや詳細情報の表示（ss）
ss -lptn
【出力例:】
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1123,fd=3))
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("httpd",pid=2045,fd=5))
IPv4とIPv6の切り替え（ss）
ss -4 -lnt
ss -6 -lnt
【出力例:】
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 128 [::]:22 [::]:*
netstatコマンドの使い方
netstatは長く使われてきた定番ツールです。現在は非推奨ですが、既存のシステムや古い手順書では依然として使われているため、知識を持っておく必要があります。
接続中ソケットの確認（netstat）
netstat -tn
【出力例:】
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 192.168.1.10:22 192.168.1.20:54321 ESTABLISHED
tcp 0 0 192.168.1.10:443 192.168.1.30:50211 ESTABLISHED
待ち受けポートの確認（netstat）
netstat -lnt
【出力例:】
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
プロセスや詳細情報の表示（netstat）
netstat -lntp
【出力例:】
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1123/sshd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 2045/httpd
IPv4とIPv6の切り替え（netstat）
netstat -4 -lnt
netstat -6 -lnt
【出力例:】
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 [::]:22 [::]:* LISTEN
ss / netstatの応用的な活用方法
基本的な使い方を理解していると、サービスの死活確認や障害対応に即座に役立てることができます。ここでは、現場で一歩進んだ使い方をするための実践的な活用方法を紹介します。
長時間の監視とログ保存
サーバーのポートが断続的に不安定になる場合、短時間の確認では原因を特定できません。ssやnetstatを定期的に実行してログとして保存することで、後から「いつ接続が切れたか」を振り返ることができます。
while true; do ss -s >> /var/log/ss_monitor.log; sleep 60; done &
【出力例:】
Total: 150 (kernel 160)
TCP: 12 (estab 10, closed 0, orphaned 0, synrecv 0, timewait 2/50)
Transport Total IP IPv6
RAW 0 0 0
UDP 5 3 2
TCP 12 12 0
このようにログを溜めることで、障害の時間帯や頻度を把握できるようになります。
特定サービスの切り分け
特定のポートやプロセスに絞り込むことで、複数サービスが動いている環境でも対象を明確にできます。これは「どのプロセスがどのポートを専有しているか」を把握する上で大きなメリットがあります。
ss -lptn 'sport = :80'
【出力例:】
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("httpd",pid=2045,fd=5))
これにより「ポート80を利用しているのはhttpdである」と即座に確認できます。
統計情報によるボトルネック把握
ssやnetstatの統計表示は「どのプロトコルに負荷が集中しているか」を把握するのに便利です。数値を見続けることで、どの層で遅延や不具合が発生しているのかを切り分けられます。
netstat -s
【出力例:】
Tcp:
105 active connections openings
98 passive connection openings
3 failed connection attempts
2 connection resets received
Udp:
220 packets received
220 packets sent
これにより、TCPの接続失敗やリセットが多い場合はアプリケーションやネットワーク機器を疑うなど、調査の指針が得られます。
cronによる定期実行
定期的にログを取るには、cronへの登録が有効です。障害が夜間や休日に発生しても、記録を残しておけば原因分析に活かせます。
*/5 * * * * ss -s >> /var/log/ss_monitor.log
これにより5分ごとにソケット統計を保存できます。ログをグラフ化すれば、トラフィックの変化や異常の兆候を早期に把握できます。
実践的な活用例
ssやnetstatは単なる情報取得コマンドではなく、障害対応や運用現場で役立つ実践的な活用方法があります。ここではトラブルシュートと特定ポートの開放確認という2つのシーンを取り上げ、どのようにメリットを得られるかを解説します。
トラブルシュートでの利用
通信エラーが発生したとき、ネットワークが原因なのかアプリケーションが原因なのかを切り分ける必要があります。
ssやnetstatを使えば、接続状態を素早く可視化でき、どの段階で問題が生じているかを判断する材料になります。
ss -tn
【出力例:】
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 192.168.1.10:22 192.168.1.20:54321
SYN-SENT 0 1 192.168.1.10:443 192.168.1.50:50123
この例では、SSHは正常に確立（ESTAB）している一方で、HTTPS接続はSYN送信のまま応答がありません。
これにより、アプリケーションの不具合ではなく、ネットワークやファイアウォールの問題を疑うべきと判断できます。
同様にnetstatでも確認可能です。
netstat -tn
【出力例:】
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 192.168.1.10:22 192.168.1.20:54321 ESTABLISHED
tcp 0 1 192.168.1.10:443 192.168.1.50:50123 SYN_SENT
両者を使い分けることで、切り分けスピードが格段に上がり、復旧までの時間短縮につながります。
特定ポートの開放確認
新しいサービスを立ち上げたとき、そのポートが正しく待ち受け状態になっているかを確認することは欠かせません。
設定を誤っていれば外部から接続できず、サービスイン直後にトラブルになる可能性があります。
ss -lnt 'sport = :5432'
【出力例:】
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 0.0.0.0:5432 0.0.0.0:*
この出力から、PostgreSQLがポート5432で待ち受けていることが確認できます。ユーザーにとっては「設定が正しく反映されている」という安心感が得られる点が大きなメリットです。 netstatでも同様に確認できます。
netstat -lnt | grep 5432
【出力例:】
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:5432 0.0.0.0:*
LISTEN これにより「サービスが起動し、ポートが開放されている」ことを即座に把握できます。外部からの疎通確認と組み合わせることで、ネットワーク全体の健全性を保証できます。
利用時の注意点
ssやnetstatは便利なコマンドですが、利用にあたっては注意すべき点があります。ここでは、現場で混乱を避けるために押さえておきたい2つの観点を解説します。
netstat非推奨と移行の必要性
netstatは長年使われてきた定番コマンドですが、RHEL系Linuxを含む多くの環境で非推奨となっています。これは、開発が止まっており、最新の機能や改善が反映されないためです。そのため、新しい環境ではssを使うことが求められます。
しかし、既存のシステムや古い手順書には今でもnetstatが前提となっているケースが数多く残っています。このため、移行期にある現場では両方のコマンドを理解しておくことがメリットとなります。ssをメインに使いながらも、netstatを知らないと既存環境のトラブル対応で手詰まりになることがあります。
移行を進める上では、運用スクリプトや監視ジョブをnetstatからssに置き換えていくのが望ましいです。これにより将来的な保守性が高まり、環境依存のトラブルを避けることができます。
出力ログの管理と影響
ssやnetstatは手元での確認だけでなく、定期的に実行してログを残す使い方も多くの現場で採用されています。ただし、無制限に出力を保存してしまうとログファイルが肥大化し、ディスクを圧迫して逆にシステム障害の原因になりかねません。
*/5 * * * * ss -s >> /var/log/ss_monitor.log
【出力例:】
Total: 150 (kernel 160)
TCP: 12 (estab 10, closed 0, orphaned 0, synrecv 0, timewait 2/50)
UDP: 5
RAW: 0
このようにcronで定期収集する場合は、logrotateなどで古いログを自動的に圧縮・削除する仕組みを必ず組み込むべきです。
また、詳細情報を出力するオプション（例: -p や -e）はプロセス情報や内部構造を含むため、外部に流出するとセキュリティリスクになります。保存先の権限管理やマスキング処理も併せて検討する必要があります。
ログ管理を適切に行うことで、過去の通信状態を分析できる一方、システム資源やセキュリティを損なわずに済むという大きなメリットがあります。
まとめ
ssとnetstatはいずれもLinuxにおけるポートやソケットの状態確認に欠かせないコマンドです。RHEL系Linuxではssが中心となっていますが、実務の現場では依然としてnetstatの知識が求められる場面もあります。どちらか一方だけを理解していると、既存システムや過去の手順に対応できない可能性があるため、両方のコマンドを知っておくことに大きな意味があります。
ssは高速かつ詳細な情報を提供でき、統計やフィルタリングによって効率的な調査が可能です。netstatは互換性や長年の実績があり、古い環境やドキュメントを読む際に役立ちます。利用シーンに応じて適切に使い分けることで、トラブルシュートの時間を短縮し、サービスの安定運用につなげられるというメリットがあります。
さらに、長期的な監視やログ管理と組み合わせることで、突発的な障害に対しても迅速に原因を特定できる体制を整えられます。ssやnetstatを単なる確認コマンドとして捉えるのではなく、日々の運用に組み込むことで、システムの信頼性と安全性を高めることが可能です。
これまで解説した内容を踏まえ、実際の現場ではssを主軸に据えつつ、netstatを理解しておくことで幅広い状況に対応できるようになります。これがエンジニアにとって大きな武器となり、トラブル対応や運用効率の改善につながります。
