HTTP 400 Bad Request

HTTP 400의 의미

HTTP 400 Bad Request는 서버가 요청을 읽었지만 실제 작업을 수행하기 전에 유효하지 않다고 판단해 거부했다는 의미입니다. 잘못된 문법, 유효하지 않은 매개변수, 손상된 쿠키나 헤더 등 서버가 처리를 거부하는 모든 경우를 포괄하는 클라이언트 오류입니다.

401이나 403과 달리 400은 권한에 대해서는 아무것도 말해주지 않습니다 — 요청 자체가 도착 시점부터 문제였다는 뜻입니다. API는 흔히 어떤 필드가 검증에 실패했는지 정확히 설명하는 JSON 본문을 함께 반환합니다.

400 오류의 일반적인 원인

• 요청 본문의 JSON이나 XML 형식이 잘못된 경우(불필요한 쉼표, 잘못된 따옴표, 잘린 페이로드 등).
• 쿼리 매개변수가 누락되었거나 유효하지 않거나, 값이 서버 측 검증을 통과하지 못한 경우.
• 손상되었거나 과도하게 큰 쿠키 — 대형 사이트에서 특정 사용자에게만 지속적으로 400이 발생하는 전형적인 원인입니다.
• 잘못된 Content-Type 헤더로 인해 서버가 본문을 엉뚱한 형식으로 파싱하는 경우.
• URL 인코딩 실수: 쿼리 문자열에 이스케이프되지 않은 공백, 따옴표, 비ASCII 문자가 포함된 경우.

사용자로서 해결하는 방법

• 페이지를 새로고침하고, 그래도 400이 계속되면 해당 사이트의 쿠키를 삭제하세요 — 손상된 쿠키가 가장 흔한 원인입니다.
• URL에 오타나 복사·붙여넣기 과정에서 손상된 문자가 없는지 확인하세요.
• 시크릿 창을 사용해 확장 프로그램이 요청을 변형하고 있는 것은 아닌지 확인해 보세요.

개발자로서 해결하는 방법

• 요청을 보내기 전에 JSON 페이로드를 검증하고, 서버가 실제로 받은 요청 본문을 정확히 로그로 남기세요.
• 어떤 필드가 유효하지 않은지 명시하는 응답 본문을 반환하세요 — 아무 정보 없는 400은 모두의 디버깅 시간을 낭비하게 만듭니다.
• 헤더와 쿠키 크기에 대한 서버 제한을 확인하세요(nginx의 large_client_header_buffers 등).
• API에서 둘을 구분한다면, 형식은 올바르지만 의미상 유효하지 않은 입력에는 422를 사용하세요.

응답 예시

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error":"validation_failed","field":"email","message":"not a valid address"}

자주 묻는 질문