nicetool.dev logo

HTTP 상태 코드

번호나 이름으로 검색하거나 분류로 필터링하세요. 각 코드는 명세에 연결됩니다.

1xx 정보

요청을 받았고 처리가 계속됩니다. 애플리케이션 코드에서는 드물게 보입니다.

100

Continue

서버가 요청 헤더를 받았으니 클라이언트는 본문을 보내도 됩니다. 대용량 업로드 전에 "Expect: 100-continue"와 함께 씁니다.

RFC 9110
101

Switching Protocols

클라이언트의 요청대로 프로토콜을 전환합니다. 예: HTTP/1.1에서 WebSocket으로.

RFC 9110
102

Processing

WebDAV: 서버가 요청을 받아 아직 처리 중이므로 클라이언트는 시간 초과로 끊지 말아야 합니다.

RFC 2518
103

Early Hints

서버가 최종 응답을 준비하는 동안 Link 헤더를 먼저 보내 브라우저가 CSS나 폰트를 미리 불러오게 합니다.

RFC 8297

2xx 성공

요청을 받고 이해했으며 수락했습니다.

200

OK

요청이 성공했습니다. 본문에 요청한 리소스나 작업 결과가 들어 있습니다.

RFC 9110
201

Created

새 리소스가 생성되었습니다. 보통 POST 이후이며 Location 헤더가 그 위치를 가리킵니다.

RFC 9110
202

Accepted

요청을 처리하도록 접수했지만 아직 끝나지 않았습니다. 대기열에 들어간 백그라운드 작업 등.

RFC 9110
203

Non-Authoritative Information

성공이지만 변환 프록시가 응답을 수정해 원 서버가 보낸 것과 정확히 같지는 않습니다.

RFC 9110
204

No Content

성공했지만 돌려줄 본문이 없습니다. DELETE나 페이지 새로고침 없는 폼 저장에 자주 씁니다.

RFC 9110
205

Reset Content

성공. 클라이언트는 요청을 보낸 폼이나 화면을 초기화해야 합니다.

RFC 9110
206

Partial Content

Range 헤더대로 리소스의 일부만 반환합니다. 이어받기 다운로드와 동영상 탐색에 쓰입니다.

RFC 9110
207

Multi-Status

WebDAV: 본문에 여러 작업에 대한 여러 상태 코드가 들어 있습니다.

RFC 4918
208

Already Reported

WebDAV: 응답 앞부분에서 이미 나열한 항목은 반복하지 않습니다.

RFC 5842
226

IM Used

서버가 응답에 델타 인코딩을 적용했습니다. 거의 쓰이지 않습니다.

RFC 3229

3xx 리다이렉션

요청을 완료하려면 보통 다른 URL로 이동하는 등 추가 동작이 필요합니다.

300

Multiple Choices

언어나 형식 등 여러 표현이 있어 클라이언트가 하나를 골라야 합니다.

RFC 9110
301

Moved Permanently

리소스가 Location에 적힌 새 URL로 영구 이동했습니다. 검색 엔진은 순위를 새 URL로 넘깁니다.

RFC 9110
302

Found

리소스가 일시적으로 다른 URL에 있습니다. 클라이언트는 원래 URL을 계속 쓰며, 브라우저는 POST를 GET으로 바꿀 수 있습니다.

RFC 9110
303

See Other

결과를 다른 URL에서 GET으로 받을 수 있습니다. 폼 POST 후 재전송을 막는 데 씁니다(Post/Redirect/Get).

RFC 9110
304

Not Modified

캐시된 사본이 여전히 유효하므로(If-None-Match나 If-Modified-Since 일치) 본문을 보내지 않습니다.

RFC 9110
307

Temporary Redirect

메서드와 본문을 유지하는 임시 리다이렉트입니다. POST는 POST로 유지됩니다.

RFC 9110
308

Permanent Redirect

메서드와 본문을 유지하는 영구 리다이렉트입니다. 301의 엄격한 버전입니다.

RFC 9110

4xx 클라이언트 오류

요청에 문제가 있습니다: 잘못된 문법, 인증 누락, 권한 없음, 존재하지 않는 리소스 등.

400

Bad Request

요청 형식이 잘못되어 처리할 수 없습니다. 문법 오류, 깨진 JSON, 잘못된 매개변수 등.

RFC 9110
401

Unauthorized

인증이 없거나 유효하지 않습니다. 응답의 WWW-Authenticate 헤더가 로그인 방법을 알려 줍니다.

RFC 9110
402

Payment Required

미래의 디지털 결제를 위해 예약된 코드입니다. 구독이나 사용량 결제가 필요할 때 쓰는 API도 있습니다.

RFC 9110
403

Forbidden

서버는 누구인지 알지만 권한이 없어 작업을 거부합니다. 다시 로그인해도 해결되지 않습니다.

RFC 9110
404

Not Found

리소스가 없거나, 서버가 존재 여부를 밝히고 싶지 않은 경우입니다.

