HTTP 상태 코드 레퍼런스

1xx-5xx 모든 HTTP 상태 코드 검색 — 요약·RFC·사용 시점·흔한 함정 포함.

검색

결과: 61

100Continue
서버가 헤더를 받았으니 클라이언트는 본문을 보내면 됩니다.
RFC: RFC 9110 §15.2.1
101Switching Protocols
서버가 프로토콜 전환에 동의합니다(예: HTTP/2, WebSocket).
사용 시점: WebSocket 업그레이드 핸드셰이크.
RFC: RFC 9110 §15.2.2
102Processing
WebDAV: 요청은 받았지만 아직 응답이 없습니다.
RFC: RFC 2518
103Early Hints
최종 응답 전에 보내는 프리로드 힌트.
사용 시점: 느린 백엔드 응답이 오기 전에 핵심 리소스에 대한 Link: rel=preload를 먼저 보낼 때.
RFC: RFC 8297
200OK
본문이 있는 표준 성공 응답.
RFC: RFC 9110 §15.3.1
201Created
리소스가 생성되었습니다. 생성된 리소스를 가리키는 Location 헤더를 포함하세요.
사용 시점: 새 리소스를 만드는 POST. 본문은 선택 사항입니다.
RFC: RFC 9110 §15.3.2
202Accepted
비동기 처리를 위해 요청을 접수했으며 아직 결과는 없습니다.
사용 시점: 오래 걸리는 작업. 클라이언트가 폴링할 상태 URL을 돌려주세요.
RFC: RFC 9110 §15.3.3
203Non-Authoritative Information
프록시가 응답을 변형했습니다.
RFC: RFC 9110 §15.3.4
204No Content
성공했지만 보낼 본문이 없습니다.
사용 시점: DELETE 성공, 돌려줄 내용이 없는 PUT, 프리플라이트 성공.
함정: 메시지 본문을 포함하면 안 됩니다(MUST NOT). 본문을 넣으면 오류를 내는 라이브러리도 있습니다.
RFC: RFC 9110 §15.3.5
205Reset Content
성공. 클라이언트는 문서 화면을 초기화해야 합니다(폼 비우기).
RFC: RFC 9110 §15.3.6
206Partial Content
Range 요청을 받아들였으며 본문의 일부가 이어집니다.
사용 시점: 이어받기 가능한 다운로드, 동영상 탐색.
RFC: RFC 9110 §15.3.7
207Multi-Status
WebDAV: 여러 리소스의 결과를 한꺼번에 담은 응답.
RFC: RFC 4918
208Already Reported
WebDAV: 바인딩이 이 응답의 앞부분에서 이미 나열되었습니다.
RFC: RFC 5842
226IM Used
델타 인코딩 응답.
RFC: RFC 3229
300Multiple Choices
여러 리소스가 일치하니 클라이언트가 하나를 골라야 합니다.
RFC: RFC 9110 §15.4.1
301Moved Permanently
리소스에 새 영구 URL이 생겼습니다. 캐시에 계속 남습니다.
사용 시점: 도메인 이전, URL 구조 개편.
함정: 브라우저가 301을 적극적으로 캐시하므로 잘못 보낸 것을 바로잡기가 매우 어렵습니다. 먼저 302로 시험해 보세요.
RFC: RFC 9110 §15.4.2
302Found
임시 리디렉트(레거시 의미로, 메서드가 바뀔 수 있음).
함정: 역사적으로 POST를 GET으로 바꿔 왔습니다. 메서드 처리를 명시하려면 303이나 307을 쓰세요.
RFC: RFC 9110 §15.4.3
303See Other
항상 GET으로 바뀌는 리디렉트.
사용 시점: 폼 제출 후의 POST/Redirect/GET 패턴.
RFC: RFC 9110 §15.4.4
304Not Modified
조건부 요청: 캐시된 사본이 아직 유효합니다.
사용 시점: If-None-Match / If-Modified-Since에 대한 응답.
함정: 본문을 포함하면 안 됩니다(MUST NOT).
RFC: RFC 9110 §15.4.5
307Temporary Redirect
임시. 메서드와 본문을 그대로 유지해야 합니다.
RFC: RFC 9110 §15.4.8
308Permanent Redirect
영구. 메서드와 본문을 그대로 유지해야 합니다.
사용 시점: 영구 이전 후에도 POST가 유지되어야 할 때. API 엔드포인트에는 301보다 이쪽을 권합니다.
RFC: RFC 9110 §15.4.9
400Bad Request
서버가 해석할 수 없는 잘못된 형식의 요청(일반).
함정: 문법은 맞지만 의미가 틀린 요청에는 400 대신 422를 쓰세요.
RFC: RFC 9110 §15.5.1
401Unauthorized
인증이 필요하거나 실패했습니다. WWW-Authenticate를 포함해야 합니다.
함정: 역사적으로 이름이 잘못 붙었습니다. 실제 의미는 "인증되지 않음"입니다. "인증은 됐지만 허용되지 않음"에는 403을 쓰세요.
RFC: RFC 9110 §15.5.2
402Payment Required
향후 사용을 위해 예약됨. 결제 실패에 쓰는 API도 있습니다.
RFC: RFC 9110 §15.5.3
403Forbidden
인증은 되었지만 이 주체에게는 허용되지 않는 작업입니다.
사용 시점: 권한 부족, 지역 차단, 또는 "인증과 상관없이 할 수 없는 작업".
RFC: RFC 9110 §15.5.4
404Not Found
리소스가 존재하지 않습니다(또는 숨기고 있습니다).
사용 시점: 존재 여부를 드러내지 않으려고 403 대신 자주 쓰입니다.
RFC: RFC 9110 §15.5.5
405Method Not Allowed
리소스는 있지만 이 메서드를 지원하지 않습니다. Allow 헤더를 반드시 포함해야 합니다.
RFC: RFC 9110 §15.5.6
406Not Acceptable
Accept 헤더에 맞는 표현이 없습니다.
RFC: RFC 9110 §15.5.7
407Proxy Authentication Required
401과 같지만 프록시용입니다. Proxy-Authenticate를 포함해야 합니다.
RFC: RFC 9110 §15.5.8
408Request Timeout
서버가 요청이 끝나기를 기다리다 포기했습니다.
RFC: RFC 9110 §15.5.9
409Conflict
요청이 현재 상태와 충돌합니다(예: 편집 충돌, 중복).
사용 시점: 생성 시 고유 키 위반, 수정 시 버전 불일치.
RFC: RFC 9110 §15.5.10
410Gone
리소스가 영구적으로 삭제되었고 이전 주소도 없습니다.
사용 시점: 크롤러나 클라이언트가 해당 URL을 영구히 버리기를 원할 때 404 대신 씁니다.
RFC: RFC 9110 §15.5.11
411Length Required
서버는 Content-Length를 요구하는데 요청에 빠져 있습니다.
RFC: RFC 9110 §15.5.12
412Precondition Failed
If-Match / If-Unmodified-Since 검사가 실패했습니다.
사용 시점: 수정 시 낙관적 동시성 제어.
RFC: RFC 9110 §15.5.13
413Content Too Large
본문이 서버 한도를 넘었습니다. 예전 이름은 "Payload Too Large".
RFC: RFC 9110 §15.5.14
414URI Too Long
URL이 서버 한도를 넘었습니다(흔히 약 8KB).
RFC: RFC 9110 §15.5.15
415Unsupported Media Type
이 엔드포인트가 지원하지 않는 Content-Type입니다.
RFC: RFC 9110 §15.5.16
416Range Not Satisfiable
Range 헤더가 리소스 범위를 벗어난 바이트를 요청합니다.
RFC: RFC 9110 §15.5.17
417Expectation Failed
서버가 Expect: 헤더의 요구를 충족할 수 없습니다.
RFC: RFC 9110 §15.5.18
418I'm a teapot
만우절 상태 코드(RFC 2324). 일부 디버깅용 또는 허니팟 엔드포인트가 돌려줍니다.
RFC: RFC 2324
421Misdirected Request
응답을 만들 수 없는 서버로 요청이 전달되었습니다(예: 잘못된 SNI).
RFC: RFC 9110 §15.5.20
422Unprocessable Content
문법은 맞지만 의미가 틀렸습니다(예: 유효성 검사 실패).
사용 시점: JSON API의 폼 단위 유효성 검사 오류.
RFC: RFC 9110 §15.5.21
423Locked
WebDAV: 리소스가 잠겨 있습니다.
RFC: RFC 4918
424Failed Dependency
WebDAV: 연쇄된 앞선 요청이 실패했습니다.
RFC: RFC 4918
425Too Early
재전송 공격에 취약한 조기 데이터(TLS 1.3 0-RTT)를 서버가 거부합니다.
RFC: RFC 8470
426Upgrade Required
클라이언트가 다른 프로토콜로 업그레이드해야 합니다. Upgrade 헤더를 포함하세요.
RFC: RFC 9110 §15.5.22
428Precondition Required
서버가 조건부 요청을 요구합니다(If-Match 등).
사용 시점: 갱신 손실을 막기 위해 낙관적 동시성 토큰을 요구하는 API.
RFC: RFC 6585
429Too Many Requests
요청 빈도 제한에 걸렸습니다. Retry-After 헤더를 포함하세요.
RFC: RFC 6585
431Request Header Fields Too Large
헤더 전체 크기가 서버 한도를 넘었습니다.
RFC: RFC 6585
451Unavailable For Legal Reasons
법적 요구로 차단되었습니다(소설 「화씨 451」에서 따온 번호).
RFC: RFC 7725
500Internal Server Error
처리되지 않은 예외 또는 일반적인 서버 장애.
함정: 스택 트레이스를 절대 노출하지 마세요. 서버 쪽 로그에만 남기세요.
RFC: RFC 9110 §15.6.1
501Not Implemented
서버가 요청한 메서드를 아예 지원하지 않습니다.
RFC: RFC 9110 §15.6.2
502Bad Gateway
업스트림이 게이트웨이에 잘못된 응답을 돌려주었습니다.
사용 시점: 로드 밸런서가 오리진에 닿지 못하거나, 오리진이 엉뚱한 응답을 보냈을 때.
RFC: RFC 9110 §15.6.3
503Service Unavailable
서버가 일시적으로 중단되었거나 과부하 상태입니다. Retry-After를 포함하는 것이 좋습니다.
RFC: RFC 9110 §15.6.4
504Gateway Timeout
게이트웨이가 업스트림을 기다리다 포기했습니다.
RFC: RFC 9110 §15.6.5
505HTTP Version Not Supported
서버가 요청에 쓰인 HTTP 버전을 지원하지 않습니다.
RFC: RFC 9110 §15.6.6
506Variant Also Negotiates
투명 콘텐츠 협상 설정이 잘못되었습니다.
RFC: RFC 2295
507Insufficient Storage
WebDAV: 서버가 해당 표현을 저장할 수 없습니다.
RFC: RFC 4918
508Loop Detected
WebDAV: 처리 중 무한 루프가 감지되었습니다.
RFC: RFC 5842
510Not Extended
요청을 처리하려면 추가 확장이 필요합니다.
RFC: RFC 2774
511Network Authentication Required
종속 포털: 먼저 네트워크에 로그인하세요.
사용 시점: 공용 Wi-Fi 로그인 페이지.
RFC: RFC 6585

