アップロードで413が出たら？ファイル容量とサーバーの受信上限を分けよう

画像を送ったら413という番号が出た。通信が遅いから何度も送ればよい、とは限らないよ。受け付ける要求の大きさに関係する応答かもしれない。

このページでは、HTTPの413 Content Too Largeと、利用者側・運営側で確認することを整理する。実際の大容量ファイルや公開サーバーへの負荷テストは不要。架空の容量を使って考えよう。

413は、要求が大きすぎるという応答

HTTPはブラウザとサーバーなどが要求・応答をやり取りする仕組み。413は、サーバーが処理する意思または能力のある大きさを、要求の内容が超えることを表す。

以前の名称Payload Too Largeを見かけることもある。ページの見出しが少し違っても、応答番号と発生した操作を確認しよう。すべてのアップロード失敗が413になるわけではないよ。

ファイルの容量と要求全体は同じではない

ファイルが10MBだから、上限10MBの場所で必ず送れるとは限らない。フォームの情報や区切りなどが加わり、要求全体はファイル本体より大きくなる場合がある。

同じ「10MB」でも単位の定義が違う場合もある。正確に比べる必要があるときは、バイト数と、どの上限なのかを確認するのが近道だよ。

サイトを利用する人が確認する順番

1. 応答番号、送信した時刻、操作したページを記録する。
2. 画面にあるファイル形式・容量・件数の条件を読む。
3. 元のファイルを残し、複製した画像などで容量を小さくできるか検討する。
4. 複数ファイルなら、サイトが認める方法で分けて送れるか確認する。
5. 条件内でも失敗するなら、運営へ確認する。

拡張子を書き換えるだけでは、内容の容量や形式は変わらない。圧縮や画像の書き出しでは、読める文字や必要な画質が失われていないかも見る。機密資料を、案内されていない別サービスへ勝手に移す必要はないよ。

サイトを運営する人は、入口からたどる

要求は、CDN、リバースプロキシ、Webサーバー、アプリなどを通る場合がある。アプリの設定だけを上げても、その手前で拒否されれば到達しない。

どの層が413を返したのか、要求の記録や設定を照合しよう。上限を無制限にする前に、必要な容量、保存領域、処理時間、同時送信なども検討する。公開サイトで大きな送信を繰り返して確認するのは避けたいね。

時間を空ければ解決する？

サーバーが一時的な条件としてRetry-Afterを返す場合もある。ただし、いつも待てば容量制限が外れるという意味ではない。画面の案内や管理者の説明を確認し、連打せず、条件に合う送り方を選ぼう。

ファイルの種類は拡張子と形式、別の制限応答は429と再試行へ。

参照した公式資料

• MDN：413 Content Too Large

確認日：2026年10月25日。