ERR_RESPONSE_HEADERS_TOO_BIG 원인

Problem

Chrome이 아무것도 없는 에러 페이지 — “이 페이지가 작동하지 않습니다” — 를 띄우고 하단에 ERR_RESPONSE_HEADERS_TOO_BIG 코드가 붙습니다. 내용도, HTTP 상태도, 사이트에서 온 그 무엇도 없습니다. 서버는 거의 확실히 답을 보냈습니다. Chrome이 그 답을 받기를 거부한 것뿐입니다.

이유는 대부분 부딪히기 전까지는 들어본 적도 없는 하드 리밋입니다. Chrome의 네트워크 스택은 도착하는 응답 헤더를 버퍼에 담는데, 그 버퍼에 천장이 있습니다. Chromium 소스에서는 kMaxHeaderBufSize 상수 — kHeaderBufInitialSize(4 KB)에 64를 곱한 값, 즉 256 KB입니다. Chrome이 그만큼의 헤더 바이트를 읽는 동안 응답 본문 시작을 못 찾으면, 포기하고 ERR_RESPONSE_HEADERS_TOO_BIG로 트랜잭션을 실패시킵니다. 이건 헤더만의 문제입니다. 40MB 이미지는 괜찮습니다. 예산을 터뜨린 건 본문 앞의 메타데이터입니다.

Symptoms

• 정확한 코드는 ERR_RESPONSE_HEADERS_TOO_BIG, Chrome 일반 에러 페이지에 HTTP 상태 번호 없이 표시됩니다.
• 보통 특정 사이트 — 쿠키나 응답이 뚱뚱해진 그 사이트 — 만 걸리고 나머지는 정상입니다.
• 첫 방문이 아니라, 로그인해서 한참 클릭하고 돌아다닌 뒤에 뜨는 경우가 많습니다. 상태가 쌓인 거죠.
• 그 사이트 쿠키만 지우면 즉시 사라지고(나중에 슬금슬금 돌아오기도 합니다).
• Firefox나 Safari에서는 같은 페이지가 잘 뜰 수 있습니다 — 헤더 한도가 더 크거나 다르게 처리해서, Chrome 전용 증상인 경우가 잦습니다.
• curl이나 외부 fetch로 URL을 받으면 성공하고, 유난히 긴 응답 헤더 블록이 보입니다.

ERR_RESPONSE_HEADERS_TOO_BIG의 실제 의미

응답 헤더 총합이 256KB를 넘었다는 뜻입니다. 헤더 하나가 아니라 — 총합입니다. Chrome은 그게 말도 안 되게 긴 Content-Security-Policy 하나든 별개의 Set-Cookie 400줄이든 상관 안 합니다. 헤더 블록의 바이트를 세다가, 헤더를 끝내는 빈 줄이 나오기 전에 카운트가 버퍼 크기를 넘으면 중단합니다.

이 관점이 중요한 건 보는 곳이 바뀌기 때문입니다. “헤더가 너무 크다”를 보면 사람들은 눈에 띄는 괴물 하나를 찾아 헤더를 하나씩 감사하기 시작합니다. 그런 하나가 있을 때도 있습니다. 하지만 더 흔한 건 천 번의 칼질로 인한 죽음입니다 — 각각은 작지만 합치면 넘치는 쿠키 누적. 실전 최다 원인은 쿠키에 계속 쓰는 사이트입니다 — 세션 데이터, 기능 플래그, 추적 ID, DB 대신 쿠키에 밀어넣은 “최근 본 항목” 목록이 커지다가, 매 응답마다 보내고 다시 세팅하는 더미가 선을 넘는 겁니다.

이 에러가 아닌 것을 분명히 해둘 가치가 있습니다. HTTP 413(요청 본문 초과)도, 414(요청 URI 초과)도, 431(서버가 당신의 요청 헤더를 거부)도 아닙니다. 셋 다 서버가 판단해 상태를 돌려주는 것입니다. ERR_RESPONSE_HEADERS_TOO_BIG는 Chrome이 로컬에서, 응답에 대해 내린 판단이라 — 거기까지 도달한 적이 없으니 상태 코드가 존재하지 않습니다.

Top Causes

