2026年5月22日

2026年5月22日

netstatとssでネットワーク接続を監視する方法|WordPressサーバーの接続数・状態を読む

サーバーの「いま、誰と、どれだけ、どんな状態でつながっているか」を確かめるには、Linux の ss コマンド(古い環境では netstat)を使います。この記事では、待ち受けポートの確認、接続状態の集計、IPごとの接続数、MySQL や PHP-FPM との接続の見方までを、WordPress サーバーの運用でよくある場面に沿って説明します。読み終えるころには、出力のどの列を見て何を判断すればよいかが分かるはずです。

netstat と ss の違いと、どちらを使うか

netstat は net-tools パッケージに含まれる昔からのコマンドで、ss は iproute2 パッケージに含まれる後継です。最近の主要ディストリビューション(Ubuntu、Debian、RHEL 系など)では net-tools が最小構成に入っていないことが多く、netstat: command not found と表示されることがあります。iproute2 は標準で入っているため、これから覚えるなら ss を基本にするのがおすすめです(2026年10月現在)。

ss はカーネルから直接ソケット情報を取得するため、接続数が多いサーバーでも netstat より速く結果が返ります。どうしても netstat を使いたい場合は、Debian/Ubuntu なら apt install net-tools、RHEL 系なら dnf install net-tools で導入できます。以下では ss を中心に、対応する netstat の書き方も併記します。

よく使うオプションは次のとおりです。

  • -t TCP、-u UDP を対象にする
  • -l 待ち受け(LISTEN)中のソケットだけを表示する
  • -a 待ち受けと接続中の両方を表示する
  • -n 名前解決をせず、IP アドレスとポート番号のまま表示する(速く、誤解も少ない)
  • -p ソケットを使っているプロセスを表示する(他ユーザーのプロセスを見るには root 権限が必要)
  • -s 集計(サマリー)を表示する

待ち受けポートを確認する

最初に確認したいのは「どのプロセスが、どのアドレスの、どのポートで待ち受けているか」です。

# TCP の待ち受けポートとプロセス
sudo ss -tlnp

# netstat で同じことをする場合
sudo netstat -tlnp

出力の Local Address:Port 列に注目します。0.0.0.0:3306 や [::]:3306 のように表示されていれば、MySQL/MariaDB がすべてのネットワークインターフェースで待ち受けています。Web サーバーと DB が同じ機械にあるなら、127.0.0.1:3306 だけで待ち受けるよう DB 側の設定(bind-address など)を見直すか、ファイアウォールで外部からの 3306 番を閉じておくのが安全です。

同じように、Nginx/Apache が :80 と :443、SSH が :22(変更している場合はそのポート)で待ち受けているかを確認します。「ブラウザでサイトが開かない」というときに、そもそも Web サーバーが待ち受けていないのか、待ち受けているのに外から届かないのかを切り分ける最初の一手になります。

接続状態を集計する

全体の様子をつかむには -s が便利です。

ss -s

TCP の行に estab(確立済み)、closed、timewait などの数が並びます。より細かく状態ごとの数を見たい場合は、状態の列を数えます。

# 状態ごとの TCP 接続数(-H でヘッダー行を省く)
ss -Htan | awk '{print $1}' | sort | uniq -c | sort -rn

# netstat の場合(6列目が状態)
netstat -ant | awk 'NR>2 {print $6}' | sort | uniq -c | sort -rn

数字の読み方の目安は次のとおりです。どれも「普段の値」と比べて初めて意味を持つので、平常時に一度記録しておくと判断しやすくなります。

  • ESTAB が急増している: アクセスが集中しているか、接続が長く張りっぱなしになっています。後述の IP 別集計で偏りを確認します。
  • SYN-RECV が多い: 接続の受け付け途中で止まっているものが多い状態です。大量の接続要求を受けているか、受け付けが追いついていない可能性があります。
  • TIME-WAIT が多い: 短い接続を自分から閉じた側に残る正常な状態です。数が多いだけなら直ちに問題とは限りません。Nginx から PHP-FPM や MySQL へ TCP(127.0.0.1:9000 など)で接続している構成で増えやすく、同じ機械内なら Unix ソケットに切り替えると減らせます。
  • CLOSE-WAIT が増え続ける: 相手は接続を閉じたのに、こちらのアプリケーションが閉じていない状態です。時間とともに減らずに積み上がるなら、アプリケーションやプロキシ側の不具合を疑います。

特定のポートや相手に絞り込む

ss は状態やポートでフィルタできます。

# 443 番で確立済みの接続だけ
ss -tn state established '( sport = :443 )'

