2026年6月2日

Nginxのworker_processes・worker_connectionsの最適化｜上限の計算とファイル数制限の確認

Webサーバー・Nginx

Nginx の worker_processes は基本的に auto（CPU コア数に合わせる）で十分で、調整の余地が大きいのは worker_connections と、それを支える OS のファイルディスクリプタ上限です。ただし WordPress サイトでは、Nginx より先に PHP-FPM やデータベースが詰まることが多く、Nginx の数値だけを上げても速くならない場面があります。この記事では、二つの設定の意味と同時接続数の見積もり方、上げる必要があるかを判断するログと指標、変更の手順を説明します。

二つの設定が決めているもの

Nginx は、マスタープロセスが設定を読み、実際の通信はワーカープロセスが受け持ちます。各ワーカーはイベント駆動で、1プロセスで多数の接続を同時にさばけます。

worker_processes：ワーカープロセスの数。auto を指定すると、利用できる CPU コア数に合わせて起動します。
worker_connections：1つのワーカーが同時に開ける接続の上限。events ブロックに書きます。

worker_processes auto;

events {
    worker_connections 1024;
}

ディストリビューションのパッケージに含まれる設定ファイルでは、worker_connections が 768 や 1024 になっていることが多いようです（2026年10月現在）。値はパッケージや版によって異なります。現在の値は、読み込まれている設定をすべて表示する nginx -T で確認できます。

sudo nginx -T 2>/dev/null | grep -E "worker_(processes|connections|rlimit_nofile)"
nproc   # 利用できる CPU コア数

同時接続数の見積もり方

扱える同時接続数のおおよその上限は、次の掛け算で考えます。

最大接続数 ≒ worker_processes × worker_connections

注意したいのは、worker_connections が「クライアントとの接続」だけでなく、Nginx が開くすべての接続を数える点です。WordPress を PHP-FPM と組み合わせている場合、1件のリクエストを処理する間に「クライアント → Nginx」と「Nginx → PHP-FPM」の二つの接続を使います。リバースプロキシ構成でも同じで、同時に処理できるクライアント数は概ね半分になると見ておくと安全です。

例えば 4コアで worker_connections 1024 なら、上限は約4,096接続、PHP へ渡すリクエストが中心なら同時に処理できるクライアントは約2,000件が目安です。

もう一つ見落としやすいのが Keep-Alive です。ブラウザは表示を終えた後も、しばらく接続を開いたままにします。この「待機中の接続」も worker_connections を消費するため、keepalive_timeout を長くすると、実際のアクセス数が少なくても接続数は多く見えます。

上げる必要があるかを判断する

数値を変える前に、本当に Nginx の接続数が足りていないのかを確認します。判断材料は主に三つあります。

エラーログのメッセージ

接続数の上限に達すると、Nginx のエラーログに次のようなメッセージが出ます。

sudo grep -E "worker_connections are not enough|Too many open files" /var/log/nginx/error.log

「worker_connections are not enough」が出ている場合は、worker_connections が不足しています。
「Too many open files」（エラー番号 24）が出ている場合は、OS のファイルディスクリプタ上限が先に尽きています。worker_connections だけを上げても解決しません。

どちらも出ていなければ、Nginx の接続数は原因ではない可能性が高いと考えられます。

stub_status で現在の接続数を見る

ngx_http_stub_status_module が組み込まれていれば（nginx -V の出力に --with-http_stub_status_module があるか確認します）、現在の接続数を数値で確認できます。外部に公開しないよう、ローカルからのアクセスに限定します。

server {
    listen 127.0.0.1:8080;
    location = /nginx_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
    }
}

curl -s http://127.0.0.1:8080/nginx_status

表示される Active connections が上限（worker_processes × worker_connections）に近づいているなら、上げる検討の余地があります。Waiting が大半を占める場合は、多くが Keep-Alive の待機接続なので、keepalive_timeout を短くする方が効果的なこともあります。

PHP-FPM 側が詰まっていないか

WordPress で「遅い」「502 / 504 が出る」という症状の多くは、Nginx の接続数ではなく、PHP-FPM のワーカー（pm.max_children）が埋まっていることが原因です。PHP-FPM のログに「server reached pm.max_children setting」のような警告が出ていないかを確認してください。この場合、Nginx の worker_connections を増やすと、PHP-FPM の前で待つリクエストが増えるだけで、応答はかえって悪化することがあります。キャッシュの導入や PHP-FPM の調整を先に行います。

ファイルディスクリプタの上限を確認・調整する

Nginx では、1つの接続が1つのファイルディスクリプタを使い、さらにログやキャッシュのファイルも開きます。ワーカーが開けるファイル数の上限が worker_connections より小さいと、そちらが実質の上限になります。実行中のワーカーの上限は次のように確認できます。

for pid in $(pgrep -f "nginx: worker process"); do
  grep "Max open files" /proc/$pid/limits
done

足りない場合は、nginx.conf の最上位に worker_rlimit_nofile を書いて、ワーカーの上限を引き上げます。worker_connections の2倍程度を目安にする例が多く見られます。

worker_processes auto;
worker_rlimit_nofile 4096;

events {
    worker_connections 2048;
}

systemd で起動している環境では、サービス側の LimitNOFILE も影響します。sudo systemctl edit nginx で上書き設定を作り、[Service] セクションに LimitNOFILE= で値を指定します。ユニットの設定を変えた場合は、反映に reload ではなく restart が必要です。

変更を反映する手順

設定ファイルのバックアップを取り、構文を確認してから反映します。

sudo cp -a /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
sudo nginx -t                  # syntax is ok / test is successful を確認
sudo systemctl reload nginx

reload では、マスタープロセスが新しい設定で新しいワーカーを起動し、古いワーカーは処理中の接続を終えてから終了します。反映後は、ps でワーカーの数が意図どおりか、エラーログに新しい警告が出ていないかを確認します。

負荷をかけて効果を測る場合は、本番ではなくステージング環境で行います。本番に負荷試験ツールを向けると、それ自体が障害の原因になります。

そのほかの関連設定

multi_accept：有効にすると、ワーカーが新しい接続をまとめて受け付けます。標準は無効で、多くの環境では変える必要はありません。
use epoll：Linux では Nginx が自動で最適なイベント方式を選ぶため、通常は明示しなくて構いません。
worker_cpu_affinity auto：ワーカーを CPU コアに固定します。仮想サーバーでは効果が見えにくいことがあります。

いずれも、エラーログや指標で問題が確認できてから試すもので、最初から入れておく必要はありません。

まとめ

worker_processes は auto を基本にし、調整の中心は worker_connections とファイルディスクリプタの上限。
上限の目安は worker_processes × worker_connections。PHP-FPM やプロキシへ渡す構成では、1リクエストで2接続を使うため実質は半分程度と見る。
上げる前に、エラーログの「worker_connections are not enough」「Too many open files」と、stub_status の接続数を確認する。
WordPress の遅延や 502 は PHP-FPM の pm.max_children が原因のことが多い。Nginx だけを上げても解決しない場合はそちらを先に見る。