• HOME
  • WordPressのNginxでworker_processesとworker_connectionsを最適化する設定

2026年9月9日

  • シェア
  • ツイート

    • 2026年9月9日

    WordPressのNginxでworker_processesとworker_connectionsを最適化する設定

    WordPress を動かす Nginx では、worker_processes は auto（CPU コア数に合わせる）、worker_connections は想定する同時接続数の2倍程度を目安にし、あわせてファイルディスクリプタの上限を引き上げるのが基本です。ただし、WordPress サイトが混雑時に遅くなる原因の多くは Nginx ではなく PHP-FPM 側にあるため、この2つの値を大きくするだけでは速くなりません。この記事では、2つの値の意味と決め方、エラーログでの不足の見分け方、そして PHP-FPM と合わせて考えるべき点を説明します。

    Nginx の一般的なチューニングとは別に、「WordPress の前段に置いた Nginx」という前提で、どこまで調整すれば十分かに焦点を当てます。

    2つの値の意味

    worker_processes

    Nginx は1つのマスタープロセスと、実際にリクエストを処理する複数のワーカープロセスで動きます。worker_processes はワーカーの数です。各ワーカーはイベント駆動で多数の接続を並行して扱えるため、CPU コア数より多くしても速くはならず、コアの取り合いが増えるだけです。auto を指定すると、利用できる CPU コア数に合わせて起動します。

    worker_connections

    worker_connections は、1つのワーカーが同時に開ける接続の上限です。公式ドキュメントでも説明されているとおり、この数にはブラウザからの接続だけでなく、PHP-FPM やバックエンドへのプロキシ接続も含まれます。WordPress の動的ページでは「ブラウザとの接続」と「PHP-FPM との接続」の2本を同時に使うため、同時に処理できるクライアント数は概ね次のようになります。

    • 静的ファイル中心: worker_processes × worker_connections
    • PHP へ渡すリクエスト中心: worker_processes × worker_connections ÷ 2

    たとえば 2コアで worker_connections が 1024 なら、PHP を通すリクエストでも理屈の上では約 1000 の同時接続を扱えます。小〜中規模の WordPress サイトでは、この数字が先に尽きることはあまりありません。

    現状を確認する

    設定を変える前に、CPU コア数、現在の設定値、実際に起動しているワーカー数を確認します。

    # 利用できる CPU コア数
nproc

# 現在有効な設定値（include されたファイルも含めて展開表示）
sudo nginx -T 2>/dev/null | grep -E "worker_processes|worker_connections|worker_rlimit_nofile"

# 起動中のワーカー数
ps -o pid,psr,cmd -C nginx | grep "worker process"

    Debian/Ubuntu 系のパッケージでは、最初から worker_processes auto が書かれていることが多く、その場合 worker_processes はそのままで構いません。これは主要ディストリビューションのパッケージでの傾向（2026年10月現在）で、配布元によって既定の設定は異なります。

    不足しているかをエラーログで見分ける

    worker_connections やファイルディスクリプタが足りないときは、Nginx のエラーログにはっきり記録が残ります。

    sudo grep -E "worker_connections are not enough|Too many open files" /var/log/nginx/error.log | tail -n 20
    • 「worker_connections are not enough」: 1ワーカーあたりの接続上限に達しています。worker_connections を増やします。
    • 「Too many open files」: OS がプロセスに許すファイルディスクリプタの上限に達しています。worker_rlimit_nofile と systemd の LimitNOFILE を引き上げます。

    どちらの記録も無いのに混雑時に遅い、502 Bad Gateway や 504 Gateway Timeout が出る、という場合は、次に説明する PHP-FPM 側を疑ってください。

    推奨設定の例

    nginx.conf の最上位とイベントブロックの例です。値はサーバーの規模に合わせて調整してください。

    # /etc/nginx/nginx.conf（抜粋）
user www-data;
worker_processes auto;

