HTTP 413 Payload Too Large — 요청 본문 초과 원인·해결·예방

HTTP 413 Payload Too Large — 요청 본문 초과 원인·해결·예방

큰 이미지를 업로드하거나 첨부파일을 보냈더니 413 Payload Too Large가 돌아온다. 작은 파일은 멀쩡히 올라가는데 일정 크기를 넘으면 막힌다. 413은 "네가 보낸 요청 본문이 서버가 받아들이려는 한도보다 크다"는 뜻이다. 대부분 파일 업로드에서 만나고, 원인은 서버나 중간 장비에 걸린 용량 제한이다. 흔한 함정은 Nginx의 기본 본문 한도가 1MB라는 점이다. 이 글은 413이 정확히 무슨 의미인지, 어디서 한도가 걸리는지, 그리고 서버별로 어떻게 풀고 예방하는지를 정리한다.

HTTP 413 Payload Too Large

이 글의 구성

 

🔎413 Payload Too Large의 의미

🧩자주 나오는 발생 원인 5가지

💻재현과 한도 확인

🛠서버별 해결과 예방

⚖️414·431과의 차이

💬자주 묻는 질문 5가지

---

🔎 413 Payload Too Large의 의미

413은 4xx, 클라이언트 요청에 문제가 있다는 묶음에 속한다. 정확히는 "요청 본문(payload)이 서버가 처리하려는 크기보다 크다"는 뜻이다. 이름은 명세를 거치며 바뀌었다. 처음(RFC 2616)에는 Request Entity Too Large, 다음(RFC 7231)에는 Payload Too Large, 최신(RFC 9110)에서는 Content Too Large다. 코드 번호 413은 내내 그대로다.

 

핵심은 "전송 자체가 안 됐다"가 아니라 "받기엔 너무 크다고 거절당했다"는 점이다. 서버나 그 앞단의 웹서버·프록시가 본문 크기를 보고, 미리 정해 둔 한도를 넘으면 처리하지 않고 413을 돌려준다. 그래서 작은 파일은 통과하고 큰 파일만 막히는 것이다. 명세상 한도가 일시적인 경우라면 서버가 Retry-After 헤더로 "나중에 다시 시도하라"고 알려줄 수도 있지만, 보통은 용량 설정이 고정돼 있어 한도를 올리지 않는 한 같은 크기는 계속 막힌다.

핵심 — 어느 한 단이라도 한도를 넘으면 막힌다

요청은 보통 웹서버(Nginx) → 앱 서버(Express 등) 여러 단을 거친다. 이 중 한 곳이라도 본문 한도가 낮으면 거기서 413이 난다. 그래서 앱에서 한도를 올렸는데도 413이 계속 나면, 앞단 웹서버나 프록시의 한도를 의심해야 한다. 가장 흔한 범인은 Nginx의 기본값 1MB다.

---

🧩 자주 나오는 발생 원인 5가지

원인 1 — Nginx 기본 본문 한도 1MB

가장 흔하다. Nginx의 client_max_body_size 기본값은 1MB라, 그보다 큰 업로드는 별도 설정 없이는 413으로 막힌다. 1MB가 조금만 넘는 이미지 한 장에도 걸리는 이유다.

원인 2 — 앱 프레임워크의 본문 파서 제한

Express의 express.json()은 기본 100KB까지만 본문을 파싱하고 넘으면 413을 던진다. 다른 프레임워크도 비슷한 기본 제한이 있다. 웹서버는 통과했는데 앱에서 막히는 경우다.

원인 3 — Apache LimitRequestBody 설정

Apache는 LimitRequestBody로 본문 크기를 제한한다. 예전엔 무제한(0)이 기본이었지만 Apache 2.4.54부터 1GiB가 기본값이고, 운영상 더 낮게 걸어 두는 경우도 많아 그 한도를 넘으면 413이 난다.

원인 4 — 프록시·게이트웨이·WAF 한도

로드밸런서·API 게이트웨이·CDN·방화벽(WAF)도 자체 본문 한도를 둔다. 내 서버 설정을 다 올렸는데도 413이면, 그 앞의 중간 장비가 막는 경우가 많다.

