본문으로 건너뛰기

무료 HTTP 상태 코드 참조

모든 HTTP 상태 코드에 대한 검색 가능한 참조 — 각 코드의 의미, 사용 시기, 일반적인 원인. 100에서 511까지.

한 번 로드하면 오프라인에서도 작동

61개 상태 코드

100

계속

서버가 요청 헤더를 받았으며 클라이언트는 본문으로 진행해야 합니다.

Expect: 100-continue 헤더가 포함된 요청에 사용됩니다. 서버는 클라이언트가 본문을 보내기 전에 본문을 수신할 의향이 있음을 확인합니다. 현대 웹 앱에서는 거의 볼 수 없습니다.

RFC 9110 ↗
101

프로토콜 전환

서버가 클라이언트에서 요청한 대로 프로토콜을 전환하고 있습니다.

가장 일반적으로 WebSocket 업그레이드에 사용됩니다. 클라이언트가 Upgrade: websocket을 요청하면 서버가 101로 응답하여 전환합니다.

RFC 9110 ↗
102

처리 중

서버가 요청을 받았으며 처리 중이지만 아직 응답을 사용할 수 없습니다.

WebDAV: 긴 작업 중 클라이언트 타임아웃을 방지하기 위해 전송된 중간 응답입니다. 더 이상 사용되지 않음 - 최신 서버는 이를 전송하지 않아야 합니다.

RFC 2518 ↗
103

조기 힌트

최종 응답 전에 전송된 예비 헤더입니다.

서버가 최종 응답이 준비되는 동안 Link 헤더(미리로드/미리연결)를 전송하여 브라우저가 중요한 자산을 더 빨리 가져올 수 있도록 합니다.

RFC 8297 ↗
200

OK

요청이 성공했습니다.

표준 성공 응답입니다. 의미는 HTTP 메서드에 따라 다릅니다: GET → 리소스 반환됨, POST/PUT → 작업 완료됨.

RFC 9110 ↗
201

생성됨

새 리소스가 성공적으로 생성되었습니다.

POST 후 일반적입니다. 응답에는 새 리소스의 URL을 가리키는 Location 헤더가 포함되어야 합니다.

RFC 9110 ↗
202

수락됨

요청이 처리를 위해 수락되었지만 처리가 완료되지 않았습니다.

비동기 작업의 경우 - 서버가 작업을 대기열에 넣고 있습니다. 클라이언트는 상태 엔드포인트를 폴링하거나 나중에 다시 확인해야 합니다.

RFC 9110 ↗
203

비권위적 정보

응답이 변환 프록시에 의해 수정되었습니다.

요청이 성공했지만 중개자(예: 캐싱 또는 변환 프록시)가 원본 서버의 페이로드를 수정했습니다. 예를 들어 이미지를 다시 압축했습니다. 실제로는 드뭅니다.

RFC 9110 ↗
204

콘텐츠 없음

요청이 성공했지만 응답 본문이 없습니다.

DELETE 작업이나 본문을 반환할 필요가 없는 PUT 업데이트에 자주 사용됩니다. 클라이언트는 현재 페이지에서 벗어나지 않아야 합니다.

RFC 9110 ↗
205

콘텐츠 재설정

요청이 성공했으며 클라이언트는 문서 보기를 재설정해야 합니다.

204와 유사하게 본문이 반환되지 않습니다. 하지만 클라이언트는 추가로 요청을 생성한 양식 또는 보기를 재설정하도록 지시됩니다(예: 다음 항목 입력을 위해 양식 필드를 비웁니다).

RFC 9110 ↗
206

부분 콘텐츠

서버가 리소스의 일부만 제공했습니다.

Range 요청에 대한 응답입니다. 비디오 플레이어와 다운로드 관리자가 중단된 다운로드를 재개하거나 대용량 파일을 스트리밍하는 데 사용됩니다.

RFC 9110 ↗
207

다중 상태

응답 본문에 여러 작업에 대한 여러 상태 코드가 포함되어 있습니다.

WebDAV: XML 본문은 여러 하위 작업의 결과를 독립적으로 보고합니다. 예를 들어 일부 항목이 성공하고 다른 항목이 실패한 일괄 이동입니다.

RFC 4918 ↗
208

이미 보고됨

컬렉션의 멤버가 응답의 앞부분에서 이미 나열되었습니다.

WebDAV: 바인딩이 루프를 생성할 때 207 다중 상태 응답 내에서 같은 컬렉션의 멤버를 반복적으로 나열하지 않기 위해 사용됩니다.