1. 쿠키 누적 — 대표적. 앱이 커지는 상태를 쿠키에 저장하거나 여러 경로에 걸쳐 쿠키를 많이 세팅해서, 그 origin에 쌓인 브라우저 더미가 응답의 나머지와 합쳐져 결국 256KB를 넘습니다. “쿠키 삭제”로 고쳐지고, 앱이 그 쿠키를 다시 만들면 돌아오는 버전입니다.

2. 거대한 헤더 하나 — 소스 항목 수백 개짜리 괴물 Content-Security-Policy, 큰 인코딩 세션이나 SAML 토큰을 실은 뚱뚱한 Set-Cookie, 걷잡을 수 없이 커진 Report-To/NEL 블록. 헤더 하나가 혼자 예산을 다 먹을 수 있습니다.

3. Set-Cookie 루프 또는 잘못된 세션 — 서버가 매 응답마다 큰 쿠키 묶음을 다시 발급하거나 큰 값을 수십 조각으로 쪼개는 버그. 첫 응답부터 이미 거대하니 첫 방문자도 걸릴 수 있습니다.

4. 헤더를 추가하는 프록시/미들박스 — 리버스 프록시, WAF, SSO 게이트웨이가 origin이 이미 보낸 것 위에 큰 헤더(인증 컨텍스트, 디버그 정보, Via/X-Forwarded-* 더미, preload Link 헤더)를 주입. origin은 결백해 보이고, 헤더 부풀림은 경유 중에 더해진 겁니다.

DechoNet으로 진단

• HTTP 점검은 브라우저 밖에서 URL을 가져와, 서버가 실제로 보내는 응답 헤더를 — 브라우저가 쌓아둔 쿠키 하나 없이 — 보여줍니다. 그 외부 시야가 진단의 전부입니다. HTTP 점검이 정상적인 작은 헤더 묶음으로 돌아오면, 256KB 초과는 당신 브라우저에서만 벌어지는 것 — 즉 누적된 쿠키(또는 확장 프로그램)입니다. 그 사이트 쿠키를 지우면 끝입니다. HTTP 점검 자체가 거대한 헤더 블록을 보이면, origin이나 앞단 프록시가 원인이고, 어느 헤더가 큰지 정확히 읽어 그 서버 주인에게 넘길 수 있습니다.

Resolution Checklist

• 범위를 확인하세요. 한 사이트인가 전부인가? 한 사이트면 그 사이트의 쿠키나 응답, 진짜 전부면 응답을 주무르는 확장 프로그램 같은 로컬 요인.
• 해당 사이트 쿠키를 지우세요(Chrome 설정 → 개인정보 → 쿠키 → 모든 사이트 데이터 → 도메인 검색 → 삭제). 페이지가 뜨면 쿠키 누적을 확인한 겁니다.
• URL에 외부 HTTP 점검을 돌리세요. 거기선 정상인데 브라우저만 실패 = 로컬 쿠키/상태 문제, 여기서 끝. 거기서도 거대한 헤더 = 서버측, 계속 진행.
• 서버측이면 헤더 블록을 읽어 범인을 찾으세요: 거대한 CSP, 뚱뚱한 세션 쿠키, Set-Cookie 루프, 프록시 주입 더미. 그 하나를 줄이거나 고칩니다.
• 범인이 쿠키 저장 상태라면 있어야 할 곳으로 옮기세요 — 페이로드 전부를 쿠키에 넣지 말고, 짧은 쿠키 ID를 쓰는 서버측 세션으로. 계속 고쳐져 있는 유일한 해법입니다.
• 프록시나 게이트웨이가 헤더를 추가한다면, 주입 헤더를 쳐내거나 실제 원인을 줄이는 동안 임시로 그 홉의 헤더 버퍼를 키우세요.

When to Escalate

• 외부 HTTP 점검에서 헤더가 거대하면, 이건 서버·인프라 수정이지 방문자가 풀 수 있는 게 아닙니다. 구체적 헤더 이름과 함께 origin이나 프록시 운영자에게 넘기세요 — “CSP가 300KB다”, “쿠키를 600개 세팅한다”는 조치 가능한 버그 리포트입니다.
• 앱이 설계상 의미 있는 상태를 쿠키에 저장한다면, 헤더 조정이 아니라 아키텍처 이슈로 올리세요. 어딘가의 버퍼를 키우면 시간은 벌지만, 페이로드는 서버측에 있어야 하고, 거기로 옮기기 전까지는 충분히 상태를 쌓은 누구에게든 에러가 계속 재발합니다.