404 Not Found

사용법

404 Not Found 오류가 도착해도, 그 상태는 리소스가 영구적으로 사용 불가인지, 일시적으로 사용 불가인지, 아니면 애초에 존재한 적이 없는지를 명시하지 않습니다. 이 오류는 대개 잘못 입력한 URL에서 비롯되며, 아직 작업 중인 리소스 묶음을 다루는 개발자가 자주 마주칩니다.

404 Not Found를 반환하는 주소를 가리키는 링크는 흔히 죽은 링크 또는 깨진 링크라고 부릅니다. 이 상태는 서버가 어떤 리소스의 존재를 인정하고 싶지 않을 때 사용되기도 했습니다.

서버가 해당 주소에 리소스가 한때 존재했지만 영구적으로 제거되었음을 알고 있다면 410 Gone 상태가 더 많은 정보를 줍니다.

최종 사용자가 이 오류를 워낙 자주 보기 때문에, 많은 서버는 자기 사이트에 맞춰 설명이 충실하고 관련성 있는 맞춤 오류 페이지를 사용합니다.

참고

404는 클라이언트가 차단되었다는 뜻이 아닙니다. 차단되면 403 Forbidden이 나옵니다. 일부 서버는 리소스의 존재를 숨기기 위해 403 대신 404를 반환합니다. 404는 영구성을 나타내지 않습니다. 해당 리소스는 나중에 나타날 수도 있습니다. 영구 제거의 경우 서버는 410 Gone을 반환합니다.

SEO 영향

Google 같은 검색 엔진은 404 상태를 반환하는 URL을 색인하지 않습니다. 이전에 색인되었다가 이 상태 코드를 반환하는 URL은 검색 결과에서 제거됩니다. 이 코드를 반환하는 페이지는 크롤 예산을 낭비하지 않습니다. Google은 404와 410을 동일하게 처리합니다. 둘 다 같은 속도로 콘텐츠를 색인에서 제거합니다. Bingbot은 404를 콘텐츠 제거 신호로 간주하며, 이후 재크롤링에서 해당 상태를 확인한 뒤 그 URL의 색인을 해제합니다. 제대로 된 404 대신 오류 내용을 담은 200을 반환하면 소프트 404가 만들어지며, 이는 크롤 예산을 낭비하고 사이트의 서버 신호에 대한 신뢰를 떨어뜨립니다.

예시

클라이언트가 리소스를 요청하고, 지정된 주소에 그 리소스가 존재하지 않으므로 서버는 404 Not Found로 응답합니다.

요청

GET /documents/secret-formula.pdf HTTP/1.1
Host: example.com

응답

HTTP/1.1 404 Not Found
Content-Type: text/html
Content-Length: 216

<html>
  <head>
    <title>Resource Not Found</title>
  </head>
  <body>
    <p>The requested resource was not found.
    Check the spelling of the address.</p>
  </body>
</html>

해결 방법

404 Not Found는 요청한 주소에 어떤 리소스도 존재하지 않는다는 뜻입니다.

URL의 철자와 경로를 확인하세요. 경로, 파일명, 쿼리 문자열의 오타가 가장 흔한 원인입니다. 주소의 모든 구간을 꼼꼼히 대조하세요. 손으로 입력하지 말고 원본 링크에서 경로를 그대로 복사하세요.

대소문자 구분을 점검하세요. Linux 기반 서버는 /Page와 /page를 다른 경로로 취급합니다. 원래 URL의 대소문자를 정확히 맞추세요. Windows 기반 IIS 서버는 기본적으로 대소문자를 구분하지 않으므로, IIS에서의 404는 실제로 리소스가 없다는 뜻입니다.

끝 슬래시가 빠지지 않았는지 살펴보세요. 일부 서버는 /path와 /path/를 구분합니다. 끝 슬래시를 추가하거나 제거한 뒤 다시 시도하세요. nginx와 Apache는 try_files 및 DirectorySlash 설정에 따라 끝 슬래시를 다르게 처리합니다.

서버에 리소스가 존재하는지 확인하세요. 파일이나 라우트가 배포되어 접근 가능한지 검증하세요. SSH로 서버에 접속해 파일이 예상되는 문서 루트 경로에 있는지 확인하세요. nginx에서는 일치하는 location 블록의 root나 alias 지시문을 확인하세요. Apache에서는 가상 호스트의 DocumentRoot를 확인하세요.

이동한 콘텐츠에는 301 또는 308 리다이렉트를 설정하세요. 리소스가 새 주소로 옮겨지면 깨진 링크를 막기 위해 이전 URL을 리다이렉트하세요. nginx에서는 다음과 같습니다.

location = /old-path {
    return 301 /new-path;
}

Apache .htaccess에서는 다음과 같습니다.

Redirect 301 /old-path /new-path

서버의 재작성 규칙을 점검하세요. Apache의 mod_rewrite 규칙이나 nginx의 try_files 및 location 블록을 검토하세요. 잘못 설정된 재작성은 유효한 경로에 대한 요청을 조용히 버립니다. 규칙 평가 과정을 추적하려면 재작성 로깅을 켜세요. Apache에서는 LogLevel alert rewrite:trace3을 일시적으로 설정합니다.

IIS에서는 MIME 타입과 핸들러 매핑을 확인하세요. 파일 확장자에 등록된 MIME 타입이나 핸들러 매핑이 없으면 IIS는 404.3을 반환합니다. IIS 관리자에서 또는 web.config를 통해 누락된 MIME 타입을 추가하세요.

<staticContent>
  <mimeMap fileExtension=".json"
    mimeType="application/json" />
</staticContent>

DNS와 가상 호스트 설정을 점검하세요. 도메인이 잘못된 서버를 가리키거나 가상 호스트 항목이 없으면 모든 경로에서 404가 발생합니다. DNS의 A/CNAME 레코드가 올바른 서버 IP로 해석되는지, 그리고 서버에 일치하는 server_name(nginx)이나 ServerName(Apache) 지시문이 있는지 확인하세요.

크롤러로 깨진 링크를 감사하세요. 사이트 크롤러를 돌려 사이트 전체의 404 응답을 탐지하세요. 깨진 내부 링크를 고치고, 이동한 콘텐츠의 재색인을 앞당기기 위해 갱신된 XML 사이트맵을 검색 엔진에 제출하세요. 깨진 링크를 찾는 도구로는 Google Search Console(색인 생성 보고서), Screaming Frog, Ahrefs Site Audit, 또는 명령줄 확인용 wget —spider가 있습니다.

코드 참고

.NET

HttpStatusCode.NotFound

Rust

http::StatusCode::NOT_FOUND

Rails

:not_found

http.StatusNotFound

Symfony

Response::HTTP_NOT_FOUND

Python3.5+

http.HTTPStatus.NOT_FOUND

Java

java.net.HttpURLConnection.HTTP_NOT_FOUND

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_NOT_FOUND

Angular

@angular/common/http/HttpStatusCode.NotFound