RFC 5842 ↗
226

IM 사용됨

응답은 리소스에 적용된 인스턴스 조작의 결과입니다.

델타 인코딩: 서버가 전체 리소스 대신 이전 버전에 대한 diff를 반환하여 대역폭을 절약합니다. 매우 드물게 구현됩니다.

RFC 3229 ↗
300

다중 선택

리소스의 여러 표현을 사용할 수 있습니다.

서버가 여러 옵션(예: 다양한 형식 또는 언어)을 제공하며 클라이언트가 하나를 선택해야 합니다. 자동 콘텐츠 협상이 일반적으로 이를 처리하기 때문에 거의 사용되지 않습니다.

RFC 9110 ↗
301

영구적으로 이동됨

리소스가 새 URL로 영구적으로 이동되었습니다.

영구적인 URL 변경에 사용합니다. 검색 엔진이 인덱스를 업데이트합니다. SEO 권한이 새 URL로 전송됩니다.

RFC 9110 ↗
302

찾음 (임시 리다이렉트)

리소스가 일시적으로 다른 URL에 있습니다.

리다이렉트가 영구적이지 않음을 나타냅니다. 캐싱이 301보다 덜 적극적입니다. '로그인 필요, /login으로 리다이렉트 중' 같은 경우에 사용합니다.

RFC 9110 ↗
303

다른 것 참조

GET을 사용하여 다른 URL로 리다이렉트합니다.

POST 제출 후에 사용됩니다. 응답은 '당신의 POST가 작동했습니다. 결과를 보려면 이 GET URL을 참조하세요'라고 말합니다. 브라우저는 항상 새 URL을 GET합니다.

RFC 9110 ↗
304

수정되지 않음

캐시된 버전이 여전히 유효합니다. 그것을 사용하세요.

조건부 요청에 대한 응답(If-None-Match 또는 If-Modified-Since 헤더 포함). 대역폭을 절약합니다. 본문이 반환되지 않습니다.

RFC 9110 ↗
307

임시 리다이렉트

302와 같지만 원본 HTTP 메서드를 보존합니다.

원본이 POST였다면 리다이렉트도 POST를 사용합니다. 메서드 보존이 중요할 때 302의 최신 대체재입니다.

RFC 9110 ↗
308

영구 리다이렉트

301과 같지만 원본 HTTP 메서드를 보존합니다.

POST 요청이 리다이렉트 후에도 POST로 유지되기를 원할 때 301의 최신 대체재입니다.

RFC 9110 ↗
400

잘못된 요청

서버가 잘못된 구문으로 인해 요청을 이해할 수 없습니다.

일반적인 원인: 본문의 잘못된 형식의 JSON, 잘못된 쿼리 매개변수 또는 필수 필드 누락. 요청 본문과 헤더를 확인하세요.

RFC 9110 ↗
401

인증 필요

인증이 필요하며 제공되지 않았습니다.

클라이언트는 인증 자격증명(Authorization 헤더, 쿠키, 토큰)을 포함해야 합니다. 'Unauthorized'(권한 없음)는 잘못된 명칭이며, 실제로는 '인증되지 않음'을 의미합니다.

RFC 9110 ↗
402

결제 필요

향후 사용을 위해 예약됨 - 때때로 유료 API 계층에 사용됩니다.

원래는 디지털 결제용으로 의도되었습니다. 최신 사용법: 일부 API는 사용자가 유료 할당량을 초과했을 때 402를 반환합니다.

RFC 9110 ↗
403

금지됨

클라이언트는 인증되었지만 권한이 없습니다.

401과 다릅니다. 사용자는 로그인 상태이지만 이 리소스에 대한 권한이 없습니다. 역할/권한 논리를 확인하세요.

RFC 9110 ↗
404

찾을 수 없음

요청된 리소스가 존재하지 않습니다.

URL이 잘못되었거나 리소스가 삭제되었거나 존재하지 않았습니다. 서버는 때때로 403이 더 정확할 때 404를 반환합니다.

RFC 9110 ↗
405

메서드 허용 안 됨

사용된 HTTP 메서드가 이 리소스에 허용되지 않습니다.

예를 들어 POST만 허용하는 엔드포인트에 대한 GET 요청입니다. 응답에는 유효한 메서드를 나열하는 Allow 헤더가 포함되어야 합니다.

RFC 9110 ↗
406

수용 불가

클라이언트의 Accept 헤더와 일치하는 표현이 없습니다.