사용법

검색창에 코드·이름 또는 임의 단어를 입력하세요(예: '리디렉트', 'rate limit', '422').
컬러 칩으로 클래스별로 필터링하세요.
각 결과의 요약·사용 시점·함정·RFC 참조를 확인하세요.

자세한 설명

펼치기

100 Continue부터 511 Network Authentication Required까지 표준화된 HTTP 응답 코드 60여 개를 전부 담았고, 한 줄 요약과 RFC 참조, 권장 용법, 그리고 흔히 잘못 쓰이는 코드에 대한 "함정" 메모를 붙였습니다(401 대 403, 영원히 캐시되는 301, 400 대 422 등). 등급으로 걸러 보거나(1xx 정보, 2xx 성공, 3xx 리다이렉트, 4xx 클라이언트, 5xx 서버) 코드와 이름과 요약과 메모를 아우르는 전문 검색을 할 수 있습니다.

401과 403 짝이 무엇보다 자주 잘못 쓰이는데, 이름이 엉뚱한 쪽을 가리키기 때문입니다. 401 Unauthorized는 인증되지 않았다는 뜻입니다. 요청에 유효한 자격 증명이 없었으니 그것을 붙여 다시 시도해야 하고, 그래서 명세는 WWW-Authenticate 헤더를 함께 보내라고 요구합니다. 403 Forbidden은 자격 증명을 이해했는데도 답이 여전히 아니라는 뜻이라 다시 시도해도 달라지는 것이 없습니다. 로그아웃한 방문자에게 403을 보내면 그들에게 필요했던 로그인 안내를 감추는 셈입니다.

