HTTP 400 Bad Request — 잘못된 요청 에러 원인·해결·예방

HTTP 400 Bad Request — 잘못된 요청 에러 원인·해결·예방

웹사이트나 API에서 "400 Bad Request" 또는 "잘못된 요청"을 만나면, 이번엔 서버가 고장 난 것도 길이 없는 것도 아니다. 클라이언트가 보낸 요청 자체에 문제가 있어 서버가 이해하거나 처리할 수 없다는 뜻이다. 편지로 치면 주소가 깨졌거나 봉투 형식이 엉망이라 우체국이 받아주지 못한 상황에 가깝다.

 

400은 4xx 클라이언트 오류의 대표격이다. 일반 사용자에게는 손상된 쿠키가 가장 흔한 원인이고, 개발자에게는 깨진 JSON·잘못된 헤더·검증 실패가 단골이다. 이 글은 400의 의미, 자주 나오는 원인, 재현과 API 요청 코드, 단계별 진단·해결, 그리고 비슷한 코드와의 차이까지 정리한다.

HTTP 400 Bad Request

 

이 글의 구성

 

🔎400 에러 메시지와 의미

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

💻재현 시나리오와 요청 코드

🛠해결 방법과 단계별 진단

⚖️400 vs 401·403·404·422 비교

💬자주 묻는 질문 5가지

---

🔎 400 에러 메시지와 의미

400은 HTTP 응답 상태 코드 가운데 4xx, 클라이언트 측 오류로 분류된다. 서버가 요청을 받았지만 그 문법·형식이 잘못돼(malformed) 이해하거나 처리할 수 없을 때 반환한다. 즉 문제의 출발점이 서버가 아니라 보낸 요청 쪽에 있다.

항목	내용
상태 코드	400
영문 메시지	Bad Request
한글 의미	요청 문법·형식이 잘못되어 처리 불가
분류	4xx 클라이언트 오류
책임 소재	요청을 보낸 클라이언트(주소·쿠키·본문·헤더)

400은 "범용 클라이언트 오류"에 가깝다. 요청의 무엇이 잘못됐는지는 다양하다. 깨진 URL, 손상된 쿠키, 잘못된 헤더, 형식에 안 맞는 JSON 본문까지 모두 400으로 묶일 수 있다. 그래서 진단은 "내가 보낸 요청의 어느 부분이 잘못됐나"를 좁혀 가는 일이다.

핵심 관찰 — 서버가 아니라 요청을 본다

400은 5xx와 달리 요청 쪽 문제다. 그래서 일반 사용자라면 브라우저 쿠키·캐시부터, 개발자라면 요청 본문·헤더·파라미터부터 의심한다. 서버 코드를 뜯어보기 전에 "보낸 것"을 먼저 점검하는 것이 빠르다.

---

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

원인 1 — 손상되거나 너무 큰 쿠키

일반 사용자에게 가장 흔하다. 오래된·손상된 쿠키나, 누적되어 너무 커진 쿠키를 서버가 거부하면 400이 난다. 특정 사이트에서만 400이 뜬다면 그 사이트 쿠키를 삭제하는 것으로 해결되는 경우가 많다.

원인 2 — 잘못된 URL·쿼리스트링

URL에 허용되지 않는 문자나 잘못 인코딩된 값, 깨진 쿼리스트링이 들어가면 서버가 요청을 해석하지 못해 400을 낸다. 주소를 복사·편집하다 특수문자가 깨진 경우가 대표적이다.

원인 3 — 잘못되거나 너무 큰 헤더

형식에 맞지 않는 헤더, 또는 누적 쿠키 등으로 헤더 전체 크기가 서버 한도를 넘으면 400이 난다. 서버에 따라 헤더 버퍼 한도를 올리거나, 클라이언트가 불필요한 헤더를 줄여야 한다.

원인 4 — 깨진 JSON 본문 (API)

