400 Bad Request 진단

Problem

요청에 대한 최종 응답 코드가 400 Bad Request로 반환됩니다.

Symptoms

• HTTP Check에서 최종 코드가 400입니다.
• 브라우저에 단순한 “Bad Request” 페이지가, 때로는 “Request Header Or Cookie Too Large”와 함께 표시됩니다.
• 특정 클라이언트에서만 발생하거나, 해당 사이트의 쿠키를 지우면 사라질 수 있습니다.

400이 실제로 뜻하는 것

RFC 9110(§15.5.1)은 400을 “클라이언트 오류로 인식되는 무언가(예: 잘못된 요청 구문, 잘못된 메시지 프레이밍, 기만적 라우팅) 때문에” 서버가 요청을 처리할 수 없거나 처리하지 않는 상태로 정의합니다. 핵심은 인식입니다 — 서버는 요청을 수행해 보기도 전에 망가졌다고 판단하므로, 요청은 애플리케이션 로직에 아예 도달하지 못합니다.

그래서 400은 500과 다릅니다. 500은 일단 받아들인 요청에서 애플리케이션이 실패한 것이고, 400은 요청이 문 앞에서 거부된 것입니다. 스펙은 클라이언트가 “수정 없이 요청을 반복해서는 안 된다(SHOULD NOT)“고도 적습니다 — 같은 바이트를 다시 보내면 같은 400이 돌아옵니다.

Top 3 Causes

1. 헤더·쿠키 초과 - 실제로 가장 흔히 마주치는 400입니다. 쌓인 쿠키, 큰 JWT, 프록시가 붙인 헤더 더미가 서버 버퍼를 넘칩니다. nginx는 large_client_header_buffers 기본값(줄당 8KB)을 초과하면 이를 400 Request Header Or Cookie Too Large로 보고합니다.
2. 잘못된 요청 구문·프레이밍 - 버그 있는 클라이언트, 깨진 프록시, 손으로 만든 요청이 URL에 불법 문자, 잘못된 Content-Length, 잘못된 HTTP 프레이밍을 보냅니다. 서버가 파싱하지 못해 거부합니다.
3. Host·라우팅 불일치 - 어떤 server block과도 맞지 않는 Host 헤더, TLS 뒤의 SNI/Host 불일치, 또는 오리진이 기만적 라우팅으로 취급하는 형태로 요청을 재작성하는 프록시.

Diagnose with DechoNet

• HTTP Check로 최종 코드가 400인지 확인하고, 응답 본문이 헤더·쿠키 초과를 가리키는지 점검합니다.
• DNS Lookup으로 요청이 의도한 호스트에 닿고 있는지 확인해, 엉뚱한 server block으로 가는 Host/라우팅 불일치를 배제합니다.

Resolution Checklist

• 해당 사이트의 쿠키를 지우고 다시 시도합니다 — “Header Or Cookie Too Large” 유형은 이걸로 바로 해결됩니다.
• 서버를 직접 운영한다면 large_client_header_buffers(nginx) 또는 동등한 헤더 한도를 올리고, 무엇이 헤더를 부풀리는지 찾습니다.
• 깨끗한 클라이언트(시크릿 창, 새 curl)로 재현해 클라이언트 문제와 서버 문제를 분리합니다.
• 요청 바이트를 직접 들여다보며 불법 문자, 잘못된 Content-Length, 잘못된 프레이밍을 확인합니다 — 흔히 경로 중간의 프록시가 만듭니다.
• Host 헤더가 설정된 가상 호스트와 일치하는지, upstream에서 재작성되지 않는지 확인합니다.
• HTTP Check를 다시 실행해 400이 사라졌는지 확인합니다.

When to Escalate

• 400이 엣지에서 발생하고 헤더 한도를 직접 못 바꾸면, 리버스 프록시나 CDN 운영 주체에게 넘깁니다.
• 잘못된 요청이 직접 제어할 수 없는 서드파티 클라이언트나 SDK에서 온다면, 캡처한 요청 바이트를 해당 메인테이너에게 전달합니다.