最終更新日 2025年1月29日
ss コマンドとは？
ss（Socket Statistics）コマンドは、Linuxで現在のネットワーク接続の状態を確認するためのツールです。
サーバーの運用やネットワークのトラブルシューティングの際に、接続状況を素早く把握するのに役立ちます。
このコマンドを使うことで、以下のような情報を取得できます。
- サーバーが待機しているポート（LISTEN状態）の確認
- 現在接続中のクライアント（ESTABLISHED状態）の把握
- 受信・送信キューのデータ量の確認（通信の遅延や詰まりの検出）
- どのプロセスがどのポートを使用しているかの特定
以前は netstat コマンドがネットワーク状態の確認に広く使われていましたが、ss は より高速かつ詳細な情報を取得できる ため、現在では netstat の代替として推奨されています。
SSコマンドの概要については下記で紹介しているので興味があったら見てみてください！
ss コマンドを活用したトラブルシューティング
サーバーを運用していると、ネットワークの問題に直面することは避けられません。
ここでは、実際に発生したトラブルと、その際に ss コマンドを使ってどのように対処したかを紹介します。
- サーバーが特定のポートでリスニングしていない場合の対処
- 不審な接続や大量の接続を検出
- TIME-WAITやCLOSE-WAITが大量に発生している
- スクリプトを使ったネットワーク監視の自動化の事例
- 特定のIPアドレスが大量の接続を占有していた
Webサーバーに接続できない
【トラブル発生】Webサーバーに接続できない
ある日、運用しているWebサーバーにアクセスしようとしたところ、「接続できません」 というエラーが発生しました。ブラウザで確認しても、Webサイトが表示されません。
【原因調査】ss コマンドでポートの状態を確認
まず、サーバーがポート80（HTTP）または443（HTTPS）でリスニングしているかどうかを確認しました。
ss -tln | grep ':80\|:443'しかし、何も表示されませんでした。
この結果から、Webサーバー（NginxまたはApache）がポートを開いていないことが分かりました。
【対処】サービスの状態を確認し再起動
次に、Webサーバーのプロセスが正しく動作しているかを確認しました。
systemctl status nginxすると、サービスが停止していました。原因は、サーバーの再起動後に自動起動が設定されていなかったことでした。
以下のコマンドでWebサーバーを再起動しました。
sudo systemctl start nginxさらに、次回のサーバー再起動後も自動的に起動するように設定しました。
sudo systemctl enable nginx再度 ss -tln を実行すると、ポート80と443でリスニングが確認でき、サイトへのアクセスが正常に復旧 しました。
不審な接続や大量の接続を検出
【トラブル発生】サーバーのレスポンスが異常に遅い
ある日、サーバーのレスポンスが極端に遅くなる問題が発生しました。
特に、SSHでのログインが異常に遅くなり、Webサイトの読み込みも時間がかかる状態でした。
【原因調査】大量の不審な接続を発見
まず、サーバーへの確立済みの接続を確認しました。
ss -tan state establishedすると、以下のような出力が得られました。
ESTAB 0 0 192.168.1.10:22 203.0.113.200:54321
ESTAB 0 0 192.168.1.10:80 45.67.89.123:65432
ESTAB 0 0 192.168.1.10:80 45.67.89.124:65433
ESTAB 0 0 192.168.1.10:80 45.67.89.125:65434
ESTAB 0 0 192.168.1.10:80 45.67.89.126:65435
...
※GlobalIPアドレスは仮の値に変更しています。短時間で同じIPアドレスの範囲から大量の接続 が発生していました。
さらに、ss -tan | grep '45.67.89' で詳細を確認すると、数百件の接続 が確認されました。
【対処】不審なIPアドレスをブロック
このIPアドレスが不審なアクセスである可能性が高いため、ファイアウォールでブロックしました。
sudo iptables -A INPUT -s 45.67.89.0/24 -j DROPまた、fail2ban を導入し、不正な接続を自動的にブロックするように設定しました。
sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2banこの対応後、サーバーの負荷が大幅に軽減され、レスポンスも正常に戻りました。
TIME-WAITやCLOSE-WAITが大量に発生している
【トラブル発生】サーバーの接続数が異常に増加し、新しい接続が確立できない
深夜、サーバーが異常に重くなり、Webサイトが開けない状態になりました。
ログを調査すると、新しい接続を受け付けることができず、サービスが停止していました。
【原因調査】TIME-WAIT の増加を確認
まず、ss コマンドで TIME-WAIT 状態の接続数を調査しました。
ss -tan state time-wait | wc -lすると、TIME-WAIT 状態の接続が 5000 件以上 も存在していることが分かりました。
【対処】TCPの設定を最適化
TIME-WAIT が過剰に発生する原因は、短時間で大量の接続が行われ、サーバーがリソースを解放しきれない状態 になっていたためです。
そのため、以下の設定を適用しました。
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycleさらに、sysctl.conf に設定を追加して、永続化しました。
sudo nano /etc/sysctl.conf以下の設定を追加しました。
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1下記コマンドで設定を反映します。
sudo sysctl -pこの設定を適用後、ss -tan state time-wait | wc -l を再度実行したところ、TIME-WAIT の接続数が大幅に減少 し、新しい接続がスムーズに確立できるようになりました。
実際の業務でも役立つ場面が多いため、ぜひ活用してください。
スクリプトを使ったネットワーク監視の自動化の事例
【体験談】ある日、サーバーの通信が突然不安定に…
以前、運用していたサーバーで、特定の時間帯に通信が不安定になる という問題が発生しました。
日中は問題なく動作しているのに、夜間になると突然レスポンスが遅くなるという事象でした。
【原因調査】リアルタイムで接続数を監視する必要があった
この問題の原因を特定するため、ss コマンドを使って、サーバーの確立済み接続（ESTABLISHED）を監視することにしました。
しかし、手動で ss -tan を何度も実行するのは非効率だったため、リアルタイムで変化を監視する方法を考えました。
【対処】watch コマンドを使ったリアルタイム監視
以下のコマンドを実行し、1秒ごとに確立済みの接続数を表示 するようにしました。
watch -n 1 'ss -tan state established | wc -l'このコマンドを実行すると、現在のアクティブな接続数が1秒ごとに更新されて表示 されます。
これにより、夜間に特定の時間帯で異常な接続数の増加があることを確認できました。
【さらなる対策】cron を使ってログを記録
リアルタイム監視だけではデータが残らないため、cron ジョブを使って定期的にログを記録 するスクリプトを作成しました。
1．network_log.sh というスクリプトを作成
#!/bin/bash<br>TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S")
CONNECTIONS=$(ss -tan state established | wc -l)
echo "$TIMESTAMP - Active Connections: $CONNECTIONS" >> /var/log/network_monitor.log2．cron に登録し、1分ごとに接続数を記録
crontab -e3．以下の行を追加
* * * * * /path/to/network_log.sh
※/path/to/network_log.sh はスクリプトの実際のパスこの設定を適用した結果、夜間に特定のIPアドレスから異常な接続が急増していることが判明 しました。
すぐに iptables で問題のIPをブロックし、サーバーの負荷が大幅に軽減できました。
特定のIPアドレスが大量の接続を占有していた
ある日、サーバーの負荷が急上昇し、SSHの応答が遅くなる という問題が発生しました。
負荷の原因を調査するため、まず ss コマンドで接続状況を確認しました。
ss -tan state establishedすると、特定のIPアドレスが 同じポートに数百回以上接続 していることが分かりました。
これは、DDoS攻撃や不正アクセスの可能性 があります。
【対処】grep で特定のIPアドレスの接続数を確認
まず、grep を使って 問題のIPアドレスの接続数を特定 しました。
ss -tan | grep "203.0.113.100" | wc -l出力結果
256結果、このIPアドレスが 256回もサーバーに接続 していることが判明しました。
【対処】iptables で問題のIPをブロック
不審なIPアドレスを iptables でブロックしました。
sudo iptables -A INPUT -s 203.0.113.100 -j DROPブロック後に ss で確認すると、そのIPからの接続が消え、サーバーの負荷が低下しました。
tcpdump を使って詳細な通信内容を調査
その後、同じような現象が再発しないか監視するため、tcpdump を使って詳細な通信データを確認しました。
sudo tcpdump -i eth0 port 80 -c 100これにより、ポート80（HTTP）へのリクエストがどのIPアドレスから来ているかを詳細に把握できました。
【対処】iftop でリアルタイムの帯域使用量を確認
さらに、iftop を使ってネットワークの帯域使用量をリアルタイムで監視しました。
sudo iftop -i eth0この結果、特定のIPアドレスが異常に多くの帯域を消費していたため、該当のIPをブロックすることでサーバーの負荷を軽減しました。
ゴリタン
インフラエンジニアとして、ネットワークとサーバーの運用・保守・構築・設計に幅広く携わり、
現在は大規模政府公共データの移行プロジェクトを担当。
CCNPやLPICレベル3、AWSセキュリティスペシャリストなどの資格を保有しています。