되돌릴 수 없는 것이 301입니다. 브라우저는 영구 리다이렉트를 적극적으로 캐시하고 상당수는 프로필을 지울 때까지 간직하므로, 잘못 보낸 301은 서버가 그것을 멈춘 뒤로도 한참 동안 개별 방문자를 따라다닙니다. 되돌릴 수도 있는 리다이렉트는 302나 307이어야 하고, 영구 형태는 이미 내린 결정의 몫입니다.

307과 308이 존재하는 이유는 옛 코드들이 잘못 구현되었기 때문입니다. 명세는 301이나 302가 요청 메서드를 보존한다고 줄곧 말해 왔지만 브라우저들은 POST를 GET으로 바꿨고, 웹의 상당 부분이 그 동작에 의존하게 되어 고칠 수 없게 됐습니다. 새 짝은 메서드가 살아남음을 보장하는데, 페이지 조회가 아닌 무언가를 리다이렉트할 때 중요한 차이가 그것입니다.

본문에 오류 메시지를 담은 200이 바로 이 목록이 막으려는 실패 양식입니다. 캐시와 재시도 로직, 모니터링, 클라이언트 라이브러리는 모두 상태 줄만 읽고 그 밖에는 읽지 않으므로, 성공 응답 안에서 실패를 보고하는 API는 그 위의 모든 계층에 보이지 않습니다.

