Nginx の client_max_body_size の設定方法｜413 Request Entity Too Large と WordPress のアップロード上限を直す

Nginx で動くサイトに大きなファイルをアップロードすると失敗し、ブラウザーや WordPress には分かりにくいエラーしか出ないことがあります。原因の多くは Nginx の client_max_body_size です。この記事では、上限の仕組み、設定する場所、反映と確認の手順、WordPress で合わせて変える PHP の設定を説明します。設定ファイルの場所やバージョンは 2026年10月時点の Ubuntu / Debian の標準パッケージを例にしています。

client_max_body_size とは

client_max_body_size は、クライアントが送るリクエスト本文（アップロードするファイルを含む）の最大サイズを決める Nginx の設定です。

既定値が 1MB なので、何も設定していない Nginx では 1MB を超える画像や PDF のアップロードが拒否されます。

413 が原因かを確かめる

Nginx の公式文書にもあるとおり、ブラウザーは 413 エラーを正しく表示できないことがあります。WordPress のメディア画面でもアップロード失敗とだけ表示される場合があるので、Nginx のエラーログで確認するのが確実な方法です。

sudo tail -n 50 /var/log/nginx/error.log

上限を超えたリクエストがあると、次のような行が記録されます。

[error] 22#22: *1 client intended to send too large body: 2000000 bytes, client: 127.0.0.1, server: , request: "POST / HTTP/1.1", host: "127.0.0.1"

この行があれば client_max_body_size の不足です。アクセスログ（/var/log/nginx/access.log）では該当リクエストのステータスが 413 になっています。

現在の設定を確認する

設定ファイルは複数に分かれていることが多いので、読み込まれた設定全体を nginx -T で出力して探します。

sudo nginx -T 2>/dev/null | grep -n client_max_body_size

何も表示されなければ、既定値の 1MB が使われています。

設定する場所を決める

client_max_body_size は http → server → location の順に引き継がれ、内側に書いた値が優先されます。

RHEL 系や nginx.org の公式パッケージでは、サイトの設定は /etc/nginx/conf.d/*.conf に置くのが一般的です。

WordPress の場合は server ブロックに書くのが分かりやすい方法です。WordPress のアップロードは、メディア画面からの wp-admin/async-upload.php やブロックエディターからの REST API（/wp-json/wp/v2/media）など複数の経路を通るため、特定の location だけに書くと上限が効かない経路が残ることがあります。

設定と反映の手順

1. 設定を書く

対象サイトの server ブロックに 1 行追加します。値は実際にアップロードする最大のファイルより少し大きめにします。

server {
    listen 443 ssl;
    server_name example.com;

    # アップロードできるリクエスト本文の上限
    client_max_body_size 64m;

    # ...既存の設定...
}

特定のパスだけ大きくしたい場合は、location に書きます。次の例では、全体を 8MB に抑え、/upload だけ 64MB まで受け付けます。

server {
    client_max_body_size 8m;

    location /upload {
        client_max_body_size 64m;
        # ...アップロードを処理する設定...
    }
}

2. 構文を確認する

sudo nginx -t

syntax is ok と test is successful が表示されれば問題ありません。エラーが出た場合は、表示されたファイルと行番号を直してから再度確認します。

3. 設定を読み込み直す

sudo systemctl reload nginx

reload なら処理中の接続を切らずに新しい設定を読み込めます。restart は不要です。

4. 動作を確かめる

元のファイルをもう一度アップロードします。コマンドで確かめる場合は、上限より大きい仮のファイルを作って送り、ステータスコードを見ます（URL は自分の環境に合わせてください）。

head -c 2000000 /dev/zero > /tmp/test.bin
curl -s -o /dev/null -w "%{http_code}\n" -X POST --data-binary @/tmp/test.bin https://example.com/

413 以外（WordPress のトップページなら 200 や 405 など）が返れば、Nginx の上限は通過しています。

WordPress では PHP の上限も合わせる

Nginx の上限を上げても、PHP 側の上限が小さければアップロードできません。WordPress がアップロードを受け付ける最大サイズは、PHP の次の 2 つのうち小さいほうです。

3 つの値は次の関係にしておきます。

• upload_max_filesize ≦ post_max_size ≦ Nginx の client_max_body_size

フォームの他の項目なども本文に含まれるため、post_max_size と client_max_body_size は upload_max_filesize より少し大きくしておくと安全です。

PHP-FPM を使っている場合は、FPM 用の php.ini を編集します。Ubuntu 24.04 の PHP 8.3 なら /etc/php/8.3/fpm/php.ini です（コマンドラインの php --ini が示すのは CLI 用のファイルなので注意してください）。

upload_max_filesize = 60M
post_max_size = 64M

編集したら PHP-FPM を読み込み直します。サービス名は PHP のバージョンで変わります。

sudo systemctl reload php8.3-fpm

WordPress が認識している値は、管理画面の「ツール」→「サイトヘルス」→「情報」タブで、サーバーとメディア処理の項目を開くと確認できます。PHP のインストールと php.ini の場所は「PHPのインストールとphp.iniの基本設定」も参考にしてください。

複数のサーバーを経由している場合

ロードバランサーやリバースプロキシの Nginx の後ろに別の Nginx や Apache がある構成では、経由するすべての層の上限が適用されます。手前の Nginx だけ上げても、奥のサーバーで止まることがあります。各サーバーのエラーログを見て、どこで 413 が返っているかを確かめてください。

Cloudflare などの CDN を経由している場合も、CDN 側にリクエスト本文の上限があります。上限はサービスやプランごとに違うので、各社の公式文書で確認してください。

注意点

• 必要以上に大きくしない: 上限を大きくすると、大きなリクエストを大量に送りつけられたときにディスクや帯域を消費しやすくなります。0（無制限）は避け、実際に必要な値にとどめます。
• 大きなファイルは時間制限にも注意: Nginx の client_body_timeout（既定 60 秒）は、本文の受信が途切れている時間の上限です。回線が遅く送信が止まると 408 になります。PHP 側では max_execution_time や、Nginx から PHP-FPM への fastcgi_read_timeout が関係することがあります。
• レンタルサーバーでは変更できないことがある: 共用サーバーでは Nginx の設定を直接編集できないのが一般的です。管理画面の PHP 設定でアップロード上限を変えられるかを確認してください。

Nginx と PHP-FPM の基本的な組み合わせは「NginxとPHP-FPMの設定」で説明しています。

まとめ

• アップロード時の 413 Request Entity Too Large は、Nginx の client_max_body_size（既定 1MB）が原因です。エラーログの client intended to send too large body で確認できます。
• WordPress では server ブロックに設定し、nginx -t で確認してから systemctl reload nginx で反映します。
• PHP の upload_max_filesize と post_max_size も合わせて上げ、PHP-FPM を読み込み直します。
• プロキシや CDN を経由する場合は、各層の上限も確認します。