클라이언트가 서버가 만족할 수 없는 콘텐츠 유형, 언어 또는 인코딩을 요청했습니다(Accept, Accept-Language, Accept-Encoding을 통해). 많은 서버는 엄격한 협상을 건너뛰고 대신 기본값을 반환합니다.

RFC 9110 ↗
407

프록시 인증 필요

클라이언트는 먼저 프록시를 통해 인증해야 합니다.

401과 유사하지만 프록시에서 발급됨: 클라이언트는 Proxy-Authorization 자격증명을 보내야 합니다. 인증하는 프록시가 있는 회사 네트워크에서 볼 수 있습니다.

RFC 9110 ↗
408

요청 시간 초과

서버가 요청을 기다리다가 시간이 초과되었습니다.

클라이언트가 요청 본문을 보내는 데 너무 오래 걸렸거나 연결을 유휴 상태로 유지했습니다. 요청을 다시 시도하세요.

RFC 9110 ↗
409

충돌

요청이 리소스의 현재 상태와 충돌합니다.

일반적으로 동시 편집 충돌이나 중복 리소스 생성(예: 이미 존재하는 이메일로 사용자 생성)에 대해 반환됩니다.

RFC 9110 ↗
410

영구 삭제됨

리소스가 삭제되었으며 복구되지 않습니다.

404보다 강함 — 서버는 리소스가 과거에 존재했다는 것을 명시적으로 알고 있지만 영구적으로 제거되었습니다. 검색 엔진이 인덱스를 제거합니다.

RFC 9110 ↗
411

길이 필요

서버는 Content-Length 헤더가 필요합니다.

요청에 Content-Length 헤더가 없어서 거부되었으며 서버가 알 수 없는 크기의 본문을 거부합니다. 헤더를 추가하고 다시 시도하세요.

RFC 9110 ↗
412

전제 조건 실패

요청 헤더의 조건이 충족되지 않았습니다.

If-Match 또는 If-Unmodified-Since와 같은 조건부 헤더가 실패할 때 반환됩니다. 일반적으로 낙관적 잠금: 다른 사람이 당신의 버전 이후로 리소스를 변경했습니다. 다시 가져오고 재시도하세요.

RFC 9110 ↗
413

페이로드가 너무 큼

요청 본문이 서버의 크기 제한을 초과합니다.

대용량 파일을 업로드할 때 일반적입니다. 서버 구성(nginx, apache)이 최대 본문 크기를 설정합니다. 서버 구성을 확인하세요.

RFC 9110 ↗
414

URI가 너무 김

요청 URL이 서버의 길이 제한을 초과합니다.

일반적으로 매우 긴 쿼리 문자열(예: GET에서 데이터 인코딩)로 인해 발생합니다. POST 본문으로 전환하거나 제어할 수 있는 경우 서버 제한을 높이세요.

RFC 9110 ↗
415

지원되지 않는 미디어 유형

서버가 전송된 Content-Type을 처리할 수 없습니다.

예를 들어 application/json만 허용하는 서버에 application/xml을 보내는 경우입니다. Content-Type 헤더를 올바르게 설정하세요.

RFC 9110 ↗
416

범위를 만족할 수 없음

요청한 바이트 범위가 리소스의 크기를 벗어납니다.

Range 헤더가 파일에 없는 부분을 요청합니다. 예: 파일 끝을 넘어서 다운로드를 재개합니다. 응답에 실제 크기가 포함된 Content-Range가 포함되어야 합니다.

RFC 9110 ↗
417

예상 실패

서버가 Expect 헤더의 요구 사항을 충족할 수 없습니다.

서버가 Expect: 100-continue를 지원하지 않을 때 전송됩니다. 일부 클라이언트는 대용량 POST에서 기본적으로 이 헤더를 보냅니다. 비활성화하면 일반적으로 오류가 해결됩니다.

RFC 9110 ↗
418

찻주전자입니다

서버가 찻주전자이기 때문에 커피를 끓이기를 거부합니다.

1998년의 만우절 농담입니다(RFC 2324). 일부 실제 API는 농담이나 더 이상 사용되지 않는 끝점을 표시하는 데 사용합니다. 프로덕션 사용을 위한 것이 아닙니다.

RFC 2324 ↗
421

잘못 전달된 요청

요청이 이에 대한 응답을 생성할 수 없는 서버로 전송되었습니다.

HTTP/2 연결 재사용으로 일반적입니다: 요청이 대상 호스트명에 대해 구성되지 않은 서버에 도달했습니다. 클라이언트는 새 연결에서 재시도해야 합니다.

RFC 9110 ↗
422

