HTTP 상태 코드 조회
HTTP 상태 코드 의미를 빠르게 조회, 모든 표준 상태 코드 설명 포함
1xx 정보(4)
계속. 클라이언트는 요청의 나머지 부분을 계속 전송해야 합니다.
프로토콜 전환. 서버가 클라이언트 요청을 이해하고 Upgrade 메시지 헤더를 통해 프로토콜 전환을 알립니다.
처리 중. 서버가 요청을 수신했으며 처리 중이지만 완료하지는 않았습니다.
사전 힌트. 최종 응답 전에 일부 헤더 정보를 반환하여 클라이언트가 리소스를 미리 로드할 수 있도록 합니다.
2xx 성공(10)
성공. 요청이 성공적으로 처리되었으며 응답에 요청한 데이터가 포함되어 있습니다.
생성됨. 요청이 성공하고 새로운 리소스가 생성되었습니다. 보통 POST 요청에 사용됩니다.
접수됨. 요청이 접수되어 처리되었지만 처리가 완료되지 않았습니다. 비동기 처리에 자주 사용됩니다.
비인가 정보. 서버가 요청을 성공적으로 처리했지만 반환된 정보는 제3자에서 온 것일 수 있습니다.
내용 없음. 요청은 성공했지만 응답에 메시지 본문이 포함되어 있지 않습니다. DELETE 요청에 자주 사용됩니다.
내용 재설정. 요청이 성공했으며 클라이언트는 문서 뷰를 재설정해야 합니다.
부분 내용. 서버가 부분 GET 요청을 성공적으로 처리했으며 이어받기에 사용됩니다.
다중 상태. 여러 상태 코드의 응답 (WebDAV).
이미 보고됨. DAV 바인딩 멤버가 이전의 다중 상태 응답에서 열거되었습니다 (WebDAV).
IM 사용됨. 서버가 GET 요청을 완료했으며 응답에 인스턴스 조작이 사용되었습니다.
3xx 리다이렉트(8)
다양한 선택. 요청한 리소스에 여러 표현 형식이 있어 클라이언트가 선택해야 합니다.
영구 이동. 요청한 리소스가 새로운 위치로 영구 이동되었으며 새로운 URL을 사용해야 합니다.
임시 이동. 요청한 리소스가 현재 임시로 다른 URL에서 응답합니다.
다른 위치 조회. GET 메서드를 사용하여 다른 URL에서 리소스에 접근해야 합니다.
수정되지 않음. 리소스가 수정되지 않았으며 클라이언트는 캐시된 버전을 사용할 수 있습니다.
프록시 사용 (폐기됨). 지정된 프록시를 통해 리소스에 접근해야 합니다.
임시 리다이렉트. 요청은 동일한 메서드와 메시지 본문으로 다른 URL에 리다이렉트해야 합니다.
영구 리다이렉트. 요청은 동일한 메서드로 다른 URL에 영구 리다이렉트해야 합니다.
4xx 클라이언트 오류(29)
잘못된 요청. 서버가 요청의 형식을 이해할 수 없으며 클라이언트는 요청을 수정한 후 다시 시도해야 합니다.
미인증. 요청에 사용자 인증이 필요합니다.
결제 필요. 향후 사용을 위해 예약되며 유료 콘텐츠에 자주 사용됩니다.
접근 금지. 서버가 요청을 이해하지만 실행을 거부합니다.
찾을 수 없음. 요청한 리소스가 존재하지 않으며 가장 흔한 상태 코드입니다.
메서드 허용되지 않음. 요청 메서드가 지원되지 않으며 응답에 Allow 헤더가 포함됩니다.
수락 불가. 서버가 클라이언트가 요청한 콘텐츠 유형에 따라 응답을 반환할 수 없습니다.
프록시 인증 필요. 클라이언트는 먼저 프록시 서버에 인증을 해야 합니다.
요청 시간 초과. 서버가 요청을 기다리다 시간 초과되었습니다.
충돌. 요청이 서버의 현재 상태와 충돌하며 PUT 요청에 자주 사용됩니다.
삭제됨. 요청한 리소스가 영구적으로 삭제되어 복구되지 않습니다.
길이 필요. 요청에 Content-Length 헤더가 포함되어야 합니다.
전제 조건 실패. 요청 헤더에서 지정한 조건이 만족되지 않습니다.
요청 엔티티 과대. 요청 본문이 서버가 처리할 수 있는 크기를 초과했습니다.
URI 과장. 요청한 URL이 너무 길어 서버가 처리할 수 없습니다.
지원되지 않는 미디어 유형. 요청 본문의 형식을 서버가 지원하지 않습니다.
요청 범위 불만족. 요청한 범위가 유효하지 않습니다.
기대 실패. 서버가 요청 헤더 Expect 필드의 기대를 만족할 수 없습니다.
나는 찻주전자입니다. RFC 2324의 이스터 에그 코드로 서버가 커피를 끓이는 것을 거부한다는 것을 표시합니다.
잘못된 요청. 요청이 응답을 생성할 수 없는 서버에 전송되었습니다.
처리할 수 없는 엔티티. 요청의 형식은 올바르지만 의미 오류로 처리할 수 없습니다.
잠김. 요청한 리소스가 잠겨 있습니다 (WebDAV).
의존성 실패. 요청이 이전 요청 실패로 인해 실패했습니다 (WebDAV).
너무 이름. 서버가 재생될 가능성이 있는 요청을 처리할 의향이 없습니다.
업그레이드 필요. 클라이언트는 TLS 프로토콜로 전환해야 합니다.
전제 조건 필요. 요청에 조건 헤더 (예: If-Match)가 필요합니다.
요청 과다. 사용자가 요청을 너무 자주 전송하고 있으며 속도를 제한해야 합니다.
요청 헤더 필드 과대. 요청 헤더가 너무 커서 서버가 처리할 수 없습니다.
법적 이유로 사용 불가. 해당 리소스는 법적 이유로 제공할 수 없습니다.
5xx 서버 오류(11)
서버 내부 오류. 서버가 예상치 못한 상황에 직면하여 요청을 완료할 수 없습니다.
미구현. 서버가 요청에 필요한 기능을 지원하지 않습니다.
잘못된 게이트웨이. 서버가 게이트웨이 또는 프록시로 작동 중 상위에서 무효 응답을 수신했습니다.
서비스 이용 불가. 서버가 일시적으로 요청을 처리할 수 없으며 과부하 또는 유지보수 중일 수 있습니다.
게이트웨이 시간 초과. 서버가 게이트웨이 또는 프록시로 작동 중 상위 응답을 기다리다 시간 초과되었습니다.
HTTP 버전 미지원. 서버가 요청에서 사용한 HTTP 버전을 지원하지 않습니다.
변형도 협상 필요. 서버 구성 오류로 콘텐츠 협상이 루프에 빠졌습니다.
저장 공간 부족. 서버가 요청을 완료하기 위해 필요한 리소스를 저장할 수 없습니다 (WebDAV).
루프 감지됨. 서버가 요청을 처리하다 무한 루프를 감지했습니다 (WebDAV).
미확장. 처리를 위해 요청을 추가 확장해야 합니다.
네트워크 인증 필요. 계속하려면 네트워크 인증이 필요합니다 (예: 핫스팟 로그인).
HTTP 상태 코드란?
HTTP 상태 코드는 서버가 요청에 응답할 때 반환하는 세 자리 숫자 코드로 요청의 처리 결과를 표시합니다. 상태 코드는 다섯 개 카테고리로 나뉩니다: 1xx (정보 응답), 2xx (성공), 3xx (리다이렉트), 4xx (클라이언트 오류), 5xx (서버 오류). 이해하는 것은 웹 개발과 디버깅에 필수적입니다. 상태 코드는 문제의 방향을 알려 주지만 원인을 모두 설명하지는 않습니다. 실제 디버깅에서는 요청 헤더, 응답 본문, 서버 로그, 캐시 상태를 함께 확인해야 합니다.
사용 방법
빠른 참조
- 상태 코드 카드를 클릭하면 해당 코드가 복사됩니다
- 검색창으로 특정 코드를 빠르게 찾을 수 있습니다
- 카테고리 태그를 클릭하여 상태 유형별로 필터링합니다
- 코드에 마우스를 올리면 상세 설명을 볼 수 있습니다
디버깅 참고사항
- 먼저 상태 코드 계열을 파악하세요: 2xx 성공, 3xx 리다이렉트, 4xx 클라이언트 문제, 5xx 서버 문제.
- API 디버깅 시에는 상태 코드와 응답 본문, 헤더, 요청 메서드, 서버 로그를 함께 확인하세요. 코드만으로는 전체 문제를 설명하기 어렵습니다.
활용 사례
기술 원리
HTTP 상태 코드는 HTTP 의미 체계 사양이 정의하는 응답 시작 줄에 반환되는 3자리 정수입니다. 현재 규범적 참조는 RFC 9110(HTTP Semantics, 2022년 6월)이며, 이전 RFC 7231 시리즈를 대체합니다. RFC 9111(Caching), RFC 9112(HTTP/1.1), RFC 9113(HTTP/2), RFC 9114(HTTP/3)에 확장이 있습니다. 첫 번째 숫자는 응답 클래스를 정의하므로 인식되지 않는 코드도 예측 가능한 처리를 받습니다: 1xx 정보(중간, 최종 응답이 뒤따름), 2xx 성공, 3xx 리다이렉트(사용자 에이전트의 추가 동작 필요), 4xx 클라이언트 오류(요청 형식이 잘못되었거나 처리 불가), 5xx 서버 오류. 캐시와 중간 서버는 알 수 없는 코드를 일반 클래스 코드 x00(예: 알 수 없는 4xx는 400처럼 처리)으로 처리해야 하므로, 독자적 또는 확장 코드에서도 상태 계열이 의미를 가집니다. 리다이렉트 코드는 역사적으로 의도와 다르게 해석된 메서드 보존 시맨틱스를 가집니다. RFC 9110 §15.4는 이를 명확히 구분합니다: 301 Moved Permanently와 302 Found는 POST를 GET으로 재작성할 수 있습니다(1990년대 후반 모든 브라우저가 정착한 사실상의 동작으로, RFC 7231에서 공식화됨). 307 Temporary Redirect와 308 Permanent Redirect는 사용자 에이전트가 동일한 메서드와 본문을 반복하도록 요구합니다. SEO 도구는 일반적으로 301과 308에 PageRank 등급 가중치를 전달하고, 302/307은 원래 URL의 신호를 보존하는 것으로 처리합니다. 조건부 코드 304 Not Modified와 412 Precondition Failed는 요청의 If-None-Match/If-Modified-Since/ETag/Last-Modified 헤더에 의존하며, 206 Partial Content는 Range 헤더에 Content-Range 헤더와 복수 범위 요청 시 multipart/byteranges 본문으로 응답합니다. 4xx와 5xx 클래스는 헤더에 계약 상세를 담습니다. 401 Unauthorized는 수락된 스키마(Bearer, Basic, Digest, Negotiate)를 나열하는 WWW-Authenticate 챌린지를 포함해야 하며, 이것이 없으면 응답은 기술적으로 형식이 잘못된 것입니다. 405 Method Not Allowed는 지원되는 메서드를 나열하는 Allow 헤더를 포함해야 합니다. 429 Too Many Requests, 503 Service Unavailable, 그리고 301/307/308의 Retry-After는 RFC 9110 §10.2.3에 따라 초 단위(Retry-After: 120) 또는 HTTP-date(Retry-After: Wed, 21 Oct 2025 07:28:00 GMT)로 지연을 신호할 수 있습니다. RFC 9110은 305 Use Proxy와 306(예약/미사용)을 폐기하고, 418 I'm a teapot을 RFC 2324/RFC 7168의 문서화된 농담 코드로 유지하며, 1xx를 재구성하여 HTTP/1.1 계층에서 100 Continue와 101 Switching Protocols만 필수로 하고, 102 Processing과 103 Early Hints(RFC 8297)는 주로 CDN 엣지 로직을 통해 노출되는 선택적 확장으로 분류합니다.
- 규범적 참조: RFC 9110(HTTP Semantics, 2022년 6월)이 RFC 7230-7235를 대체; 확장은 RFC 9111(Caching), 9112(HTTP/1.1 와이어 포맷), 9113(HTTP/2), 9114(HTTP/3)에 존재
- 알 수 없는 코드는 클래스 코드(x00)로 폴백: 알 수 없는 4xx는 400처럼 캐시 및 렌더링, 알 수 없는 5xx는 500처럼 처리 - 이것이 첫 번째 숫자를 계약으로 만드는 것
- 메서드 보존: 301/302는 역사적으로 POST→GET 재작성 허용(1990년대 초 브라우저 분기 후 공식화); 307/308은 동일한 메서드와 본문 재전송 요구 - 영구 API 엔드포인트 이동에는 308 사용
- 401 Unauthorized는 WWW-Authenticate를, 405 Method Not Allowed는 Allow를 포함해야 함; 이 헤더가 없으면 사양 위반이며 올바른 HTTP 클라이언트가 깨짐
- Retry-After(RFC 9110 §10.2.3)가 429/503/301/307/308에 사용: 델타 초(Retry-After: 120) 또는 HTTP-date(Retry-After: Wed, 21 Oct 2025 07:28:00 GMT) 수락 - 클라이언트는 두 형태 모두 파싱해야 함
- 조건부 캐싱: 304 Not Modified는 If-None-Match/If-Modified-Since 일치에 본문 없이 응답; 206 Partial Content는 Range에 Content-Range와 부분 본문 또는 multipart/byteranges 문서로 응답
- RFC 9110은 305 Use Proxy와 306(예약)을 폐기하고, RFC 2324/RFC 7168의 418 I'm a teapot을 농담으로 보존하며, 102 Processing/103 Early Hints(RFC 8297)를 많은 프록시가 제거하는 선택적 1xx 확장으로 취급
예시
2xx 성공 - 200 OK 및 204 No Content
200 OK GET /api/users -> 응답 본문 반환
201 Created POST /api/posts -> Location 헤더에 새 리소스 위치 표시
204 No Content DELETE /api/posts/42 -> 성공, 빈 본문
206 Partial 비디오 스트리밍이나 재개 가능한 다운로드를 위한 Range 요청
RFC: RFC 7231 section 6.3에서 2xx 성공 상태 코드 정의3xx 리다이렉트 - 301 vs 302 vs 304
301 Moved Permanently -> SEO 친화적, 브라우저가 새 URL을 영구 캐싱
302 Found -> 임시 리다이렉트, 대상 URL 캐싱 금지
304 Not Modified -> 캐시된 사본이 여전히 유효 (ETag/Last-Modified 일치)
307 Temporary Redirect -> 302와 유사하지만 메서드 변경 금지 (POST는 POST 유지)
308 Permanent Redirect -> 301과 유사하지만 요청 메서드 보존
RFC: RFC 7231 section 6.4에서 3xx 리다이렉트 코드 정의
RFC: RFC 7232 section 4.1에서 304 Not Modified 의미 정의4xx 클라이언트 오류 - 인증 vs 권한
400 Bad Request 잘못된 JSON 형식, 필수 필드 누락
401 Unauthorized 토큰 누락 또는 무효 - 호출자가 인증 필요
403 Forbidden 인증되었지만 해당 리소스 접근 권한 없음
404 Not Found 리소스가 존재하지 않음 (또는 보안상 없는 척)
409 Conflict 중복 키, 낙관적 잠금 버전 불일치
429 Too Many Reqs 속도 제한 초과 - Retry-After 헤더 확인
RFC: RFC 7231 section 6.5에서 4xx 클라이언트 오류 코드 정의
RFC: RFC 6585 section 4에서 429 Too Many Requests 정의5xx 서버 오류 - 업스트림 디버깅
500 Internal Server Error 애플리케이션 코드의 처리되지 않은 예외 - 로그 확인
502 Bad Gateway Nginx/업스트림이 백엔드로부터 잘못된 응답을 받음
503 Service Unavailable 유지보수, 과부하, 또는 앱 부팅 중
504 Gateway Timeout 업스트림이 프록시 타임아웃 내 응답하지 않음
RFC: RFC 7231 section 6.6에서 5xx 서버 오류 코드 정의
빠른 분류: 5xx = 우리 잘못, 4xx = 호출자 잘못여러 코드를 보여주는 실제 curl 세션
$ curl -I https://example.com/old-page
HTTP/2 301
location: https://example.com/new-page
$ curl -I https://example.com/admin
HTTP/2 401
www-authenticate: Bearer realm="api"
$ curl -X POST https://example.com/api/posts -d '{}'
HTTP/2 422
content-type: application/json
참고: 422 Unprocessable Entity는 유효성 검증 오류에 사용되는 WebDAV 확장(RFC 4918)입니다.자주 묻는 질문
1xx, 2xx, 3xx, 4xx, 5xx 분류는 각각 무슨 뜻인가요?
1xx는 정보성 응답(실무에서는 드뭅니다). 2xx는 요청이 성공했다는 뜻. 3xx는 리다이렉트로 클라이언트가 다른 URL을 따라가야 함. 4xx는 클라이언트 측 문제(잘못된 요청, 인증 누락, 존재하지 않는 리소스 등). 5xx는 서버 측 문제(요청 자체는 정상이지만 서버가 처리하지 못함). 로그 한 줄을 볼 때는 항상 분류부터 먼저 확인하세요.
301과 302의 차이는 무엇인가요?
301 Moved Permanently는 리소스가 영구적으로 이동했음을 클라이언트와 검색엔진에 알립니다. 브라우저는 이 리다이렉트를 적극적으로 캐시하고 SEO 링크 가치도 새 URL로 넘어갑니다. 302 Found는 일시적인 리다이렉트로 장기 캐시되지 않습니다. 요청 메서드를 그대로 유지해야 한다면 영구 리다이렉트는 308, 일시 리다이렉트는 307을 사용하세요.
401과 403은 언제 각각 반환해야 하나요?
401 Unauthorized는 클라이언트가 인증을 하지 않았거나 보낸 자격 증명이 유효하지 않다는 뜻으로, 응답에 WWW-Authenticate 헤더를 포함해야 합니다. 403 Forbidden은 서버가 클라이언트가 누구인지 알면서도 이 리소스 제공을 거부한다는 뜻입니다. 로그인하면 401은 해결되지만 403은 해결되지 않습니다.
더 이상 존재하지 않는 리소스에는 404와 410 중 무엇을 써야 하나요?
404 Not Found는 '이 리소스를 찾을 수 없으며, 어딘가에 있을 수도 있고 나중에 다시 생길 수도 있다'는 의미입니다. 410 Gone은 '이 리소스가 여기 있었지만 의도적으로 제거됐으니 다시 찾지 말라'는 의미입니다. 검색엔진은 410 URL을 404보다 더 빠르게 인덱스에서 제외하므로, 다시 크롤링되지 않길 원하는 폐기된 페이지에는 410이 적절합니다.
API를 디버깅할 때 상태 코드를 어떻게 읽어야 하나요?
먼저 분류(4xx인지 5xx인지)로 어느 쪽 문제인지 가늠하고, 그다음 구체 코드, 마지막으로 응답 본문을 보세요. 실제 오류 메시지와 내부 오류 코드는 보통 본문에 담기며, HTTP 상태는 그저 큰 범주에 해당합니다. Retry-After, WWW-Authenticate, Location 같은 헤더도 상태와 함께 반드시 확인하세요.
2xx가 아닌 코드는 SEO에 해가 되나요?
어떤 것은 그렇고 어떤 것은 그렇지 않습니다. 5xx 응답이 오래 지속되면 신뢰할 수 없는 사이트로 인식되어 검색엔진이 결국 크롤링 빈도를 줄입니다. 301/308 리다이렉트는 링크 가치를 전달하지만 302/307은 그렇지 않습니다. 410은 인덱스에서 빠르게 제거되고 404는 더 오래 남습니다. 200을 돌려주면서 본문에 '찾을 수 없음'을 표시하는 소프트 404는 빈 페이지로 인덱스를 채우므로 진짜 404보다 더 나쁩니다.
418, 451 같은 특이한 코드는 어떤 용도인가요?
418 'I'm a teapot'은 RFC 2324의 만우절 농담으로 만들어진 코드라 실제 서비스에서는 절대 반환하면 안 됩니다. 451 Unavailable For Legal Reasons는 법적 요구로 인해 리소스가 차단됐음을 나타냅니다(브래드버리의 소설 화씨 451에서 따왔습니다). 429 Too Many Requests는 속도 제한을 의미하며 Retry-After 헤더와 함께 보내야 합니다. 503 Service Unavailable은 계획된 점검에 적합한 코드입니다.