413 Payload Too Large 진단

Problem

요청에 대한 최종 응답 코드가 413 Payload Too Large로 반환됩니다(RFC 9110에서는 공식 명칭이 413 Content Too Large로 바뀌었고, 여전히 많은 서버가 413 Request Entity Too Large로 표시합니다).

Symptoms

• HTTP Check에서 최종 코드가 413입니다.
• 작은 요청은 되는데, 파일 업로드나 큰 JSON/XML 본문은 실패합니다.
• 폼·API 호출·업로드가 매번 특정 크기 임계점에서 죽습니다.

413이 실제로 뜻하는 것

RFC 9110(§15.5.14)은 413을 “서버가 처리할 의향보다 큰” 본문을 가진 요청으로 정의합니다. 그게 전부입니다 — 데이터, 인증, 라우트에는 아무 문제가 없습니다. 경로 어딘가의 한 층이 본문 크기를 재고, 너무 크다고 판단해 거부한 것이죠. 스펙은 이미 거부한 본문을 끝까지 읽는 대신 서버가 연결을 끊는 것을 허용합니다. 그래서 413은 가끔 깔끔한 응답이 아니라 절반만 끝난 업로드나 갑작스러운 리셋으로 나타납니다.

함정은 “서버”가 곧 당신의 애플리케이션이라고 가정하는 것입니다. 현대 스택에서 본문은 CDN → 리버스 프록시 → (경우에 따라) 인그레스 컨트롤러 → 앱을 거치는데, 각 층은 저마다의 크기 한도를 독립적으로 설정합니다. 먼저 “안 돼”라고 말하는 층이 이깁니다. nginx가 두 홉 전에 이미 413을 반환했다면, 앱에서 한도를 고쳐도 아무 소용이 없습니다.

Top 3 Causes

1. 리버스 프록시 한도가 너무 낮음 - nginx는 client_max_body_size를 기본 1 MB로 두고, 본문이 이를 넘는 순간 앱이 1바이트도 보기 전에 413을 반환합니다. 가장 흔한 413 원인입니다. Apache의 LimitRequestBody, 프레임워크의 body-parser 한도도 설정 파일만 다를 뿐 같은 얘기입니다.
2. CDN·플랫폼의 하드 한도 - Cloudflare는 요청 본문을 Free·Pro에서 100 MB(Business 200 MB, Enterprise 500 MB)로 제한하고 엣지에서 413을 반환합니다 — 오리진에는 요청이 닿지도 않으니 오리진 설정으로는 못 고칩니다. 대부분의 매니지드 플랫폼에 당신이 올릴 수 없는 비슷한 한도가 있습니다.
3. IIS / ASP.NET이 별도 한도 두 개를 적용 - IIS Request Filtering은 본문을 기본 약 28.6 MB로 제한하고 413이 아니라 404.13으로 보고합니다. ASP.NET은 그 위에 자체 maxRequestLength(4096 KB)를 얹습니다. 둘 다 올바른 설정 위치에서 올려야 하며, 안 그러면 낮은 쪽이 계속 이깁니다.

Diagnose with DechoNet

• HTTP Check로 최종 코드가 413인지 확인하고 응답 헤더를 읽습니다 — Retry-After 헤더는 일시적 속도·크기 제한을 가리키고, 서버 배너(nginx, cloudflare, Microsoft-IIS)는 어느 층이 본문을 거부했는지 알려줍니다.
• DNS Lookup으로 요청이 당신이 생각하는 호스트에 닿는지, 그리고 오리진에 오기 전 자체 한도를 거는 CDN을 거치는지 확인합니다.

Resolution Checklist

• 깨지는 정확한 크기를 찾습니다 — 1 MB는 nginx 기본값, 약 28.6 MB는 IIS, 100 MB는 Cloudflare Free/Pro를 가리킵니다. 숫자가 범인을 지목합니다.
• 413 응답의 Server 헤더를 읽어 어느 층이 답했는지 봅니다(nginx, cloudflare, Microsoft-IIS, 앱 프레임워크).
• nginx의 client_max_body_size(또는 Apache LimitRequestBody)를 실제 최대 업로드보다 큰 값으로 올리고 reload 합니다.
• IIS에서는 requestLimits maxAllowedContentLength 와 ASP.NET maxRequestLength를 둘 다 올립니다 — 안 그러면 낮은 쪽이 계속 막습니다.
• CDN이 한도를 건다면, 통제할 수 없는 한도를 올리려 하지 말고 큰 업로드를 CDN 밖으로 우회시킵니다(스토리지 직행 signed URL).
• HTTP Check를 다시 실행해 풀사이즈 요청이 더 이상 413을 내지 않는지 확인합니다.

When to Escalate

• 한도가 CDN·플랫폼의 것이고 현재 요금제에서 설정 불가라면, 그 소유자에게 넘깁니다 — 유일한 진짜 해결책은 다른 업로드 경로입니다.
• 문서화된 모든 한도를 올렸는데도 413이 계속 나오면, 일반 크기 검사보다 먼저 본문을 크기로 검사·거부하는 WAF나 보안 규칙을 의심합니다.