2026年6月30日

Nginxのworker_processes・worker_connectionsの最適化（決め方と確認方法）

Webサーバー・Nginx

worker_processes は auto（CPUのコア数に合わせる）にし、worker_connections は実際の同時接続数を測ってから、ファイルディスクリプタの上限とあわせて決めるのが基本です。この記事では、2つの値の意味と関係、同時に何接続まで扱えるかの見積もり方、上限を上げるときに一緒に変える設定、現在の接続数の測り方、そして値を上げても速くならない場合に見るべき場所を説明します。

2つの値の意味

Nginxは、設定を読み込んで管理する1つのマスタープロセスと、実際にリクエストを処理する複数のワーカープロセスで動きます。

worker_processes: ワーカープロセスの数です。メインの設定ファイル（通常は /etc/nginx/nginx.conf）の最上位に書きます。
worker_connections: 1つのワーカーが同時に開ける接続の上限です。events ブロックの中に書きます。

各ワーカーは、イベント駆動で多数の接続を少ないプロセスで並行して処理します。1つのワーカーが1つのCPUコアを使い切れるため、ワーカーの数をコア数より増やしても、多くの場合は処理能力は上がらず、切り替えの負担が増えるだけです。

# /etc/nginx/nginx.conf
worker_processes auto;

events {
    worker_connections 1024;
}

worker_processesの決め方

ほとんどの環境では auto で問題ありません。auto は、Nginxが起動時に検出したCPUの数に合わせます。確認には次のコマンドを使います。

nproc
ps -o pid,cmd -C nginx

ps の出力に nginx: worker process が nproc の数だけ並んでいれば、auto が働いています。

例外は、コンテナや仮想環境でCPUの割り当てを制限している場合です。ホストのCPU数が検出され、割り当てより多くのワーカーが起動することがあります。その場合は、割り当てたコア数を数値で指定します。また、同じサーバーでPHP-FPMやデータベースも動いているなら、Nginxのワーカーを増やすとそれらとCPUを取り合います。WordPressの多くの構成では、CPUを一番使うのはNginxではなくPHPとデータベースです。

worker_connectionsの決め方

コンパイル時の既定値は512ですが、ディストリビューションの設定ファイルでは768や1024が書かれていることが多くあります（2026年10月現在）。ディストリビューションやバージョンによって異なるため、実際のファイルを確認してください。

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

最大接続数 ≒ worker_processes × worker_connections

ここで数えるのは「Nginxが開く接続のすべて」で、ブラウザからの接続だけではありません。リバースプロキシやPHP-FPMへの中継では、1件のリクエストについてブラウザ側とバックエンド側の2つの接続を使います。そのため、プロキシとして使う場合に同時に扱えるクライアントの数は、上の値のおよそ半分と考えます。

また、キープアライブで待機している接続も1接続として数えられます。HTTP/1.1のブラウザは1つのサイトに複数の接続を開くことがあるため、「同時訪問者数」と「接続数」は一致しません。実際の値は次の節の方法で測って決めます。

上限に達すると、エラーログに次のような行が出ます（先頭の数値は設定した値で、後ろに処理中の状況が続くことがあります）。

1024 worker_connections are not enough

この行が出ていなければ、worker_connections を増やしても速くはなりません。

ファイルディスクリプタの上限も一緒に上げる

Linuxでは、1つの接続が1つのファイルディスクリプタを使い、配信中のファイルやログファイルもそれぞれ1つずつ使います。プロセスごとに開けるファイルの数には上限があり、worker_connections を大きくしても、こちらが小さいままだとエラーログに (24: Too many open files) が出ます。

Nginxでは、ワーカーの上限を worker_rlimit_nofile で引き上げられます。worker_connections の2倍程度を目安にします。

worker_processes auto;
worker_rlimit_nofile 8192;

events {
    worker_connections 4096;
}

systemdで起動している場合は、サービスの上限（LimitNOFILE）も影響します。現在の値は次のように確認できます。

# ワーカープロセスの実際の上限
sudo cat /proc/$(pgrep -f 'nginx: worker' | head -1)/limits | grep 'open files'

# systemd のサービスに設定された上限
systemctl show nginx -p LimitNOFILE

サービスの上限を変える場合は、パッケージの設定ファイルを直接書き換えず、sudo systemctl edit nginx で上書き用のファイルを作り、[Service] の下に LimitNOFILE= を書きます。その後 sudo systemctl daemon-reload と sudo systemctl restart nginx で反映します。

現在の接続数を測る

決める根拠になるのは、混んでいる時間帯の実際の接続数です。Nginxの stub_status を使うと、接続の状態を数値で確認できます。モジュールが組み込まれているかは 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 http://127.0.0.1:8080/nginx_status

出力の Active connections が現在の接続数で、Reading（リクエストを読んでいる）・Writing（応答を書いている）・Waiting（キープアライブで待機中）の内訳も表示されます。Waiting が大半を占めているなら、処理中の接続は多くありません。この値の最大を、worker_processes × worker_connections が十分に上回っていれば足りています。この確認用のページは外部に公開せず、上のように接続元を制限します。

その他の関連設定

multi_accept on;（events ブロック）: ワーカーが一度に複数の新しい接続を受け付けます。既定はoffです。接続が急に集中する環境で使われますが、効果は環境によって変わるため、測ってから判断します。
use epoll;: Linuxでは、指定しなくても最適な方式が自動で選ばれるため、通常は書く必要がありません。
worker_cpu_affinity auto;: ワーカーを特定のCPUに固定します。一般的なWebサーバーでは、効果を測れる場合を除いて指定しなくて構いません。

値を上げても速くならないとき

WordPressで応答が遅い原因の多くは、Nginxのワーカーではなく、PHPの処理待ちです。PHP-FPMの pm.max_children に達すると、Nginxは接続を受け付けてもPHPの空きを待つことになり、ワーカーの値をいくら増やしても改善しません。PHP-FPMのログに server reached pm.max_children setting が出ていないか、データベースの遅いクエリが無いかを先に確認します。

設定を変えるときは、変更前の nginx.conf を保存し、sudo nginx -t で構文を確認してから sudo systemctl reload nginx で反映します。負荷試験で効果を測る場合は、本番ではなくステージング環境で行います。

まとめ

worker_processes は auto が基本です。コンテナでCPUを制限している場合は数値で指定します。
最大接続数は worker_processes × worker_connections で見積もり、プロキシでは1リクエストに2接続を使う点を考慮します。
worker_connections を増やすときは、worker_rlimit_nofile と systemd の LimitNOFILE も確認します。
値は stub_status で実際の接続数を測り、worker_connections are not enough が出ているかを根拠に決めます。
WordPressで遅い場合は、PHP-FPMとデータベースを先に疑います。