원인 5 — base64 인코딩으로 부푼 크기

파일을 base64로 인코딩해 JSON에 담아 보내면 용량이 약 33% 늘어난다. 원본은 한도 안인데 인코딩 후 한도를 넘겨 413이 나기도 한다. 멀티파트 업로드로 바꾸면 이 부풀림을 피할 수 있다.

---

💻 재현과 한도 확인

413은 한도를 넘는 본문을 보내 보면 바로 재현된다. curl로 큰 파일을 업로드해 응답 코드를 확인한다.

# 큰 파일 업로드 → 413 재현 (-F 멀티파트)
curl -i -F 'file=@big-image.jpg' https://example.com/upload

# 응답 — 한도 초과
HTTP/1.1 413 Request Entity Too Large
server: nginx

테스트용으로 정해진 크기의 더미 파일을 만들어 경계값을 찾을 수도 있다. 어느 크기부터 막히는지 보면 어느 단의 한도인지 짐작할 수 있다.

# 2MB 더미 파일 생성 후 업로드 시도
dd if=/dev/zero of=test2m.bin bs=1M count=2
curl -i -F 'file=@test2m.bin' https://example.com/upload

# 1MB는 통과, 2MB는 413 → Nginx 기본 1MB 한도 의심

응답의 server 헤더가 nginx인지, 에러 페이지 문구가 어느 소프트웨어인지 보면 어디서 막혔는지 단서가 된다. 개발자도구 네트워크 탭에서도 업로드 요청의 Status가 413인지 확인할 수 있다.

---

🛠 서버별 해결과 예방

해결의 출발점은 "어느 단에서 막히는가"를 찾고, 그 단의 한도를 올리는 것이다. 단, 무작정 키우면 메모리·디스크·공격 위험이 커지므로 필요한 만큼만 올린다.

Nginx는 client_max_body_size를 올린다. http·server·location 어디에도 둘 수 있다.

# Nginx — 본문 한도 20MB로 상향
http {
    client_max_body_size 20m;   # 0 으로 두면 무제한(권장 안 함)
}

# 특정 업로드 경로만 키우려면 location 블록에
location /upload {
    client_max_body_size 50m;
}

Apache는 LimitRequestBody(바이트 단위), Express는 파서의 limit 옵션을 조정한다.

# Apache — 20MB (바이트 단위, 20*1024*1024)
LimitRequestBody 20971520

// Express — 본문 파서 한도 상향
app.use(express.json({ limit: '20mb' }));
app.use(express.urlencoded({ limit: '20mb', extended: true }));

근본적인 예방은 "큰 본문을 통째로 보내지 않는 것"이다. 한도를 키우는 것만으로는 더 큰 파일 앞에서 또 막힌다.

상향보다 나은 예방책

01클라이언트에서 업로드 전 이미지를 리사이즈·압축해 용량을 줄인다.

02큰 파일은 청크(분할)·재개 가능 업로드로 나눠 보낸다.

03스토리지(S3 등)로 프리사인 URL을 받아 서버를 거치지 않고 직접 업로드한다.

04JSON+base64 대신 multipart/form-data로 보내 33% 부풀림을 없앤다.

---

⚖️ 414·431과의 차이

413은 "본문이 크다"는 것이지만, 요청의 다른 부분이 너무 커서 나는 비슷한 코드들이 있다. 어느 부분이 큰지에 따라 코드가 갈린다.

코드	무엇이 큰가	대표 상황
413	요청 본문(payload)	큰 파일·이미지 업로드
414	URI(주소)가 너무 김	쿼리스트링에 데이터를 과도하게 실음
431	헤더가 너무 큼	쿠키·헤더 누적 과다

정리하면 413은 본문, 414는 주소(URI), 431은 헤더가 한도를 넘은 것이다. 셋 다 "요청의 어떤 부분이 너무 크다"는 점은 같지만 막힌 위치가 달라, 해결도 각기 다른 한도를 손봐야 한다. 파일 업로드에서 만나는 건 거의 413이다.

“