API 요청에서 본문 JSON 문법이 깨지면 서버가 파싱하지 못해 400을 반환한다. 쉼표·따옴표·괄호 누락 같은 작은 실수가 흔하다. 참고로 본문 형식과 Content-Type이 맞지 않는 경우는 400이 아니라 415 Unsupported Media Type이 반환되는 것이 표준이다.

원인 5 — 필수 파라미터 누락·검증 실패

필수 값이 빠졌거나 타입이 맞지 않으면 애플리케이션이 요청을 거부하며 400을 낸다. 다만 "형식은 맞지만 값이 규칙에 안 맞는" 검증 실패는 422로 구분해 쓰는 API도 많다(뒤에서 비교).

---

💻 재현 시나리오와 요청 코드

먼저 400 응답의 모습이다. 본문에는 보통 어떤 점이 잘못됐는지 짧은 안내가 담긴다.

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

API에서 가장 흔한 재현은 깨진 JSON 본문이다. 쉼표 하나만 어긋나도 파싱이 실패해 400이 난다.

# ✗ 깨진 JSON (끝에 불필요한 쉼표) → 400
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{{ "name": "kim", }}'

# ✓ 올바른 JSON
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{{ "name": "kim" }}'

사용자 환경에서는 손상된 쿠키가 단골 원인이다. 헤더·쿠키 누적으로 크기가 커지면 서버에서 버퍼 한도를 올려 대응하기도 한다.

# 사용자 측: 해당 사이트 쿠키·캐시 삭제 후 재접속 (가장 흔한 해결)

# 서버 측(Nginx): 헤더 버퍼 한도 상향
large_client_header_buffers 4 16k;

---

🛠 해결 방법과 단계별 진단

400은 "누가 무엇을 잘못 보냈나"를 좁힌다. 사용자라면 쿠키·주소를, 개발자라면 본문·헤더·검증을 본다.

입장	해결 방법
방문자	해당 사이트 쿠키·캐시 삭제, 주소 재입력, 시크릿 모드로 확인
URL·인코딩	특수문자·인코딩 점검, 쿼리스트링 형식 확인
API 본문	JSON 문법 검증, Content-Type 일치 확인
헤더	헤더 형식·크기 점검, 서버 버퍼 한도 조정
검증	필수 파라미터·타입 확인, 서버 로그에서 거부 사유 확인

단계별 진단 절차

 

01일반 사용자라면 해당 사이트 쿠키·캐시부터 삭제하고 다시 접속한다.

02시크릿 모드·다른 브라우저에서 되는지 확인한다. 거기서 되면 쿠키·확장프로그램 문제다.

03API라면 요청 본문 JSON과 Content-Type을 검증한다. JSON 검사 도구로 문법을 확인한다.

04필수 파라미터·타입·헤더를 점검하고, 서버 로그에서 어느 부분을 거부했는지 확인한다.

05헤더가 너무 크면 클라이언트에서 줄이거나 서버 버퍼 한도를 조정한다.

---

⚖️ 400 vs 401·403·404·422 비교

400은 비슷한 4xx와 섞이기 쉽다. 무엇이 잘못됐는지 기준으로 구분하면 명확해진다.

코드	의미	무엇이 문제인가
400	잘못된 요청	요청 문법·형식 자체가 깨짐
401	인증 필요	누구인지 인증 안 됨
403	접근 금지	인증돼도 권한 없음
404	자원 없음	경로의 자원이 존재하지 않음
422	처리 불가 엔티티	형식은 맞지만 값이 규칙 위반(검증 실패)

특히 400과 422를 헷갈리기 쉽다. 400은 "문법 자체가 깨져 서버가 해석조차 못 하는" 경우이고, 422 Unprocessable Entity는 "문법은 멀쩡한데 값이 비즈니스 규칙에 맞지 않는(예: 이메일 형식 오류, 중복 값)" 경우다. 많은 REST API가 파싱 실패는 400, 검증 실패는 422로 나눠 쓴다.