# 確立済み接続を相手 IP ごとに数える(上位10件)
ss -Htn state established '( sport = :443 or sport = :80 )' \
  | awk '{print $4}' | sed -E 's/:[0-9]+$//' | sort | uniq -c | sort -rn | head -10

state を指定すると出力から状態の列がなくなるため、相手のアドレスは4列目になります。IPv6 の場合は [2001:db8::1]:443 のような形式になり、sed で末尾のポート番号だけを取り除いています。

ひとつの IP からの接続が極端に多い場合は、アクセスログ(Nginx なら access.log)で同じ IP のリクエスト内容を確認します。wp-login.php や xmlrpc.php への連続アクセスであれば、ログイン試行の制限やファイアウォールでの遮断を検討します。ただし、CDN やリバースプロキシを経由している構成では、ここに見える相手は CDN のアドレスなので、本当の接続元はプロキシが付けるヘッダー(X-Forwarded-For など)を記録したログで確認する必要があります。

MySQL・PHP-FPM との接続を確認する

WordPress の「データベース接続確立エラー」や表示の遅さを調べるときは、DB への接続数を見ます。

# Web サーバー側から見た DB(3306番)への確立済み接続数
ss -Htn state established '( dport = :3306 )' | wc -l

# DB サーバー側で受けている接続数
ss -Htn state established '( sport = :3306 )' | wc -l

この数を MySQL の上限と比べます。MySQL に接続して SHOW VARIABLES LIKE 'max_connections'; と SHOW STATUS LIKE 'Threads_connected'; を実行すると、上限と現在の接続数が分かります。上限に近いなら、PHP-FPM のワーカー数(pm.max_children)が DB の上限に対して多すぎないか、遅いクエリで接続が長く占有されていないかを確認します。同じ機械内で localhost 指定にしていると Unix ソケットで接続するため、TCP の 3306 番には現れない点にも注意してください。

PHP-FPM を TCP で待ち受けさせている場合は、待ち受けソケットのキューも参考になります。

ss -tln '( sport = :9000 )'

LISTEN 状態のソケットでは、Recv-Q が受け付け待ちの接続数、Send-Q がキューの上限を表します。Recv-Q が常に 0 より大きいなら、PHP-FPM の処理が追いついていない兆候です。

定期的に記録して変化を見る

一度だけ見るより、時間ごとの変化を記録するほうが原因をつかみやすくなります。手元で様子を見るなら watch が手軽です。

watch -n 5 'ss -s'

継続的に残したい場合は、短いスクリプトを cron で動かす方法があります。

#!/bin/sh
# /usr/local/bin/tcp-state-log.sh : 状態ごとの接続数を1行で記録する
{
  date '+%F %T'
  ss -Htan | awk '{print $1}' | sort | uniq -c | awk '{printf " %s=%s", $2, $1}'
  echo
} >> /var/log/tcp-state.log

chmod +x で実行権限を付け、crontab -e に */5 * * * * /usr/local/bin/tcp-state-log.sh のように登録すると5分ごとに記録されます。ログは増え続けるので、logrotate の対象に加えておきます。本格的に監視するなら、Prometheus の node_exporter や Zabbix などの監視ツールで接続数をグラフ化し、しきい値で通知する構成に移行すると運用が楽になります。

つまずきやすい点

  • **-p を付けてもプロセス名が出ない**: 他ユーザーのプロセスは root 権限がないと表示されません。sudo を付けて実行します。
  • コンテナのポートが見えない: Docker のコンテナ内で待ち受けているポートは、ホストに公開(-p オプションなど)していなければホスト側の ss には現れません。コンテナ内で確認するか、docker port で公開状況を見ます。
  • 名前解決で遅い・表示が変わる: -n を付けないと逆引きが走り、遅くなったりホスト名で表示されたりします。調査時は -n を付けるのが基本です。
  • 数字だけで判断する: 接続数の多さは負荷の結果であって原因とは限りません。アクセスログ、PHP-FPM のスローログ、MySQL のスロークエリログとあわせて見ることで、どこが詰まっているかが分かります。

まとめ

  • これから使うなら iproute2 の ss が基本。netstat は net-tools を入れれば同じ用途に使えます。
  • ss -tlnp で待ち受けポートを確認し、DB などが外部に開いていないかを見ます。
  • ss -Htan の状態列を集計し、ESTAB・SYN-RECV・TIME-WAIT・CLOSE-WAIT を平常時と比べて判断します。
  • state とポート指定で絞り込み、IP 別の接続数や MySQL への接続数を確認します。CDN 経由では本当の接続元はログ側で見ます。
  • 定期的に記録しておくと、障害時に「いつから増えたか」を追えます。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