先に結論
413はサーバーが処理可能または許可された上限より要求内容が大きい時の応答です。アプリの設定だけを増やさず、CDN・WAF・load balancer・reverse proxy・framework・アプリの順に、最初に要求を拒否した層と実際のrequest sizeを特定します。
上限を変える前に拒否した層を探す
- 対象URL、method、発生時刻、ファイルとrequest全体のサイズ、status、request IDを保存する。
- 何MBまで成功し、どのサイズから失敗するかを安全な検証データで確認する。
- CDN／WAF／LBのログに413があるか、アプリまでrequestが到達したかを確認する。
- 圧縮、multipart境界、複数ファイルを含むrequest全体のサイズを確認する。
- 直前のplan、proxy、framework、upload機能変更を差分化する。
先に見る場所：アプリログに要求がなければ手前のCDN／proxy、到達後に413ならframework／アプリ上限を優先します。閾値が契約planの上限と一致する場合は公式の現行制限を確認します。
失敗条件から上限の所在を絞る
| 観測 | 優先候補 | 次の確認 |
|---|---|---|
| 全uploadが同じ閾値で失敗 | CDN・proxy上限 | plan、body size、edge log |
| 特定pathだけ | location・route設定 | path別上限、WAF rule、handler |
| 複数ファイルだけ | request全体の上限 | multipartを含む総byte数 |
| アプリに記録なし | edge・LB・proxy | request IDを入口から追跡 |
| アプリ到達後に失敗 | framework・middleware | parser、upload、temp storage |
| サイズでなく回数に依存 | rate limit | 429とRetry-Afterを確認 |
入口からアプリまで上限表を作る
- CDN／WAFの契約planと現行のrequest body上限を公式資料で確認する。
- load balancer・API gateway・reverse proxyのpath別上限を確認する。
- frameworkのbody parser、multipart、server actionなどの上限を確認する。
- アプリの拡張子・件数・user別上限と、一時保存先の空き容量を確認する。
- 各層の最小値が実効上限になるため、必要値と一致するよう構成管理へ反映する。
Cloudflareなどの上限は契約planや提供条件で変わるため、固定値を別資料から転記せず、利用中planの公式制限表を確認します。
必要以上に上限を広げない
業務上必要な最大サイズを決め、対象path、認証済み利用者、ファイル種別、件数を限定します。大容量が常態なら、分割・再開可能uploadやobject storageへの直接uploadを検討し、アプリサーバーのメモリへ全内容を保持しない設計にします。変更後は上限直前・直後と同時uploadを検証します。
避ける操作
- CDN・proxy・アプリの全上限を無制限または最大値へ一括変更する。
- 認証・拡張子・rate limitなしで大容量uploadを公開する。
- 本番ファイルや個人情報を外部のサイズ検証サービスへ送る。
- メモリ・一時ディスク・timeoutを確認せず上限だけ増やす。
- 413を500へ置換し、利用者と運用者から原因を隠す。
公式情報
よくある質問
413 Content Too LargeとPayload Too Largeは同じですか？
現在のHTTP仕様では413 Content Too Largeです。以前の名称Request Entity Too LargeやPayload Too Largeもエラー画面や検索語として残っていますが、いずれも要求内容が許容上限を超えた状態を指します。
アプリのアップロード上限を増やしても413が消えません
CDN、WAF、load balancer、reverse proxy、framework、アプリなど手前の層に別の上限がある可能性があります。アプリにrequest記録がなければ、手前の層から確認します。
上限を無制限にすれば安全ですか？
推奨しません。メモリ・一時ディスク・処理時間の枯渇やDoSリスクが増えます。業務上必要な最大サイズを決め、認証、対象path、rate limit、保存容量、timeoutと合わせて狭く設定します。