WordPressで画像、動画、テーマ、プラグイン、バックアップファイルを送ったとき、「413 Content Too Large」「413 Payload Too Large」「Request Entity Too Large」と表示されることがあります。フォーム送信やREST APIだけ失敗し、普通のページ閲覧はできる場合もあります。
413は、送信した内容が受け側の上限を超えたときに返されるHTTPステータスです。ただし、上限はWordPressだけにあるわけではありません。CDN、WAF、リバースプロキシ、Webサーバー、PHP、WordPress、プラグインのどこでも制限される可能性があります。
最初からすべての上限を大きくしたり、上限確認を無効にしたりしないでください。何を、どのURLへ、どの大きさで送ったときに、どの層が413を返したかを確認し、必要な場所だけを調整します。
先に結論：413エラーは7段階で確認する
- 送信を止め、入力内容やファイルを手元へ保存する
- 失敗したURL、操作、時刻、HTTP 413を記録する
- 小さな既知ファイルや短い本文で一度だけ比較する
- 応答ヘッダーとエラー画面から413の発行元を絞る
- 管理画面に表示されるアップロード上限を確認する
- CDN、Webサーバー、PHP、WordPressの順に上限を照合する
- 必要なサイズだけへ調整し、復旧後に防御とログを確認する
画像だけ失敗する場合は、先にWordPressで画像をアップロードできないときの確認順も確認してください。413ではなく、ファイル形式、権限、容量不足、画像処理の失敗なら対処が異なります。
413 Content Too Largeとは？
RFC 9110の413 Content Too Largeは、要求の内容がサーバーの処理可能または処理意思のある大きさを超えたため、サーバーが要求を拒否した状態です。条件が一時的なら、サーバーは再試行時刻を示すRetry-Afterを返すことがあります。
以前の文書やエラー画面では「Payload Too Large」「Request Entity Too Large」という名称も使われます。名前が違っても、まず確認するのは送信内容の大きさと受信上限です。ただし、エラー画面だけで上限の場所までは決まりません。
413はファイル単体の容量だけで起こるとは限りません。複数ファイル、フォーム項目、JSON、XML、投稿本文、画像をまとめた要求全体が上限を超える場合もあります。圧縮ファイルの展開後サイズやWordPressのディスク使用量とは、別の確認項目です。
400・413・414・504の違い
| 表示 | 主な意味 | 最初に見るもの |
|---|---|---|
| 400 Bad Request | 要求の構文・内容・ヘッダーなどを処理できない | URL、Cookie、ヘッダー、送信形式 |
| 413 Content Too Large | 要求内容が受信・処理上限を超えた | 要求全体のサイズ、各層の上限 |
| 414 URI Too Long | URL自体が長すぎる | URL、クエリ文字列、転送 |
| 504 Gateway Timeout | 中継側が上流の応答を期限内に受け取れない | 処理時間、負荷、CDN・サーバーログ |
URLやCookie、要求形式が疑わしい400なら、WordPressの400 Bad Requestを直す確認順へ進みます。大きなファイルの処理が長引いて504になる場合は、WordPressの504 Gateway Timeoutを直す手順が対象です。
最初の10分で行う安全な初動
1．送信を止めて内容を退避する
記事保存やフォーム送信で413が出た場合は、本文や入力内容をローカルの安全な場所へコピーします。バックアップ復元、インポート、外部連携は自動再試行を止め、同じデータを連続送信しないでください。
413は大きさの問題なので、同じ要求を連打しても通常は改善しません。フォーム、注文、予約、会員登録など更新を伴う処理では、途中まで受理されていないか管理画面や通知も確認します。
2．エラーと送信条件を記録する
エラー画面全体、完全なURL、発生時刻とタイムゾーン、操作、ファイル名、ファイル単体の大きさ、ファイル数を記録します。開発者ツールを使える場合は、実際のHTTPステータス、Request URL、Request Method、応答本文、応答ヘッダーも確認します。
Cookie、Authorization、APIキー、フォームの個人情報をスクリーンショットやHARへ残さないでください。サポートへ共有する場合も秘密部分を伏せ、サイズと時刻、要求IDだけを伝えます。
3．小さな既知データで一度だけ比較する
画像なら、同じ形式で十分に小さい既知ファイルを一つだけ送ります。小さいファイルは成功し、大きいファイルだけ413なら、サイズ上限の可能性が高まります。どのサイズから失敗するかを探すために大量のファイルを繰り返し送る必要はありません。
すべてのサイズで失敗する場合は、413ページがキャッシュされている、送信URLが違う、権限やファイル形式が原因、サービス自体が停止している可能性もあります。番号だけで上限と断定せず、応答を再確認します。
どの層が413を返したか特定する
WordPressへ到達する前に413が返れば、WordPressやPHPのログには要求が残らないことがあります。反対に、PHPやプラグインが拒否した場合は、Webサーバーのアクセスログに要求があり、WordPress側にエラーメッセージが残ることがあります。
| 確認場所 | 手がかり | 主な担当 |
|---|---|---|
| CDN・WAF | CDNの識別ID、独自エラー画面、配信元ログに要求がない | CDN設定・ホスト |
| Webサーバー・プロキシ | アクセスログに413、上流へ転送した記録がない | サーバー会社・管理者 |
| PHP | POSTデータやアップロードが上限を超えた記録 | サーバー会社・制作者 |
| WordPress・プラグイン | 管理画面の上限表示、アップロードやインポート固有のエラー | WordPress管理者 |
WordPressのwp_max_upload_size()公式資料では、WordPressがPHPのupload_max_filesizeとpost_max_sizeを読み、小さい方をアップロード上限の基礎として使うことが確認できます。ただし、その手前にあるCDNやWebサーバーの上限までは表しません。
Cloudflareを利用している場合も、配信元の上限とCloudflare側の上限を分けます。Cloudflareの413公式資料では、プランやゾーン設定に応じた最大アップロードサイズが案内されています。数値は変更され得るため、入稿時点の契約画面と公式資料で確認してください。
原因別の安全な直し方
1．画像・動画・添付ファイルが大きい
Web表示用の画像なら、必要な表示寸法へ縮小し、画質を確認しながら適切に圧縮します。画像をZIPへ入れるだけでは、アップロード後に使えない場合があります。用途を変えずに軽量化する方法は、WordPress画像最適化の基本を参考にしてください。
動画や大容量配布ファイルをWordPressメディアへ直接置く必要があるかも見直します。外部ストレージや動画配信を使う場合は、公開範囲、料金、バックアップ、直リンク対策を確認し、単に上限回避だけで選びません。
2．バックアップ・移行・インポートファイルが大きい
バックアップや移行ツールには、分割、サーバー側配置、専用転送、除外設定が用意されている場合があります。大きな一つのファイルを管理画面から繰り返し送る前に、利用中ツールとホストの公式手順を確認します。
分割時は、データベース、アップロード、テーマ、プラグインの対応関係を崩さないでください。復元可能性を確認する方法はWordPressのバックアップを安全に取る手順、移行前の確認はWordPress移行前チェックリストで整理できます。
3．フォーム・REST API・JSONの要求全体が大きい
添付ファイル数、画像のBase64埋め込み、長い本文、カスタムフィールド、まとめて送る件数を確認します。APIは必要な項目だけを送り、対応している場合は分割アップロードや小さなバッチへ変更します。ただし、処理の重複や順序ずれが起きない設計が必要です。
記事保存でJSONエラーも出る場合は、WordPressの「正しいJSONレスポンスではありません」を直す手順で実際のHTTP応答を確認します。413を隠して200へ置き換えたり、REST APIを全面停止したりしないでください。
4．NginxなどWebサーバーの上限が小さい
Nginx公式のclient_max_body_size資料では、要求本文が設定値を超えると413を返すと説明されています。設定は全体、仮想ホスト、特定パスの単位で異なるため、実際に失敗したURLへ適用される値を確認します。
上限を0にして検査を無効化したり、必要量を大きく超えて設定したりしません。最大ファイルだけでなく、フォーム項目を含む要求全体、同時送信数、ディスク空き容量、処理時間も考慮し、ホストの推奨範囲内で調整します。
5．PHPのpost_max_sizeとupload_max_filesize
PHP公式の設定資料では、upload_max_filesizeは一つのアップロードファイルの上限で、post_max_sizeはPOSTデータ全体の上限です。公式資料では、post_max_sizeをupload_max_filesizeより大きくする必要があると説明されています。
レンタルサーバーでは、管理画面から変更できる値、サポート依頼が必要な値、変更できない値があります。php.ini、.user.ini、.htaccessへ同時に追記せず、ホスト公式の一つの方法だけを使い、変更前の値と戻し方を残します。
PHP設定を扱う前に、現在のバージョンと変更範囲はWordPressのPHPバージョンを安全に確認・更新する方法で確認してください。413を直すためにPHPバージョンまで同時に変更する必要はありません。
6．CDN・WAF・プラグイン独自の上限
CDN、WAF、フォーム、会員機能、バックアップ、インポートの各製品が独自上限を持つ場合があります。該当URL、送信サイズ、同時刻のイベントログを照合し、製品全体を停止せず、対象機能の公式設定を確認します。
WAFを停止すると、上限以外の攻撃検査まで外れる可能性があります。検証が必要なら、バックアップと代替管理経路を確保し、対象URL・送信元・時間を限定して行い、すぐ元へ戻します。
413対応でやってはいけないこと
- CDN、Webサーバー、PHP、WordPressの上限を同時に変更する
- 上限を0や極端に大きな値へ変えて放置する
- WAF、認証、REST APIを全面停止する
- 同じ大容量ファイルやフォームを連打する
- 入力内容を退避せず、ブラウザを再読み込みする
- 413を正常な200応答へ見せかける
- ホスト非推奨の設定を複数ファイルへ重複して書く
- バックアップの復元確認なしに元データを削除する
- 個人情報や認証情報を含むHAR・ログを公開する
- 公開ページまで一律に大容量POSTを許可する
復旧後に確認すること
- 必要なファイルまたは要求が一度だけ成功する
- 小さいファイルと通常の投稿保存も成功する
- 管理画面の表示上限と実際の上限が矛盾していない
- CDN、Webサーバー、PHPの変更箇所を記録した
- WAFや認証など必要な防御が有効である
- 一時ファイルとディスク容量に異常がない
- 自動再試行や移行処理を重複なく再開した
- アクセスログで同じ413が繰り返されていない
公開ページが誤って413を返す状態も放置しません。GoogleのHTTPステータス公式資料では、429以外の4xxを返すURLの内容は検索に利用されず、既存URLも時間とともにインデックスから外れると説明されています。公開URLは200、送信上限を超えた操作だけが413になる状態を確認します。
サーバー会社へ伝える情報
- 発生日時とタイムゾーン
- 失敗したURLと操作
- HTTP 413とエラー画面の文言
- ファイル単体のサイズ、ファイル数、要求全体の概算
- 小さい既知ファイルとの比較結果
- CDN・WAFの利用有無と識別ID
- 管理画面に表示された最大アップロードサイズ
- 直前に変更した設定、プラグイン、テーマ
- 秘密情報を伏せた応答ヘッダーと要求ID
「413を直してください」だけでなく、「7月22日15時、メディア追加で12MBの画像だけ413。1MBの同形式画像は成功。CDN利用あり、配信元ログには該当要求なし」のように伝えると、調査する層を絞れます。
よくある質問
WordPressの最大アップロードサイズを増やせば直りますか？
WordPressやPHPが拒否している場合は候補ですが、CDNやWebサーバーが先に413を返していれば、WordPress側だけ変えても直りません。ログと小さいファイルの比較で発行元を確認してください。
画像を圧縮すれば必ず直りますか？
画像単体が上限を超えているなら有効ですが、複数ファイルやフォーム全体、別の送信データが原因なら直らない場合があります。用途に必要な品質を保ち、送信要求全体の大きさも確認します。
413とサーバー容量不足は同じですか？
同じではありません。413は要求内容の大きさに対する拒否です。ディスク容量不足はアップロード後の書き込み失敗や別のエラーになることがあります。ただし、復旧時には一時領域を含む空き容量も確認します。
Retry-Afterがあれば待つだけでよいですか？
一時的な条件なら指定時刻後の再試行が候補です。ただし、恒久的なサイズ上限を超えている場合は、待っても同じ413になります。要求を保存し、発行元と上限を確認してから一度だけ試します。
バックアップファイルを分割してもよいですか？
利用中のバックアップ・移行ツールが公式に分割復元へ対応している場合だけ、その手順を使います。任意にファイルを分けると復元できなくなるため、先に復元手順と完全性の確認方法を確保してください。
まとめ
WordPressの413 Content Too Largeは、送信した要求内容が受け側の上限を超えた状態です。ファイル単体だけでなく、フォームやAPIの要求全体、CDN、Webサーバー、PHP、WordPress、プラグインの上限を分けて確認します。
安全な復旧の基本は、小さな既知データで範囲を分け、413を返した層の上限だけを必要量へ調整することです。発行元を確認できない場合は、時刻、URL、サイズ、比較結果をそろえてサーバー会社や制作者へ相談してください。