404 Not Found 오류: 의미와 해결 방법

이 오류의 의미와 확인 방법

• 사이트의 다른 페이지는 로드되지만 특정 페이지에 404, Not Found 또는 사용자 지정 누락 페이지 메시지가 표시됩니다.
• 호스트 이름과 서버에 연결할 수 있는데도 API 요청이 404를 반환합니다.
• 배포, 마이그레이션, permalink 변경 또는 애플리케이션 업데이트 후 정상 작동하던 URL이 404를 반환하기 시작합니다.
• 검색 결과, 북마크 또는 내부 링크가 더 이상 사용할 수 없는 콘텐츠로 연결됩니다.
• 웹 서버, reverse proxy 또는 rewrite 설정을 변경한 후 서로 관련 없는 여러 경로가 실패합니다.

가능성이 높은 순서의 주요 원인

가능성이 높은 원인부터 낮은 원인 순서입니다.

1. 잘못 입력했거나 불완전한 URL: 철자 오류, 누락된 경로 구성 요소 또는 잘못된 대소문자로 인해 존재하지 않는 리소스를 가리킵니다.
2. 삭제되거나 이동된 콘텐츠: 관련 redirect 없이 페이지나 파일이 삭제, 이름 변경 또는 다른 위치로 이동되었습니다.
3. 손상된 내부 또는 외부 링크: 특히 마이그레이션이나 URL 구조 변경 후에도 링크가 이전 URL을 계속 참조합니다.
4. 애플리케이션 route 누락: 배포된 애플리케이션에 요청한 페이지 또는 API endpoint가 정의되어 있지 않거나, 경로에서 잘못된 API 버전 또는 prefix를 사용합니다.
5. 잘못된 rewrite 또는 permalink 규칙: Apache, Nginx, framework router 또는 CMS 설정이 유효한 경로를 의도한 handler로 전달하지 못합니다.
6. 배포 또는 document root 문제: 파일, route 또는 build output이 배포되지 않았거나, 서버가 예상과 다른 디렉터리를 제공하고 있습니다.
7. Reverse proxy 불일치: proxy 또는 gateway가 요청을 잘못된 애플리케이션이나 backend로 전달하여 해당 경로를 찾지 못합니다.
8. 대소문자를 구분하는 경로 차이: 한 환경에서 작동하는 URL도 대소문자가 route 또는 파일 이름과 일치하지 않으면 대소문자를 구분하는 파일 시스템이나 서버에서 실패할 수 있습니다.

해결 방법

사이트를 방문하는 경우

1. 철자, 대소문자, 하이픈, 파일 확장자 및 모든 경로 구성 요소를 포함하여 주소를 다시 확인하세요.
2. 의심스러운 마지막 경로 구성 요소를 제거하거나 사이트 홈페이지와 내장 검색에서 이동하여 현재 페이지를 찾으세요.
3. 북마크나 검색 결과를 통해 페이지에 접근했다면 동일한 URL을 반복해서 새로 고침하기보다 콘텐츠의 최신 버전을 찾아보세요.
4. 신뢰할 수 있는 링크가 손상된 경우 정확한 URL과 해당 링크를 발견한 페이지를 함께 사이트 소유자에게 신고하세요.

사이트를 관리하는 경우

1. 실패한 요청을 확인하세요. 정확한 경로, HTTP method, host, query string 및 실패 시간을 기록하세요. 문제가 하나의 URL, 하나의 route 계열 또는 사이트 전체에 영향을 주는지 확인하세요.
2. 리소스가 존재해야 하는지 판단하세요. 콘텐츠 레코드, 배포된 파일 또는 애플리케이션 route 정의를 확인하세요. 의도적으로 삭제한 리소스는 실제로 관련성 높은 대체 위치가 없는 한 일반적으로 404로 유지해야 합니다.
3. 실패하는 경로와 정상 작동하는 경로를 비교하세요. 대소문자, trailing slash, 파일 확장자, locale prefix, API 버전, route prefix 및 query 처리 방식의 차이를 확인하세요.
4. routing 및 rewrite 설정을 점검하세요. 애플리케이션 router, CMS permalink, 웹 서버 규칙, document root 및 reverse-proxy 매핑을 검토하세요. 현재 설정을 보존하고 다른 route에 미칠 영향을 고려한 후, 적절한 권한이 있을 때만 설정을 변경하세요.
5. 배포 상태를 확인하세요. 예상한 파일, build output, route 및 정적 asset이 배포된 release에 포함되었고 활성 서버가 의도한 release를 사용하고 있는지 확인하세요.
6. 로그를 검토하세요. 웹 서버, proxy 및 애플리케이션 로그를 사용하여 어떤 구성 요소가 404를 생성했는지와 요청이 예상한 backend에 도달했는지 확인하세요. 로그를 공유하기 전에 자격 증명, token 및 개인정보를 삭제하거나 비식별화하세요.
7. 링크 또는 redirect를 수정하세요. 내부 링크를 현재 경로로 업데이트하세요. 콘텐츠가 영구적으로 이동했다면 권한이 부여된 영구 redirect를 가장 가까운 동등한 대상에 설정하세요. 관련 없는 누락 URL을 홈페이지로 redirect하지 마세요.
8. 오류 응답을 확인하세요. 원래 누락된 URL을 요청하고 HTTP 상태 404를 반환하는지 확인하세요. 사용자 지정 오류 페이지가 유용할 수 있지만, 누락된 리소스를 오해를 유발하는 성공적인 200 응답으로 바꾸어서는 안 됩니다.
9. 영향을 받은 경로를 다시 테스트하세요. 변경 후 원래 URL, 대체 URL(있는 경우), 대표적인 정상 작동 route 및 관련 API method를 확인하세요. 이후 404 로그를 모니터링하여 남아 있는 손상된 링크를 확인하세요.

예방 및 해결 확인 방법

• 마이그레이션, redesign 및 URL 구조 변경 전후에 broken-link 검사를 실행하세요.
• 영구적으로 이동하는 중요한 콘텐츠에는 문서화된 redirect를 유지하세요.
• 각 배포의 일부로 대표적인 페이지, asset 및 API route를 테스트하세요.
• 경로의 대소문자, trailing slash, locale prefix 및 API 버전을 명시적인 routing 결정으로 다루세요.
• 웹 서버, reverse proxy 및 애플리케이션 routing 설정을 변경 관리 대상으로 유지하세요.
• 자주 요청되는 404 경로를 모니터링하여 손상된 내부 링크, 오래된 연동 및 반복되는 사용자 요청을 파악하세요.
• 계속 제공하거나 색인되어야 하는 콘텐츠에는 안정적인 URL을 유지하세요.
• 사용자 지정 오류 템플릿이 올바른 HTTP 상태를 유지하도록 하세요.

자주 묻는 질문