한국어
모든 HTTP 상태 코드를 검색하고 쉽게 설명합니다.
마지막 업데이트
요청의 초기 부분이 수신됨; 클라이언트는 본문 전송을 계속해야 합니다.
서버가 프로토콜 전환에 동의 (예: HTTP/1.1 → WebSocket).
WebDAV — 요청이 수락되었지만 아직 완료되지 않음.
Link 헤더와 함께 사용해 최종 응답 전에 클라이언트가 리소스를 미리 로드합니다.
요청 성공. 정확한 의미는 메서드에 따라 다릅니다.
요청 성공. 새 리소스가 생성됨.
요청이 처리를 위해 수락되었지만 아직 완료되지 않음 (비동기 작업).
반환된 메타데이터는 원본 서버가 아닌 변환 프록시에서 옴.
요청 성공. 반환할 본문이 없음.
요청을 보낸 문서 뷰를 재설정하도록 클라이언트에 지시 (예: 폼 비우기).
Range 요청에 대한 응답으로 사용 — 본문에는 요청한 바이트 범위만 포함됨.
리소스에 여러 표현이 있음; 클라이언트가 하나를 선택해야 합니다.
리소스에 새 영구 URL이 있음. 검색 엔진은 인덱스를 업데이트합니다.
리소스가 임시로 다른 URL에 있음. 메서드를 유지해야 하면 307 사용.
POST 후, GET으로 결과를 가져오도록 클라이언트를 리다이렉트 (Post/Redirect/Get).
캐시된 사본이 여전히 유효함 — 조건부 GET (ETag / If-Modified-Since)에 대한 응답으로 전송.
302와 동일하지만 리다이렉트를 따를 때 요청 메서드를 변경하면 안 됨.
301과 동일하지만 리다이렉트를 따를 때 요청 메서드를 변경하면 안 됨.
클라이언트 오류 (잘못된 구문, 유효하지 않은 프레이밍)로 서버가 요청을 처리할 수 없거나 거부함.
인증이 필요하지만 실패했거나 제공되지 않음. (이름과 달리 인가가 아닌 인증에 관한 것입니다.)
향후 사용을 위해 예약됨. 일부 API는 사용자가 유료 할당량에 도달했음을 나타낼 때 사용.
서버가 요청을 이해했지만 인가를 거부함. 재인증해도 해결되지 않습니다.
서버가 요청한 리소스를 찾을 수 없습니다.
서버가 요청 메서드를 알지만 대상 리소스가 지원하지 않음.
서버가 클라이언트의 Accept 헤더와 일치하는 응답을 생성할 수 없음.
401과 비슷하지만 프록시 인증이 필요함.
서버가 요청을 기다리다 시간 초과됨.
요청이 대상 리소스의 현재 상태와 충돌함 (예: 버전 충돌).
리소스가 영구적으로 삭제되었으며 전달 주소가 없음.
서버가 Content-Length 헤더를 요구함.
요청 헤더의 사전 조건 (예: If-Match)이 서버에서 충족되지 않음.
요청 본문이 서버가 처리할 수 있는 크기를 초과함.
URI가 서버가 해석할 수 있는 길이를 초과함.
요청 본문이 서버나 리소스가 지원하지 않는 미디어 유형을 사용함.
Range 헤더가 파일 범위 밖의 부분을 요청함.
RFC 2324의 만우절 농담. 커피 내리기를 거부하는 서버가 반환합니다.
응답을 생성할 수 없는 서버로 요청이 전송됨 (예: 잘못된 HTTP/2 연결).
요청은 형식이 올바르지만 의미적 오류가 있음 (API가 유효성 검사 실패에 자주 사용).
WebDAV — 접근하려는 리소스가 잠겨 있음.
서버가 재전송될 수 있는 요청을 처리하지 않으려 함.
클라이언트가 요청을 완료하려면 다른 프로토콜 (예: TLS)로 업그레이드해야 함.
서버가 요청을 조건부로 요구함 (업데이트 손실 문제 방지에 도움).
클라이언트가 주어진 시간 내에 너무 많은 요청을 보냄 (속도 제한).
헤더 필드 — 또는 전체 헤더 — 가 너무 커서 서버가 요청을 거부함.
법적 사유로 리소스를 사용할 수 없음 (화씨 451에서 이름을 따옴).
서버에서 예상치 못한 조건이 발생함. 일반적인 5xx 오류.
서버가 요청 메서드를 인식하지 못함.
게이트웨이로 동작하는 서버가 상위 서버에서 잘못된 응답을 받음.
서버가 요청을 처리할 준비가 되지 않음 — 보통 과부하 또는 유지 보수 중.
게이트웨이로 동작하는 서버가 상위 서버에서 제때 응답을 받지 못함.
서버가 요청에 사용된 HTTP 버전을 지원하지 않음.
WebDAV — 서버가 요청 완료에 필요한 표현을 저장할 수 없음.
WebDAV — 서버가 처리 중 무한 루프를 감지함.
네트워크 접근을 위해 클라이언트가 인증해야 함 (캡티브 포털).
HTTP 상태 코드는 서버가 응답 맨 앞에 붙여 보내는 세 자리 숫자로, 요청이 어떻게 처리됐는지를 한마디로 요약해 줍니다. 브라우저, 클라이언트, 프록시, CDN 등이 캐시할지, 리다이렉트할지, 재시도할지, 아니면 사용자에게 에러를 보여줄지를 이 숫자를 보고 결정합니다.
모든 상태 코드는 첫 번째 숫자에 따라 다섯 가지 클래스로 나뉩니다. 1xx은 정보 전달, 2xx은 성공, 3xx은 리다이렉션, 4xx은 클라이언트 에러, 5xx은 서버 에러죠. 클래스만 알아도 구체적인 코드를 찾아보기 전에 대략적인 의미는 짐작할 수 있습니다.
실제 서비스에서 자주 쓰는 코드는 200, 201, 204, 301, 302, 304, 400, 401, 403, 404, 409, 422, 429, 500, 502, 503 정도로 많지 않습니다. 각 코드가 *진짜로* 무엇을 의미하는지, 그리고 401 Unauthorized와 403 Forbidden, 301 Moved Permanently와 302 Found처럼 헷갈리는 짝의 차이를 정확히 아는 것 — 이게 백엔드/API 개발자의 내공입니다.
4xx은 클라이언트가 뭔가 잘못한 경우(잘못된 입력, 인증 누락, 존재하지 않는 리소스). 5xx은 클라이언트가 무엇을 했든 서버 쪽에서 실패한 경우.숫자(404, 429)나 키워드(auth, redirect, rate limit)를 입력하면 일치하는 코드들이 실시간으로 필터링됩니다.
특정 코드를 찾는 게 아니라 둘러보고 싶다면 클래스 칩(1xx, 2xx, 3xx, 4xx, 5xx)으로 목록을 좁히세요.
각 항목에는 어떤 상황에서 이 코드가 보내지는지, 클라이언트는 보통 어떻게 동작하는지, 가장 흔한 원인은 무엇인지가 정리돼 있습니다.
헷갈리는 짝(401 vs 403, 301 vs 302)은 see-also 링크로 이어져 있어서, API에 어떤 코드를 쓸지 고를 때 비교하기 편합니다.
한눈에 보는 다섯 가지 HTTP 상태 코드 클래스와 그 의미. RFC 9110에 정의되어 있고, IANA HTTP Status Code Registry에 등록되어 있습니다.
| 클래스 | 의미 | 주요 코드 |
|---|---|---|
| 1xx 정보(Informational) | 요청 수신, 처리 중 | 100, 101, 103 |
| 2xx 성공(Success) | 요청이 정상적으로 처리됨 | 200, 201, 204, 206 |
| 3xx 리다이렉션(Redirection) | 다른 곳을 참고하라 | 301, 302, 304, 307, 308 |
| 4xx 클라이언트 에러 | 요청 자체에 문제가 있음 | 400, 401, 403, 404, 409, 422, 429 |
| 5xx 서버 에러 | 정상적인 요청인데 서버가 처리에 실패 | 500, 502, 503, 504 |
"잘 처리됐습니다"라는 가장 일반적인 성공 응답. 본문이 함께 옵니다.
요청 결과로 새 리소스가 생성되었다는 뜻. 보통 POST 이후에 사용합니다.
성공했지만 본문이 없음. 반환할 데이터가 따로 없는 DELETE나 PUT 응답에 자주 쓰입니다.
셋 다 성공 코드지만, 응답에 무엇이 실리느냐가 다릅니다. 201에는 새로 생성된 리소스를 가리키는 Location 헤더를 함께 넣어야 하고, 204는 정의상 본문이 비어 있어야 합니다.
영구 리다이렉트. 브라우저와 검색엔진이 이 사실을 기억하므로, 기존 URL은 사실상 죽은 셈이 됩니다.
임시 리다이렉트. 브라우저는 매 요청마다 원래 URL을 다시 확인하고, 북마크도 기존 URL을 그대로 유지합니다.
리소스가 실제로 이전된 경우(브랜드 변경, URL 구조 개편 등)에는 301을 씁니다. A/B 테스트, 로그인 리다이렉트, 점검 페이지처럼 일시적인 경우에는 302를 쓰세요.
다른 자격증명(credential)을 보내면 해결될 가능성이 있는 상황이라면 401을 반환하세요. 어떤 자격증명으로도 접근이 안 되는 상황(이 사용자에게는 그냥 막힌 리소스)이라면 403이 맞습니다.
일반적인 서버 에러 — 코드에서 처리되지 않은 예외가 발생한 경우.
Bad Gateway — 앞단의 프록시(CDN, 로드 밸런서)가 업스트림 서버에 도달하지 못함.
Service Unavailable — 서버는 살아 있지만 과부하 상태이거나 점검 중.
Gateway Timeout — 프록시가 업스트림에 닿긴 했지만 시간 안에 응답을 받지 못함.
모두 서버 에러지만, 디버깅 입장에서는 전혀 다른 이야기입니다. 500은 애플리케이션 문제, 502와 504는 네트워크 경로 문제, 503은 용량(capacity) 문제를 가리킵니다.
{"error": "..."}를 담으면서 200 OK로 응답하기. 상태 코드는 계약의 일부입니다. 클라이언트가 분기할 수 있도록 상황에 맞는 코드(400, 404, 500)를 쓰세요.401을 쓰는 경우. 401은 인증이 안 된 상황을 위한 코드이고, 권한 거부는 403입니다.201과 Location 헤더 대신 200을 쓰는 것.404 Not Found는 서버가 요청은 이해했지만 해당 URL에 리소스가 존재하지 않는다는 뜻입니다. 보통 경로가 잘못됐거나, 리소스가 삭제됐거나, URL을 잘못 입력한 경우입니다.401 Unauthorized는 아직 인증이 안 된 상태입니다 — 서버가 당신이 누구인지 모릅니다. 403 Forbidden은 인증은 됐지만 해당 리소스에 접근할 권한이 없다는 뜻이고요. 다른 자격증명을 보내면 401은 해결될 수 있지만, 403은 해결되지 않습니다.301 Moved Permanently는 영구 리다이렉트입니다 — 브라우저와 검색엔진이 정보를 갱신합니다. 302 Found는 임시 리다이렉트라서 클라이언트는 계속 원래 URL로 요청합니다. 영구 이전에는 301, 일시적인 우회에는 302를 쓰세요.500 Internal Server Error는 일반적인 서버 측 에러로, 보통 처리되지 않은 예외가 위로 전파됐을 때 발생합니다. 클라이언트는 잘못한 게 없고, 정상적인 요청을 서버가 처리하지 못한 것입니다.200 OK를 보내거나, 모든 에러를 500으로 통일하면 API가 쓰기 어려워집니다. 가장 잘 맞는 구체적인 코드를 고르세요. 클라이언트, 프록시, 모니터링, 재시도 로직이 모두 상태 코드를 보고 분기합니다.429 Too Many Requests는 클라이언트가 요청 제한(rate limit)에 걸렸을 때 보내는 응답입니다. 응답에는 언제 다시 시도해도 되는지를 알려주는 Retry-After 헤더를 함께 넣어주는 것이 좋습니다.