처리할 수 없는 콘텐츠

요청이 구문적으로는 유효하지만 의미상 잘못되었습니다.

예를 들어 JSON이 올바르게 파싱되었지만 필수 필드가 누락되었거나 필드 값이 범위를 벗어났습니다. REST API 검증 응답에서 일반적입니다.

RFC 9110 ↗
423

잠김

리소스가 잠겨있습니다.

WebDAV: 소스 또는 대상 리소스가 다른 클라이언트에 의해 잠겨있어서 작업을 진행할 수 없습니다. 잠금이 해제될 때까지 기다리거나 올바른 토큰으로 해제하세요.

RFC 4918 ↗
424

종속성 실패

요청이 실패했습니다. 이전 종속 요청이 실패했기 때문입니다.

WebDAV: 종속 작업의 체인에서 이전 작업이 실패해서 이 작업은 수행되지 않았습니다. 근본 원인을 찾기 위해 이전 실패를 살펴보세요.

RFC 4918 ↗
425

너무 빠름

서버가 재생될 수 있는 요청 처리를 거부합니다.

TLS 1.3 0-RTT(초기 데이터)와 관련: 서버가 재전송되었을 수 있는 요청을 처리하는 위험을 감수하지 않습니다. 클라이언트는 핸드셰이크가 완료된 후 재시도해야 합니다.

RFC 8470 ↗
426

업그레이드 필요

클라이언트는 다른 프로토콜로 전환해야 합니다.

서버는 현재 프로토콜을 통해 요청을 제공하기를 거부하지만 업그레이드 후에 제공할 것입니다. 응답에 필요한 프로토콜을 지정하는 Upgrade 헤더가 포함됩니다.

RFC 9110 ↗
428

전제 조건 필수

서버는 요청이 조건부일 것을 요구합니다.

서버는 업데이트 손실 충돌을 방지하기 위해 조건부 헤더(예: If-Match)를 요구합니다. 리소스를 가져오고 ETag를 캡처한 후 If-Match와 함께 다시 보내세요.

RFC 6585 ↗
429

너무 많은 요청

클라이언트가 속도 제한을 받고 있습니다.

속도를 늦추세요. 응답에는 언제 다시 시도할지를 나타내는 Retry-After 헤더가 포함되어야 합니다. 요청 할당량이 있는 API에서 일반적입니다.

RFC 6585 ↗
431

요청 헤더 필드가 너무 큼

헤더가 서버에서 처리하기에 너무 큽니다.

단일 헤더 또는 총 헤더 크기가 제한을 초과합니다. 과도한 쿠키로 인해 가장 자주 발생합니다. 쿠키를 지우거나 앱이 저장하는 내용을 줄이세요.

RFC 6585 ↗
451

법적 이유로 이용할 수 없음

법적 요구로 인한 접근 거부.

리소스가 법적 이유로 차단됩니다. 검열, 법원 명령 또는 지역 규정입니다. 숫자는 소설 화씨 451의 참고입니다.

RFC 7725 ↗
500

내부 서버 오류

서버가 예상치 못한 상황을 만났습니다.

서버 측 오류에 대한 포괄적인 범용 응답입니다. 서버 로그에서 실제 원인을 확인하세요: 처리되지 않은 예외, 데이터베이스 오류 등.

RFC 9110 ↗
501

구현되지 않음

서버가 요청한 기능을 지원하지 않습니다.

예를 들어 서버가 HTTP 메서드를 인식하지 못합니다. 실제로는 드문 일입니다. 더 자주 405가 표시됩니다.

RFC 9110 ↗
502

잘못된 게이트웨이

서버가 게이트웨이 역할을 하면서 업스트림 서버에서 잘못된 응답을 받았습니다.

마이크로서비스 아키텍처에서 일반적입니다. 로드 밸런서 또는 역방향 프록시가 백엔드 서비스에서 잘못된 응답을 받았습니다.

RFC 9110 ↗
503

서비스 이용 불가

서버가 요청을 처리할 수 없는 상태입니다.

유지 관리 중이거나 과부하 상태입니다. 응답에는 Retry-After 헤더가 포함되어야 합니다. 종종 배포 중에 반환됩니다.

RFC 9110 ↗
504

게이트웨이 시간 초과

게이트웨이 서버가 업스트림 응답을 기다리다가 시간이 초과되었습니다.

백엔드 서비스가 충분히 빠르게 응답하지 않았습니다. 업스트림 서비스 상태 및 시간 초과 구성을 확인하세요.

RFC 9110 ↗
505