코드는 제안이 아니라 계약입니다. 400과 404와 409와 422 사이에서 고르는 것은 설계 결정이지만, 동작하지 않은 일에 2xx를 고르는 것은 그렇지 않습니다.

자주 묻는 질문

왜 일부 코드에 '함정'을 표시?

몇몇 상태 코드는 자주 오용됩니다. 401은 '미인증'이지만 'unauthorized'로 읽혀 혼동되고, 301은 브라우저에서 사실상 영구 캐시되며, 400 vs 422는 끊임없이 논쟁거리입니다. 코드 리뷰·장애 회고에서 자주 문제되는 구체적 함정만 표시합니다.

WebDAV 코드도 포함?

포함됩니다 — 102·207·208·423·424·507·508과 해당 RFC. WebDAV를 직접 쓰지 않더라도 라이브러리·프록시가 노출하기도 하므로 의미를 알아두면 좋습니다.

비표준 코드(Cloudflare 520-527 등)는?

벤더 전용 코드(Cloudflare 520-527·AWS 460/463·IIS 440)는 제외했습니다. RFC에 없고 벤더마다 의미가 다르기 때문입니다. 해당 벤더 문서를 참고하세요.

왜 일부 코드는 '사용 시점' 필드가 비어있나?

이름만으로 자명하거나(200 OK·500 Internal Server Error) 특수 맥락에만 등장하면 요약만으로 충분합니다. 정말로 짚어야 할 이야기가 있을 때만 when/pitfall을 표시합니다.

HTTP 상태 코드 레퍼런스

사용법

자세한 설명

자주 묻는 질문

관련 도구

OCSP 응답·요청 디코더

JSON Diff 뷰어

ISO 국가·통화·언어 코드

Cache-Control 헤더 빌더

HTTP Basic 인증 인코더/디코더

HTTP 헤더 참조