# ワーカー1つが開けるファイル数の上限。worker_connections の2倍以上にする
worker_rlimit_nofile 8192;

events {
    # 1ワーカーあたりの同時接続数（PHP-FPM への接続も含む）
    worker_connections 2048;
    # Linux では epoll が自動で選ばれるため、use epoll; は通常書かなくてよい
}

    worker_rlimit_nofile を worker_connections の2倍以上にしておくのは、1つの接続がソケットに加えて、静的ファイルの読み出しやキャッシュファイルでディスクリプタを使うことがあるためです。systemd で起動している環境では、ユニット側の上限も確認します。

    # 現在のマスタープロセスに適用されている上限（PID ファイルの場所は環境で異なる）
cat /proc/$(cat /run/nginx.pid)/limits | grep "open files"

# 足りなければ上書き設定を作る
sudo systemctl edit nginx
    [Service]
LimitNOFILE=16384

    設定を変えたら構文を確認してから反映します。reload なら接続を切らずに新しいワーカーへ切り替わります。

    sudo nginx -t && sudo systemctl reload nginx

    LimitNOFILE を変えた場合は、systemd の設定を読み直したうえで再起動が必要です（sudo systemctl daemon-reload のあと sudo systemctl restart nginx）。

    WordPress では PHP-FPM の上限が先に効く

    WordPress の動的ページは、Nginx が受け取ったリクエストを PHP-FPM に渡し、PHP がデータベースに問い合わせて HTML を組み立てます。PHP-FPM が同時に処理できる数は pm.max_children で決まり、一般的な VPS では数本〜数十本です。Nginx が数千の接続を受けられても、PHP-FPM が 10本しか処理できなければ、残りは待ち行列に並び、待ちきれないものが 502/504 になります。

    このため、混雑対策は次の順で考えると効果が出やすくなります。

    1. ページキャッシュ（キャッシュプラグインや Nginx の fastcgi_cache）で、PHP まで届くリクエストを減らす。
    2. 画像・CSS・JavaScript を Nginx から直接返し、適切なキャッシュヘッダーを付ける。
    3. PHP-FPM の pm.max_children を、メモリに収まる範囲で見直す。
    4. そのうえで、Nginx のエラーログに不足の記録があれば worker_connections などを上げる。

    keepalive_timeout も関係します。待機中の Keep-Alive 接続も worker_connections を1つ消費するため、長すぎると空き枠が減ります。既定の 75 秒から短くする運用もありますが、短すぎると再接続が増えるので、変える場合は少しずつにしてください。

    効果を測る

    Nginx の stub_status モジュールを有効にすると、現在の接続数を確認できます。多くのディストリビューションのパッケージには組み込まれていますが、nginx -V の出力に with-http_stub_status_module があるかで確かめられます。

    # server ブロック内。外部から見えないようにローカルからのみ許可する
location = /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}
    curl -s http://127.0.0.1/nginx_status

    Active connections が worker_processes × worker_connections に近づいているなら Nginx 側の上限を、Waiting（待機中の Keep-Alive 接続）が大半を占めるなら keepalive_timeout を見直す目安になります。負荷試験ツールで確認する場合は、本番ではなくステージング環境で行い、変更前の設定ファイルは控えを残しておいてください。

    まとめ

    • worker_processes は auto が基本。CPU コア数より増やしても速くならない。
    • worker_connections は PHP-FPM への接続も含む。動的ページ中心なら同時クライアント数の2倍を見込む。
    • 不足はエラーログの「worker_connections are not enough」「Too many open files」で判断し、worker_rlimit_nofile と LimitNOFILE もあわせて上げる。
    • WordPress の混雑時の遅さは PHP-FPM の上限が原因であることが多い。ページキャッシュと pm.max_children の見直しを先に行う。
    • 変更は nginx -t で構文を確かめてから reload し、stub_status で接続数を観察する。
    Views: 27

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