지원되지 않는 HTTP 버전

서버가 요청에 사용된 HTTP 버전을 지원하지 않습니다.

요청의 주요 HTTP 버전이 서버에서 지원되지 않습니다. 최신 클라이언트에서는 거의 볼 수 없습니다.

RFC 9110 ↗
506

변형도 협상

서버의 콘텐츠 협상 구성이 잘못되었습니다.

투명한 콘텐츠 협상이 루프에 빠졌습니다: 선택한 변형은 협상하도록 구성되어 있습니다. 서버 구성 오류를 나타냅니다.

RFC 2295 ↗
507

저장소 부족

서버의 디스크 공간이 부족합니다.

원래 WebDAV 전용이지만 일반 서버에서도 때때로 사용됩니다. 저장소 제약으로 인해 서버가 요청을 저장할 수 없다는 뜻입니다.

RFC 4918 ↗
508

루프 감지됨

서버가 요청 처리 중 무한 루프를 감지했습니다.

WebDAV: Depth: infinity 요청을 처리하는 동안 루프에 진입했습니다(예: 순환 바인딩). 작업이 종료되었습니다.

RFC 5842 ↗
510

확장되지 않음

요청에 대한 추가 확장이 필요합니다.

더 이상 사용되지 않는 HTTP 확장 프레임워크에서: 서버가 요청을 이행하기 전에 더 많은 정보가 필요합니다. 실질적으로 최신 웹에서 사용되지 않습니다.

RFC 2774 ↗
511

네트워크 인증 필요

클라이언트가 네트워크 접근을 위해 인증해야 합니다.

캡티브 포털(호텔/공항 WiFi)에서 사용되어 사용자가 외부 사이트에 접근하기 전에 네트워크에 로그인해야 함을 나타냅니다.

RFC 6585 ↗

주요 용도

  • API 설계 참고REST API를 설계할 때 각 응답에 올바른 상태 코드를 선택합니다.
  • 오류 코드 빠르게 조회앱이 혼란스러운 HTTP 오류를 반환할 때 실제로 무엇을 의미하는지 조회합니다.
  • HTTP 상태 코드 배우기HTTP 및 REST를 배우는 학생 및 개발자를 위한 포괄적인 참고 자료.
  • 사건 중 빠른 참고프로덕션 사건 중에 각 상태 코드가 의미하는 바를 빠르게 조회합니다.
  • API 문서 참조API 문서를 작성할 때 반환하는 상태 코드의 신뢰할 수 있는 설명에 링크하세요.

사용 방법

이 도구는 다섯 가지 클래스(1xx–5xx)에 걸친 63개 HTTP 상태 코드를 각각 정의 RFC 번호와 함께 담은 하드코딩 조회표를 기반으로 한 클라이언트 측 참조 도구입니다. 서버 호출, 외부 API, 네트워크 요청이 없으며, 모든 필터링과 표시는 JavaScript 내장 배열 및 문자열 메서드로 브라우저에서 이루어집니다.

  1. 1
    조회표 로드
    IANA에 등록된 63개 상태 코드 전체가 JavaScript 배열로 도구에 직접 포함되어 있으며, 각 항목에는 숫자 코드, 표준 영어 이름, 분류, 이를 정의하는 RFC(예: 대부분의 HTTP/1.1 코드는 RFC 9110, 429 Too Many Requests는 RFC 6585, 418 I'm a Teapot은 RFC 2324)가 담겨 있습니다.
  2. 2
    메모리에서 필터 실행
    입력하거나 분류 필터를 선택하면 메모리의 목록에 JavaScript Array.filter가 실행되어, String.includes로 검색어를 상태 코드 번호, 표준 이름, 짧은 설명과 긴 설명 문자열에 대조합니다. 디바운스 지연도 서버 왕복도 없습니다.
  3. 3
    RFC 링크와 함께 세부 정보 펼치기
    각 결과는 HTML details/summary 요소로 렌더링됩니다. 항목을 펼치면 긴 설명과 rfc-editor.org의 공식 RFC 직접 링크가 표시되어 어떤 코드든 정확한 규격 원문을 읽을 수 있습니다.
  4. 4
    딥 링크와 클립보드 복사
    항목을 열면 URL 해시가 코드 번호(예: #404)로 업데이트되어 페이지를 공유하거나 북마크하기 쉽습니다. 복사 버튼은 브라우저의 navigator.clipboard API로 표준 문자열(예: '404 Not Found')을 클립보드에 씁니다.

관련 도구

자주 묻는 질문