ERR_INCOMPLETE_CHUNKED_ENCODING과는 어떻게 다른가요?

같은 병, 다른 형식입니다. ERR_CONTENT_LENGTH_MISMATCH(net error -354)는 응답이 Content-Length: N을 선언해 놓고 N보다 적은 바이트에서 연결이 끊길 때 납니다. ERR_INCOMPLETE_CHUNKED_ENCODING(-355)은 chunked 전송판입니다: 본문이 Transfer-Encoding: chunked를 쓰는데 종료용 0바이트 청크가 도착하기 전에 연결이 끊깁니다. 둘 다 서버가 본문 도중 전송을 멈춘 것 — 브라우저가 그걸 잡아낸 바이트 계산 방식만 다릅니다.

왜 큰 파일에서만, 또는 가끔만 발생하나요?

흔한 원인이 자원 한도이고, 그 한도에 부딪히는 건 더 크거나 느린 응답이기 때문입니다. 워커 타임아웃, 메모리 상한, 프록시 버퍼가 긴 본문 도중에 차고, 선언된 길이에 닿기 전에 연결이 죽습니다. 작은 응답은 한도에 물리기 전에 끝나죠. 그래서 2KB 페이지는 멀쩡한데 5MB 다운로드가 간헐적으로 실패합니다.

gzip이나 압축이 ERR_CONTENT_LENGTH_MISMATCH를 일으킬 수 있나요?

네, 교묘한 경우입니다. 한 계층이 Content-Length를 비압축 크기로 설정하고 다른 계층이 본문을 압축하거나 — transform·edge 워커가 헤더를 안 고치고 본문을 다시 쓰면 — 광고된 길이가 실제 바이트와 안 맞습니다. 브라우저는 실제 도착한 양을 세고, 부족분을 보고, 오류를 냅니다. 압축과 Content-Length 수동 설정을 동시에 하는 것을 점검하세요.

조회수: 6

ERR_CONTENT_LENGTH_MISMATCH 해결

ERR_CONTENT_LENGTH_MISMATCH는 서버가 약속한 바이트보다 적게 보냈다는 뜻. 프록시·디스크·워커 중 무엇이 끊었는지 3단계로 가립니다. 무료 즉시 진단으로 바로 확인.

내 도메인에 이 문제가 있는지 지금 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

Problem

페이지나 리소스가 절반쯤 로드되다 실패합니다. DevTools에 Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH — Chromium net error -354: 연결이 닫히기 전에 응답 본문이 Content-Length 헤더가 광고한 것보다 적은 바이트를 전송함.

Symptoms

리소스(이미지·스크립트·다운로드·페이지 전체)가 도중까지 로드되다 멈춥니다. 깨진 이미지나 잘린 파일로 끝나는 경우가 많습니다.
DevTools Network 탭에 그 요청이 빨갛게 ERR_CONTENT_LENGTH_MISMATCH로 뜹니다.
간헐적이거나, 작은 건 멀쩡한데 큰 파일에서 터집니다.

ERR_CONTENT_LENGTH_MISMATCH가 실제로 뜻하는 것

Content-Length: 500000을 보내는 서버는 약속을 하는 겁니다. “이 본문은 정확히 500,000바이트다.” 브라우저는 그 약속을 붙잡습니다. 바이트가 도착하는 대로 세다가, 410,000에서 연결이 끊기면 응답이 잘렸음을 압니다 — 반쪽 파일은 없는 파일보다 나쁘니까, 전부 버리고 오류를 냅니다.

그래서 이건 연결 오류가 아니라 잘림 오류입니다. 핸드셰이크는 됐고, 헤더는 도착했고, 본문이 흐르기 시작했습니다. 무언가 그걸 도중에 죽인 겁니다. 그러니 질문은 “왜 연결이 안 되나”가 아니라 “무엇이 본문을 끝까지 못 가게 했나”입니다: 오리진이 쓰기를 멈췄거나, 중간 프록시가 전체를 통과시키지 못했거나, 선언된 길이가 애초에 거짓이었거나.

Top 3 Causes

오리진이 응답 도중 쓰기를 멈춤 - 워커가 크래시 났거나, 메모리 상한에 닿았거나, 타임아웃(PHP-FPM max_execution_time, FastCGI·proxy_read_timeout, 앱 레벨 데드라인)이 — Content-Length를 포함한 헤더가 이미 나간 뒤에 — 발동했습니다. 본문이 단두대에 잘립니다. 부하 상황 간헐 실패의 전형입니다.
리버스 프록시가 본문 전체를 못 넘김 - 잘 알려진 사례는 nginx가 응답을 100% 찬 디스크의 임시 파일에 버퍼링하는 것입니다: 버퍼된 복사본이 짧아서 클라이언트가 약속보다 적게 받습니다. 잘못된 proxy_buffering, 리셋하는 업스트림, client_max_body_size·버퍼 한도도 같은 식으로 자릅니다.
Content-Length가 실제 바이트와 안 맞음 - 압축·transform 계층이 헤더를 안 고치고 본문 길이를 바꿉니다 — Content-Length를 비압축 크기로 설정한 뒤 gzip이 적용됐거나, 이중 압축이거나, edge·transform 워커가 본문을 다시 썼거나. 헤더는 한 숫자를 말하는데, 회선엔 다른 숫자가 흐릅니다.

Diagnose with DechoNet

HTTP Check를 네트워크 밖에서 실행해 진짜 응답 헤더를 잡고 오리진에서 본문 전체가 도착하는지 확인합니다. 이 진단은 완전한 응답을 받는데 당신 브라우저만 잘리면, 서버가 아니라 당신과 오리진 사이의 무언가(프록시·VPN·로컬 네트워크)를 의심하세요.
Port Check는 실패가 연결 끊김에 몰릴 때 씁니다 — 오리진 포트가 계속 열려 받는지 확인하면 펄럭이는 리스너를 배제하고 조사를 응답 본문 자체로 되돌립니다.

Resolution Checklist

curl로 재현하고 바이트를 헤더와 비교합니다: curl -sv https://yoursite.com/path -o /dev/null — Content-Length 값과 실제 받은 바이트를 봅니다.
실패한 요청 시각에 오리진 로그에서 크래시·OOM·타임아웃(PHP-FPM, 앱 서버, FastCGI)을 확인합니다 — 잘린 본문 뒤에는 거의 항상 죽었거나 타임아웃 난 워커가 있습니다.
프록시·오리진 호스트에서 df -h를 돌립니다 — 꽉 찬 디스크는 응답 버퍼링을 정확히 이렇게 깨뜨립니다. 공간을 비우거나 proxy_temp_path 볼륨을 확인합니다.
테스트로 프록시 버퍼링을 끄고(nginx proxy_buffering off;) 오류가 사라지는지 봅니다 — 사라지면 버퍼·임시 파일 경로가 범인입니다.
압축과 Content-Length 수동 설정을 동시에 하는 계층을 점검합니다. 헤더를 최종(압축 후) 본문에서 계산하게 하거나, Transfer-Encoding: chunked를 쓰고 Content-Length를 떼세요.
HTTP Check를 다시 돌려 본문 전체가 일치하는 길이로 도착하는지 확인합니다.

When to Escalate

정적 자산에서 일관되게 나는 불일치는 프록시나 오리진의 설정 버그(압축·길이 또는 버퍼링)입니다 — 그 설정 담당자에게 넘기세요. 클라이언트 쪽 수정으로는 안 됩니다.
부하에서 간헐적으로 나는 불일치는 안정성 문제입니다: 브라우저에서 쫓지 말고 워커 크래시·메모리 한도·타임아웃으로 넘기세요.