RFC 9110
405

Method Not Allowed

이 URL에서 해당 HTTP 메서드를 지원하지 않습니다. 예: 읽기 전용 리소스에 POST. Allow 헤더가 가능한 메서드를 알려 줍니다.

RFC 9110
406

Not Acceptable

Accept 헤더(형식, 언어, 인코딩)에 맞는 응답을 만들 수 없습니다.

RFC 9110
407

Proxy Authentication Required

401과 같지만 먼저 프록시에서 인증해야 합니다.

RFC 9110
408

Request Timeout

클라이언트가 요청을 다 보내기를 너무 오래 기다려 서버가 연결을 닫았습니다.

RFC 9110
409

Conflict

편집 충돌이나 고유 키 중복처럼 요청이 현재 상태와 충돌합니다.

RFC 9110
410

Gone

리소스가 의도적으로 삭제되었고 돌아오지 않습니다. 검색 엔진은 404보다 빨리 제거합니다.

RFC 9110
411

Length Required

이 요청에는 Content-Length 헤더가 필요합니다.

RFC 9110
412

Precondition Failed

If-Match 같은 조건부 헤더가 일치하지 않았습니다. 다른 사람의 변경을 덮어쓰지 않으려고 자주 씁니다.

RFC 9110
413

Content Too Large

요청 본문이 서버 허용치보다 큽니다(예전 이름 "Payload Too Large").

RFC 9110
414

URI Too Long

URL이 서버가 받는 길이보다 깁니다. GET 쿼리 문자열에 데이터를 너무 많이 넣었을 때 흔히 생깁니다.

RFC 9110
415

Unsupported Media Type

본문 형식(Content-Type)을 지원하지 않습니다. 예: JSON 전용 API에 XML 전송.

RFC 9110
416

Range Not Satisfiable

Range 헤더가 파일에 없는 부분을 요청합니다.

RFC 9110
417

Expectation Failed

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

RFC 9110
418

I'm a teapot

커피 포트 제어 프로토콜에서 나온 만우절 농담입니다. 찻주전자는 커피를 끓일 수 없습니다. 이스터 에그로 쓰는 사이트도 있습니다.

RFC 2324
421

Misdirected Request

이 호스트에 응답할 수 없는 서버로 요청이 갔습니다. 재사용한 HTTP/2 연결이 다른 오리진을 가리킬 때 생깁니다.

RFC 9110
422

Unprocessable Content

문법은 맞지만 내용이 유효하지 않습니다. 검증 규칙 위반 등(예전 이름 "Unprocessable Entity").

RFC 9110
423

Locked

WebDAV: 리소스가 잠겨 있습니다.

RFC 4918
424

Failed Dependency

WebDAV: 의존하던 다른 요청이 실패해 이 요청도 실패했습니다.

RFC 4918
425

Too Early

TLS 1.3 early data처럼 재전송될 수 있는 요청은 서버가 처리하지 않습니다.

RFC 8470
426

Upgrade Required

클라이언트는 Upgrade 헤더에 적힌 다른 프로토콜로 바꿔야 합니다.

RFC 9110
428

Precondition Required

업데이트 유실을 막기 위해 서버가 조건부 요청(If-Match)을 요구합니다.

RFC 6585
429

Too Many Requests

정해진 시간 동안 요청이 너무 많습니다(속도 제한). Retry-After가 다시 시도할 시점을 알려 줍니다.

RFC 6585
431

Request Header Fields Too Large

헤더 전체 또는 하나의 헤더가 너무 큽니다. 커진 쿠키가 원인인 경우가 많습니다.

RFC 6585
451

Unavailable For Legal Reasons

검열이나 법원 명령 같은 법적 이유로 차단되었습니다. 숫자는 소설 "화씨 451"에서 따왔습니다.

RFC 7725

5xx 서버 오류

요청은 유효해 보였지만 서버가 처리하지 못했습니다.

500

Internal Server Error

일반 오류: 서버에서 예상치 못한 문제가 생겼습니다. 서버 로그를 확인하세요.

RFC 9110
501

Not Implemented

요청을 처리하는 데 필요한 기능이나 메서드를 서버가 지원하지 않습니다.

RFC 9110
502

Bad Gateway

게이트웨이나 프록시가 상위 서버에서 잘못된 응답을 받았습니다. Nginx 뒤의 앱이 죽었을 때 등.

RFC 9110
503

Service Unavailable

과부하나 점검 때문에 일시적으로 요청을 처리할 수 없습니다. Retry-After로 재개 시점을 알려 줄 수 있습니다.

RFC 9110
504

Gateway Timeout

게이트웨이나 프록시가 상위 서버로부터 제때 응답을 받지 못했습니다.

RFC 9110
505

HTTP Version Not Supported

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

RFC 9110
506

Variant Also Negotiates

콘텐츠 협상 설정 오류: 선택된 변형이 다시 협상을 시도합니다.

RFC 2295
507

Insufficient Storage