앱 한도를 올렸는데도 413이면 앞단 Nginx의 1MB를 의심하라. 한도를 키우기보다 큰 파일을 나눠 보내는 게 진짜 예방이다.

 

— 어느 단에서 막히는지부터

---

💬 자주 묻는 질문 5가지

Q1작은 파일은 되는데 큰 파일만 413이에요.

전형적인 본문 한도 초과입니다. 서버나 앞단 웹서버에 걸린 용량 제한을 넘은 것이죠. 어느 크기부터 막히는지 확인하면 어느 단의 한도인지 짐작할 수 있습니다. 1MB 근처에서 막히면 Nginx 기본값일 가능성이 큽니다.

Q2앱에서 한도를 올렸는데도 413이 나요.

앞단의 웹서버나 프록시가 막는 경우입니다. 요청은 Nginx → 앱 순으로 거치는데, Nginx의 client_max_body_size가 낮으면 앱에 도달하기 전에 413이 납니다. 웹서버·로드밸런서·WAF의 한도도 함께 올려야 합니다.

Q3한도를 아주 크게 잡으면 안 되나요?

권장하지 않습니다. 한도를 무제한이나 과도하게 키우면 큰 요청이 메모리·디스크를 잡아먹고, 대용량 업로드를 악용한 공격에도 취약해집니다. 필요한 만큼만 올리고, 큰 파일은 분할·직접 업로드로 처리하는 편이 안전합니다.

Q4JSON으로 보내는데 413이 나요.

파일을 base64로 인코딩해 JSON에 담으면 용량이 약 33% 늘어 한도를 넘기 쉽습니다. 또 Express 같은 프레임워크는 JSON 파서 기본 한도(예: 100KB)가 낮습니다. 파일은 multipart/form-data로 보내고, 파서 limit도 함께 점검하세요.

Q5413과 414는 어떻게 다른가요?

413은 요청 본문(업로드 데이터)이 크고, 414는 URI(주소)가 너무 긴 것입니다. 431은 헤더가 큰 경우죠. 셋 다 "요청의 어떤 부분이 한도를 넘었다"는 점은 같지만, 막힌 위치와 손봐야 할 설정이 다릅니다. 파일 업로드라면 거의 413입니다.

---

📌 결론

413 Payload Too Large는 "보낸 요청 본문이 서버 허용 한도보다 크다"는 신호다. 주로 파일 업로드에서 만나고, 원인은 서버·웹서버·프록시 중 어느 한 단에 걸린 용량 제한이다. 그래서 해결은 "어디서 막히는지"부터 찾는 데서 시작한다.

실무 원칙은 다음과 같다.

 

📦 막힌 단을 찾는다. 앱 한도를 올렸는데도 413이면 앞단 Nginx의 기본 1MB나 프록시·WAF 한도를 의심한다.

⚙ 필요한 만큼만 한도를 올린다. Nginx client_max_body_size·Apache LimitRequestBody·Express limit을 조정하되, 무제한은 피한다.

✂ 큰 파일은 나눠 보낸다. 클라이언트 압축, 청크·재개 업로드, 스토리지 직접 업로드, multipart 전환으로 근본 예방한다.

413 트러블슈팅 체크리스트

01어느 크기부터 막히는지 경계값 확인.

02Nginx client_max_body_size(기본 1MB) 확인·상향.

03앱 파서 한도(Express limit 등)·Apache LimitRequestBody 점검.

04로드밸런서·게이트웨이·WAF의 본문 한도 확인.

05base64 부풀림 회피 — multipart/form-data 사용.

06대용량은 압축·청크·스토리지 직접 업로드로 예방.

---

본 글은 HTTP 413 응답의 일반적 원인과 해결 방법을 정리한 자료다. 서버·업로드 한도 설정 변경은 영향 범위를 확인한 뒤 신중히 적용한다.

 

#HTTP413 #PayloadTooLarge #413에러 #파일업로드 #clientmaxbodysize #Nginx #Apache #LimitRequestBody #Express #본문크기제한 #멀티파트 #청크업로드 #WAF #웹개발 #백엔드