WordPressで「413」が出たら、容量を増やす前に。まず探したい「どこで止まったか」
見慣れない数字のエラーが出ると、まず「ファイルが大きすぎたのかな」と考えますよね。
そこで検索すると、upload_max_filesizeやpost_max_sizeを大きくする方法が出てきます。
たしかに、それで直ることもあります。
でも、413エラーで少しややこしいのは、止めている場所がWordPressとは限らないことなんです。
CDN、Webサーバー、PHP、WordPress、プラグイン。
アップロードしたファイルは、いくつもの入口を通って届きます。
だから、数字をいきなり大きくするより、「どの入口で止まったのか」を探す方が、遠回りに見えて安全だと思うんです。
今回は、WordPressで413エラーが出たときに、僕ならどんな順番で状況を整理するかを書いてみます。
413は「送った内容が大きすぎる」という合図
HTTPの仕様を定めるRFC 9110では、413 Content Too Largeを、送られた内容がサーバーの処理できる、または処理する意思のある大きさを超えたため、処理を拒否した状態としています。
つまり、大きく捉えると「送った内容が、どこかの上限を超えた」ということです。
WordPressでは、たとえば次のような場面で出る可能性があります。
容量の大きい画像や動画を追加した
テーマやプラグインのZIPファイルをアップロードした
バックアップや移行用ファイルを取り込んだ
フォームから複数のファイルをまとめて送った
ただし、ここで「WordPressの容量設定だけ直せばいい」と決めつけるのは少し早いんですよね。
リクエストがWordPressへ届く前に、手前のサーバーで止まっていることもあるからです。
アップロードは、一つの入口だけを通るわけではない
ファイルを送る流れを、かなり単純化すると次のようになります。
CDNやWAF
NginxやApacheなどのWebサーバー
PHP
WordPress
利用中のプラグイン
この中に10MB、50MB、100MBという別々の上限があれば、実際に通れる容量は一番小さいところで決まります。
たとえば、PHP側を128MBへ上げても、手前のWebサーバーが1MBで止めていれば、そこから先には届きません。
Nginxの公式ドキュメントでも、client_max_body_sizeを超えるリクエストには413を返すと説明されています。
ここが、413エラーで混乱しやすいところです。
設定画面で見えている数字と、実際に通信を止めている数字が、同じとは限りません。
最初に「どの操作で、何MBから失敗したか」を残す
設定を変える前に、まず次の4つをメモしておくと切り分けやすくなります。
何をアップロードしようとしたか
ファイルの形式と容量
どの画面やプラグインで失敗したか
エラーが出た時刻
そのうえで、同じ形式の小さいファイルなら通るかを試します。
小さいファイルは成功し、大きいファイルだけ失敗するなら、サイズ上限の可能性が高くなります。
反対に、小さいファイルでも失敗するなら、ファイル形式、権限、セキュリティ設定など、別の原因も考えた方がよさそうです。
エラーが出た時刻も大切です。
CDNやサーバーのログを確認するとき、時刻と対象URLが分かるだけでも、原因を探しやすくなります。
WordPressのサイトヘルスで「見えている上限」を確認する
WordPress管理画面の「ツール」→「サイトヘルス」→「情報」→「メディア処理」では、ファイルアップロードに関する上限を確認できます。
WordPress公式のサイトヘルス解説によると、ここではPOSTデータの最大サイズ、1ファイルの最大サイズ、実際に有効な最大サイズなどが表示されます。
WordPressのwp_max_upload_size()も、PHPのupload_max_filesizeとpost_max_sizeを確認し、小さい方を基準にします。
ここで大切なのは、サイトヘルスの数字を「原因の確定」と考えないことです。
これはWordPressから見えている上限です。
その手前にあるCDNやWebサーバーの上限まですべて表しているわけではありません。
いきなり全部を大きくしない
エラーを早く消したいと、PHP、Nginx、プラグインの設定を一度に変えたくなります。
でも、複数の数字を同時に変えると、どの変更で直ったのか分からなくなります。
さらに、リクエストサイズの上限は、サーバー資源を守る役割も持っています。
「大きければ大きいほど安心」ではないんですよね。
僕は、次の順番で考えるのが安全だと思います。
まずファイルを小さくできないか確認する
CDNやWAFを使っているなら、その上限とログを見る
NginxやApacheなどWebサーバーの設定を確認する
PHPのpost_max_sizeとupload_max_filesizeを確認する
WordPressやプラグイン独自の上限を確認する
自分でサーバー設定を変更できない環境なら、無理に設定ファイルを触らなくても大丈夫です。
失敗した時刻、対象URL、ファイル容量、サイトヘルスの数値をまとめて、ホスティング会社へ相談した方が早いこともあります。
エラーを消すより、原因を一つに絞る
413エラーが出ると、「上限を上げれば終わり」と考えやすいです。
でも、本当に知りたいのは、どの数字を大きくするかではありません。
どの層が、何MBで止めているのか。
ここが分かれば、ファイルを小さくするのか、サーバー設定を変えるのか、ホスティング会社へ相談するのかを選べます。
WordPressのトラブルは、見えている画面だけに原因があるとは限りません。
だからこそ、焦って触る場所を増やすより、入口を一つずつたどる。
その方が、直ったあとにも「なぜ直ったのか」が残ります。
413という数字が出たら、まずは容量を増やす前に、「このファイルはどこまで届いたんだろう」と考えてみてください。
それだけで、次に見る場所が少し見つけやすくなると思います。
参考リンク
client_max_body_size｜nginx.orgWordPressへ画像や動画をアップロードしたら、突然「413 Payload Too Large」と表示された。
見慣れない数字のエラーが出ると、まず「ファイルが大きすぎたのかな」と考えますよね。
そこで検索すると、upload_max_filesizeやpost_max_sizeを大きくする方法が出てきます。
たしかに、それで直ることもあります。
でも、413エラーで少しややこしいのは、止めている場所がWordPressとは限らないことなんです。
CDN、Webサーバー、PHP、WordPress、プラグイン。
アップロードしたファイルは、いくつもの入口を通って届きます。
だから、数字をいきなり大きくするより、「どの入口で止まったのか」を探す方が、遠回りに見えて安全だと思うんです。
今回は、WordPressで413エラーが出たときに、僕ならどんな順番で状況を整理するかを書いてみます。
413は「送った内容が大きすぎる」という合図
HTTPの仕様を定めるRFC 9110では、413 Content Too Largeを、送られた内容がサーバーの処理できる、または処理する意思のある大きさを超えたため、処理を拒否した状態としています。
つまり、大きく捉えると「送った内容が、どこかの上限を超えた」ということです。
WordPressでは、たとえば次のような場面で出る可能性があります。
容量の大きい画像や動画を追加した
テーマやプラグインのZIPファイルをアップロードした
バックアップや移行用ファイルを取り込んだ
フォームから複数のファイルをまとめて送った
ただし、ここで「WordPressの容量設定だけ直せばいい」と決めつけるのは少し早いんですよね。
リクエストがWordPressへ届く前に、手前のサーバーで止まっていることもあるからです。
アップロードは、一つの入口だけを通るわけではない
ファイルを送る流れを、かなり単純化すると次のようになります。
CDNやWAF
NginxやApacheなどのWebサーバー
PHP
WordPress
利用中のプラグイン
この中に10MB、50MB、100MBという別々の上限があれば、実際に通れる容量は一番小さいところで決まります。
たとえば、PHP側を128MBへ上げても、手前のWebサーバーが1MBで止めていれば、そこから先には届きません。
Nginxの公式ドキュメントでも、client_max_body_sizeを超えるリクエストには413を返すと説明されています。
ここが、413エラーで混乱しやすいところです。
設定画面で見えている数字と、実際に通信を止めている数字が、同じとは限りません。
最初に「どの操作で、何MBから失敗したか」を残す
設定を変える前に、まず次の4つをメモしておくと切り分けやすくなります。
何をアップロードしようとしたか
ファイルの形式と容量
どの画面やプラグインで失敗したか
エラーが出た時刻
そのうえで、同じ形式の小さいファイルなら通るかを試します。
小さいファイルは成功し、大きいファイルだけ失敗するなら、サイズ上限の可能性が高くなります。
反対に、小さいファイルでも失敗するなら、ファイル形式、権限、セキュリティ設定など、別の原因も考えた方がよさそうです。
エラーが出た時刻も大切です。
CDNやサーバーのログを確認するとき、時刻と対象URLが分かるだけでも、原因を探しやすくなります。
WordPressのサイトヘルスで「見えている上限」を確認する
WordPress管理画面の「ツール」→「サイトヘルス」→「情報」→「メディア処理」では、ファイルアップロードに関する上限を確認できます。
WordPress公式のサイトヘルス解説によると、ここではPOSTデータの最大サイズ、1ファイルの最大サイズ、実際に有効な最大サイズなどが表示されます。
WordPressのwp_max_upload_size()も、PHPのupload_max_filesizeとpost_max_sizeを確認し、小さい方を基準にします。
ここで大切なのは、サイトヘルスの数字を「原因の確定」と考えないことです。
これはWordPressから見えている上限です。
その手前にあるCDNやWebサーバーの上限まですべて表しているわけではありません。
いきなり全部を大きくしない
エラーを早く消したいと、PHP、Nginx、プラグインの設定を一度に変えたくなります。
でも、複数の数字を同時に変えると、どの変更で直ったのか分からなくなります。
さらに、リクエストサイズの上限は、サーバー資源を守る役割も持っています。
「大きければ大きいほど安心」ではないんですよね。
僕は、次の順番で考えるのが安全だと思います。
まずファイルを小さくできないか確認する
CDNやWAFを使っているなら、その上限とログを見る
NginxやApacheなどWebサーバーの設定を確認する
PHPのpost_max_sizeとupload_max_filesizeを確認する
WordPressやプラグイン独自の上限を確認する
自分でサーバー設定を変更できない環境なら、無理に設定ファイルを触らなくても大丈夫です。
失敗した時刻、対象URL、ファイル容量、サイトヘルスの数値をまとめて、ホスティング会社へ相談した方が早いこともあります。
エラーを消すより、原因を一つに絞る
413エラーが出ると、「上限を上げれば終わり」と考えやすいです。
でも、本当に知りたいのは、どの数字を大きくするかではありません。
どの層が、何MBで止めているのか。
ここが分かれば、ファイルを小さくするのか、サーバー設定を変えるのか、ホスティング会社へ相談するのかを選べます。
WordPressのトラブルは、見えている画面だけに原因があるとは限りません。
だからこそ、焦って触る場所を増やすより、入口を一つずつたどる。
その方が、直ったあとにも「なぜ直ったのか」が残ります。
413という数字が出たら、まずは容量を増やす前に、「このファイルはどこまで届いたんだろう」と考えてみてください。
それだけで、次に見る場所が少し見つけやすくなると思います。