WebDAV: 요청을 완료하는 데 필요한 데이터를 서버가 저장할 수 없습니다.

RFC 4918
508

Loop Detected

WebDAV: 처리 중 무한 루프를 발견했습니다.

RFC 5842
510

Not Extended

요청에 추가 확장이 필요합니다. 폐기되어 거의 쓰이지 않습니다.

RFC 2774
511

Network Authentication Required

클라이언트가 먼저 네트워크에 로그인해야 합니다. 호텔이나 공항 와이파이의 캡티브 포털이 대표적입니다.

RFC 6585

HTTP 상태 코드란?

모든 HTTP 응답은 요청 결과를 클라이언트에 알려 주는 세 자리 상태 코드로 시작합니다. 첫 자리가 분류를 나타내며 1xx는 정보, 2xx는 성공, 3xx는 리다이렉션, 4xx는 클라이언트 오류, 5xx는 서버 오류입니다. 브라우저, 검색 엔진, 캐시, API 클라이언트, 모니터링 도구가 모두 이 코드에 따라 동작하므로 알맞은 코드를 고르는 것이 중요합니다. 301은 SEO 가치를 새 URL로 넘기지만 302는 넘기지 않고, 503은 크롤러에게 나중에 다시 오라고, 429는 API 클라이언트에게 속도를 줄이라고 알립니다. 코드는 주로 RFC 9110(HTTP Semantics)에 정의되어 있고 일부는 별도 RFC에 있습니다.

기능

  • • IANA에 등록된 상태 코드 61개 전부(100~511)
  • • 각 코드의 의미와 사용 시점을 쉽게 설명
  • • 번호, 이름, 키워드로 즉시 검색하고 분류로 필터링
  • • 각 코드를 정의한 RFC 섹션으로 바로 연결
  • • 분류별 색상 표시와 #코드 앵커로 링크 공유

빠르고 오프라인 친화적

전체 레퍼런스가 페이지에 포함되어 있어 서버 요청 없이 브라우저에서 바로 검색됩니다.

검색 가능한 레퍼런스, 추적 없음.

HTTP 상태 코드 사용 방법

  1. 1

    검색 칸에 404 같은 번호, "gateway" 같은 이름, "redirect" 같은 단어를 입력하세요. 입력하는 대로 결과가 바뀝니다.

  2. 2

    분류 버튼(1xx~5xx)으로 목록을 좁힙니다. 예를 들어 클라이언트 오류를 한 번에 살펴볼 수 있습니다.

  3. 3

    각 코드 아래 설명에서 의미, 서버가 보내야 하는 상황, 클라이언트의 반응을 확인합니다.

  4. 4

    RFC 링크로 정확한 명세를 보거나 #429 같은 앵커로 특정 코드 링크를 공유합니다.

활용 예시

REST API 설계

POST 후에는 Location 헤더와 함께 201 Created, DELETE 후에는 204 No Content, 잘못된 JSON에는 400, 검증 오류에는 422, 현재 상태와 충돌하면 409를 반환합니다.

SEO를 지키며 페이지 이전

영구 이전에는 301이나 308을 써서 검색 순위를 넘기고, A/B 테스트 같은 임시 리다이렉트에는 302나 307을 씁니다. 308과 307은 POST를 POST로 유지합니다.

인증 오류

로그인하지 않았거나 토큰이 잘못되면 401, 사용자는 알지만 권한이 없으면 403을 보냅니다. 리소스 존재 여부를 숨기려고 403 대신 404를 반환하는 API도 많습니다.

점검과 과부하

점검 중에는 Retry-After 헤더와 함께 503을 반환해 크롤러가 순위를 유지하게 하고, 요청 한도를 넘은 클라이언트에는 Retry-After와 함께 429를 반환합니다.

자주 묻는 질문

401과 403의 차이는?+

401 Unauthorized는 "누구세요?", 즉 인증이 없거나 실패했다는 뜻입니다. 403 Forbidden은 "누군지는 알지만 이 작업은 허용되지 않는다"는 뜻입니다. 다시 로그인하면 401은 해결되지만 403은 아닙니다.

리다이렉트는 301과 302 중 무엇을?+

기존 URL이 영구히 사라지면 301(또는 308), 다시 돌아온다면 302(또는 307)를 쓰세요. 영구 이전에 302를 쓰면 새 URL 색인이 늦어질 수 있습니다.

502, 503, 504의 차이는?+

502 Bad Gateway: 프록시가 상위 서버에서 잘못된 응답을 받았습니다. 503 Service Unavailable: 서버가 과부하이거나 점검 중입니다. 504 Gateway Timeout: 상위 서버가 제때 응답하지 않았습니다.

오류에 200과 오류 메시지를 보내도 되나요?+

안 됩니다. 클라이언트, 캐시, 모니터링은 상태 코드를 기준으로 동작합니다. 실패에 200을 보내면 도구가 오류를 못 보고 오류 페이지가 "소프트 404"로 색인될 수 있습니다.