HTTP 상태 코드 표

HTTP 상태 코드 표 사용법

HTTP 상태 코드는 웹 서버가 요청을 처리한 결과를 세 자리 숫자로 알려 주는 것입니다. 브라우저 화면에 뜨는 "404 Not Found", 서버 로그에 줄줄이 찍힌 200과 502, API가 돌려주는 401 같은 숫자가 모두 이것입니다. 이 표는 표준 코드와 nginx, 클라우드플레어가 쓰는 비표준 코드를 합쳐 70개를 싣고, 코드마다 뜻뿐 아니라 실제로 어떤 상황에서 나오는지와 무엇을 확인해야 하는지를 함께 적었습니다.

찾는 방법

1. 찾기 칸에 번호를 넣습니다. "404"처럼 하나만 넣어도 되고 "502 503 504"처럼 여러 개를 띄어 써도 됩니다. "50"을 넣으면 50으로 시작하는 코드가, "4xx"를 넣으면 400번대 전체가 나옵니다.
2. 번호를 모르면 낱말로 찾습니다. "권한", "쿠키", "업로드", "timeout", "gateway" 같은 말을 넣으면 이름, 뜻, 원인, 해결 어디에든 그 말이 들어 있는 코드가 나옵니다.
3. 찾기 아래의 버튼으로 종류별로 거릅니다. 자주 보는 것만은 실무에서 흔히 만나는 23개만 추립니다.
4. 코드 번호를 누르면 "404 Not Found"처럼 번호와 이름이 복사됩니다. 문서나 메신저에 붙일 때 씁니다.

번호 하나만 찾은 상태에서는 주소 끝에 #c=404 처럼 번호가 붙으므로 그 주소를 동료에게 보내면 같은 화면이 열립니다.

첫 자리로 보는 다섯 종류

자주 헷갈리는 짝

• 401과 403: 401은 "누구인지 모르겠다"(로그인 필요, 토큰 만료), 403은 "누구인지는 알지만 안 된다"(권한 없음, 차단)입니다. 이름과 달리 401 Unauthorized 가 인증 문제이고 403이 권한 문제입니다.
• 301과 302, 307과 308: 301과 308은 영구 이동, 302와 307은 임시 이동입니다. 307과 308은 POST 요청을 POST 그대로 다시 보내게 하고, 301과 302는 브라우저가 GET으로 바꿔 보내는 일이 있습니다.
• 400과 422: 400은 요청 자체가 깨진 경우(JSON 문법 오류), 422는 형식은 맞지만 값이 규칙에 어긋난 경우(이메일 형식 오류)에 씁니다.
• 404와 410: 둘 다 없다는 뜻이지만 410은 "일부러 지웠고 돌아오지 않는다"는 뜻이라 검색 엔진이 더 빨리 색인에서 뺍니다.
• 502, 503, 504: 앞단 서버(nginx, 로드 밸런서)와 뒤의 애플리케이션 서버 사이에서 생깁니다. 502는 뒤에서 잘못된 응답이 옴, 503은 받을 수 없는 상태, 504는 기다리다 시간 초과입니다.

로그에서 나온 코드 한 번에 찾기

로그에서 나온 코드 여러 개를 한 번에 찾기를 펼치고 접속 로그를 붙여 넣으면 줄마다 상태 코드를 뽑아 종류별로 세고, 나온 코드만 횟수가 많은 순서로 표에 보여 줍니다. nginx와 아파치의 기본 로그 형식(요청을 감싼 따옴표 바로 뒤의 숫자)을 알아보며, "200 301 404 404 502"처럼 숫자만 적어도 됩니다. 예시 버튼을 누르면 여섯 줄에서 코드 6개(5종류)를 찾아 404가 2회, 200, 301, 499, 502가 1회씩으로 나옵니다. 표에 없는 번호가 섞여 있으면 따로 알려 줍니다. 이 상태에서 보이는 표를 CSV로 저장하면 횟수 칸까지 함께 저장되어 장애 보고서에 붙이기 좋습니다.

오류를 만났을 때의 순서

방문자로서 오류 화면을 만났다면 첫 자리부터 봅니다. 4로 시작하면 주소를 다시 확인하고, 로그아웃 뒤 다시 로그인하고, 그 사이트의 쿠키를 지워 봅니다(400, 431은 쿠키가 원인인 경우가 많습니다). 5로 시작하면 내 쪽에서 할 수 있는 일이 거의 없으니 조금 기다렸다가 다시 시도합니다.

운영자라면 5xx는 화면이 아니라 로그에서 답을 찾습니다. 500은 애플리케이션의 오류 로그, 502와 504는 프록시의 오류 로그와 애플리케이션 프로세스의 상태, 503은 서버 자원과 동시 처리 한도를 확인합니다. 4xx가 갑자기 늘었다면 배포로 주소가 바뀌었는지(404), 인증 설정이 바뀌었는지(401, 403), 업로드 한도에 걸리는지(413)를 봅니다.

이 표의 기준

• 이름과 뜻은 HTTP 표준 문서(RFC 9110)와 IANA의 상태 코드 등록부를 따랐습니다. 413과 422는 RFC 9110에서 이름이 Content Too Large, Unprocessable Content 로 바뀌었고 옛 이름(Payload Too Large, Unprocessable Entity)도 여전히 널리 보입니다.
• 499(nginx)와 520~526(클라우드플레어)은 표준이 아니며 해당 제품에서만 뜻이 있습니다. 표에 "비표준"으로 표시했습니다.
• "흔한 원인"과 "해결"은 자주 만나는 경우를 추린 것이며 모든 원인을 담지는 못합니다. 같은 코드라도 서비스마다 쓰는 방식이 조금씩 다르니 응답 본문의 오류 메시지를 함께 보세요.