“

400은 서버를 의심하기 전에 내가 보낸 요청을 의심하라는 신호다. 답이 잘못된 게 아니라 질문이 잘못된 것이다.

 

— 파싱 실패는 400, 검증 실패는 422

---

💬 자주 묻는 질문 5가지

Q1400은 제 인터넷 문제인가요?

인터넷 연결 문제는 아닙니다. 서버까지는 잘 도달했고, 다만 보낸 요청의 형식이 잘못된 것입니다. 일반 사용자라면 해당 사이트의 쿠키·캐시를 삭제하면 풀리는 경우가 많습니다.

Q2특정 사이트에서만 400이 떠요.

그 사이트의 손상된 쿠키가 원인일 가능성이 큽니다. 브라우저 설정에서 해당 사이트 쿠키만 삭제하거나, 시크릿 모드로 접속해 보세요. 시크릿에서 정상이면 쿠키 문제로 확정할 수 있습니다.

Q3API 호출에서 400이 나요.

요청 본문 JSON의 문법(쉼표·따옴표·괄호)과 Content-Type 헤더가 본문 형식과 일치하는지 확인하세요. 본문이 JSON이면 Content-Type도 application/json이어야 합니다. 필수 파라미터 누락도 흔한 원인입니다.

Q4400과 404는 뭐가 다른가요?

404는 요청은 멀쩡한데 그 경로의 자원이 없는 경우이고, 400은 요청 형식 자체가 잘못돼 서버가 해석조차 못 하는 경우입니다. 404는 "그런 곳 없음", 400은 "요청이 이상함"입니다.

Q5400과 422는 어떻게 구분하나요?

400은 문법 자체가 깨져 파싱이 안 되는 경우, 422는 문법은 맞지만 값이 규칙에 안 맞는(검증 실패) 경우입니다. 깨진 JSON은 400, 형식은 맞지만 이메일이 잘못된 값이면 422가 적절합니다. 다만 일부 API는 둘 다 400으로 처리하기도 합니다.

---

📌 결론

400 Bad Request는 "내가 보낸 요청이 잘못됐다"는 신호다. 404가 경로, 500이 서버 처리의 문제였다면, 400은 요청 형식의 문제다. 그래서 시선은 서버가 아니라 요청을 향해야 한다.

실무 원칙은 다음과 같다.

 

🍪 일반 사용자라면 쿠키·캐시부터 의심한다. 특정 사이트 400은 손상된 쿠키 삭제로 풀리는 경우가 많다.

💻 개발자라면 요청 본문·헤더·파라미터를 검증한다. JSON 문법과 Content-Type 일치가 첫 점검 대상이다.

⚖️ 400과 422를 구분한다. 파싱 실패는 400, 검증 실패는 422로 나누면 에러가 명확해진다.

400 트러블슈팅 체크리스트

 

01해당 사이트 쿠키·캐시 삭제 후 재접속(사용자 측 1순위).

02시크릿 모드·다른 브라우저로 쿠키·확장프로그램 문제 격리.

03URL 특수문자·인코딩, 쿼리스트링 형식 점검.

04API는 JSON 문법·Content-Type·필수 파라미터 검증.

05헤더 형식·크기 점검, 필요 시 서버 버퍼 한도 조정.

06서버 로그에서 거부된 정확한 사유·필드 확인.

07파싱 실패(400)와 검증 실패(422)를 구분해 명확한 메시지 제공.

---

본 글은 HTTP 400 Bad Request 에러의 일반적 원인과 해결 방법을 정리한 자료다. 서버·API 설정 변경은 운영 환경에 적용하기 전 테스트 환경에서 충분히 검증한다.

 

#400에러 #BadRequest #HTTP400 #HTTP에러 #HTTP상태코드 #잘못된요청 #쿠키삭제 #malformed #JSON #ContentType #API에러 #400과422차이 #웹개발 #서버에러 #트러블슈팅