HTTP 404 Not Found — 페이지를 찾을 수 없음 에러 원인·해결·예방

HTTP 404 Not Found — 페이지를 찾을 수 없음 에러 원인·해결·예방

웹을 쓰다 보면 누구나 한 번쯤 "404 Not Found" 또는 "페이지를 찾을 수 없습니다" 화면을 만난다. 404는 서버에는 정상적으로 연결됐지만, 요청한 주소에 해당하는 자원이 없을 때 돌아오는 응답이다. 즉 "길은 찾았는데 그 집이 없다"는 신호다.

 

이 글은 404를 사용자 입장과 사이트 운영자·개발자 입장 양쪽에서 정리한다. 에러의 정확한 의미, 자주 나오는 원인, 재현과 서버 설정 코드 예제, 단계별 진단·해결, 그리고 SEO 관점의 예방까지 한 번에 다룬다.

HTTP 404 Not Found

 

이 글의 구성

 

01404 에러 메시지와 의미

02자주 나오는 발생 원인 5가지

03재현 시나리오와 서버 설정 코드

04해결 방법과 단계별 진단

05인접 에러 비교와 SEO 처리

Q&A자주 묻는 질문 5가지

---

01 404 에러 메시지와 의미

404는 HTTP 응답 상태 코드 가운데 4xx, 즉 클라이언트 측 오류로 분류된다. 서버가 요청을 받긴 했지만 해당 경로의 자원을 찾지 못했다는 뜻이다. 서버 자체가 죽은 5xx와는 다르다.

항목	내용
상태 코드	404
영문 메시지	Not Found
한글 의미	요청한 페이지·자원을 찾을 수 없음
분류	4xx 클라이언트 오류
책임 소재	주소(요청) 또는 서버의 경로 설정

여기서 핵심은 "클라이언트 오류"라는 분류가 꼭 사용자 잘못을 뜻하지는 않는다는 점이다. 주소를 잘못 입력한 경우도 있지만, 운영자가 페이지를 옮기거나 지우고 링크를 정리하지 않아서 발생하는 경우도 많다.

핵심 관찰 — 연결은 됐고, 자원이 없을 뿐

404가 떴다는 것은 DNS 해석과 서버 연결까지는 성공했다는 의미다. 따라서 인터넷 자체가 끊긴 문제가 아니라, 특정 주소(경로)에 해당하는 파일·라우트가 없다는 좁은 문제다. 진단 범위를 "경로"로 좁히는 것이 첫걸음이다.

---

02 자주 나오는 발생 원인 5가지

원인 1 — 주소(URL) 오타·잘못된 링크

가장 단순한 경우다. 주소의 철자, 끝 슬래시 유무, 대소문자가 실제 경로와 다르면 404가 난다. 리눅스 서버는 대소문자를 구분하므로 Page.html과 page.html은 다른 자원으로 취급된다. 윈도우·맥 로컬에서는 대소문자를 구분하지 않아 잘 열리던 페이지가, 리눅스 서버에 배포한 뒤 404가 나는 일이 자주 생기는 이유다.

원인 2 — 페이지 삭제·이동 후 링크 미정리

콘텐츠를 옮기거나 지웠는데 기존 주소로 들어오는 링크·북마크·검색 결과가 그대로 남아 있는 경우다. 운영자가 리다이렉트를 걸지 않으면 방문자는 404를 만난다.

원인 3 — 서버 라우팅·리라이트 설정 오류

Nginx·Apache의 location·rewrite 규칙이 잘못됐거나, 백엔드 프레임워크의 라우트가 등록되지 않으면 실제 파일·핸들러가 있어도 404가 난다. 정적 파일 루트(document root) 경로가 어긋난 경우도 흔하다.

원인 4 — SPA 새로고침 시 404

React·Vue 같은 단일 페이지 앱(SPA)은 클라이언트에서 라우팅을 처리한다. 첫 화면은 잘 뜨지만 하위 경로에서 새로고침하면 서버가 그 경로의 실제 파일을 찾다가 404를 낸다. 모든 경로를 index.html로 돌려주는 설정이 없을 때 생긴다.

원인 5 — 배포 누락·캐시·일시적 전파 지연

새 파일이 서버에 올라가지 않았거나, CDN·브라우저 캐시가 옛 경로를 기억하고 있거나, 배포 직후 전파가 끝나지 않은 짧은 시간 동안 404가 보일 수 있다. 빌드 산출물 경로가 바뀐 경우도 포함된다.

---

03 재현 시나리오와 서버 설정 코드

먼저 404 응답이 실제로 어떤 모습인지 본다. 서버는 상태 줄에 404를 담아 응답한다.

# 요청
GET /old-page.html HTTP/1.1
Host: example.com

# 응답
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=UTF-8

SPA에서 가장 자주 겪는 "새로고침 404"는 Nginx에서 try_files로 해결한다. 실제 파일이 없으면 index.html로 넘겨 클라이언트 라우터가 처리하게 한다.

# ✗ 문제: 하위 경로 새로고침 시 404
location / {
    root /var/www/app;
}

# ✓ 해결: 파일이 없으면 index.html로 폴백
location / {
    root /var/www/app;
    try_files $uri $uri/ /index.html;
}

# 커스텀 404 페이지 지정
error_page 404 /404.html;

Apache(.htaccess) 환경에서는 ErrorDocument로 안내 페이지를 지정하고, 옮겨진 페이지는 301 리다이렉트로 연결한다.

# 커스텀 404 안내 페이지
ErrorDocument 404 /404.html

# ✓ 옮겨진 페이지는 영구 이동(301)으로 연결
Redirect 301 /old-page.html /new-page.html

---

04 해결 방법과 단계별 진단

해결은 "누가 보느냐"에 따라 갈린다. 방문자라면 주소·캐시를, 운영자라면 경로·라우팅·로그를 본다.

입장	해결 방법
방문자	주소 철자·슬래시·대소문자 확인, 새로고침, 캐시·쿠키 삭제, 사이트 검색으로 재접근
운영자	서버 액세스·에러 로그 확인, 라우팅·document root 점검, 파일 배포 여부 확인
SPA 앱	try_files·history fallback로 모든 경로를 index.html로 연결
이전된 URL	301 리다이렉트로 새 주소에 연결, 커스텀 404 페이지 제공

단계별 진단 절차

01주소를 그대로 다시 확인한다. 철자·끝 슬래시·대소문자가 실제 경로와 같은지 본다.

02다른 페이지는 열리는지 확인한다. 사이트 전체가 안 되면 404가 아니라 다른 문제다.

03운영자라면 서버 에러 로그에서 어떤 경로가 404로 찍히는지 확인한다.

04해당 파일·라우트가 실제로 서버에 존재하는지, document root 경로가 맞는지 본다.

05SPA·이전 URL이면 try_files 폴백 또는 301 리다이렉트를 적용하고 캐시를 비운다.

---

05 인접 에러 비교와 SEO 처리

404는 비슷한 코드들과 헷갈리기 쉽다. 의미를 구분하면 대응이 달라진다.

코드	의미	대응
404	자원 없음(일시적일 수도)	경로 확인·리다이렉트
410	영구 삭제(다시 안 옴)	의도적 제거 시 명시
403	자원은 있으나 접근 금지	권한·인증 확인
soft 404	내용은 없는데 200으로 응답	실제 404 코드로 교정

SEO 관점에서 특히 조심할 것이 soft 404다. 페이지가 없는데도 서버가 200(정상)으로 응답하면, 검색엔진은 빈 페이지를 정상 페이지로 오해해 색인 품질이 떨어진다. 없는 페이지는 정직하게 404(또는 영구 삭제면 410)를 반환하고, 옮긴 페이지는 301로 연결하는 것이 원칙이다.

“

404는 고장이 아니라 약속이다. 없는 것을 없다고 정확히 알려주는 것, 옮긴 것은 새 자리로 안내하는 것이 좋은 사이트의 기본이다.

 

— soft 404를 피하고 301로 연결하라

---

06 자주 묻는 질문 5가지

Q1404가 뜨면 인터넷이 끊긴 건가요?

아닙니다. 404는 서버까지 정상적으로 연결된 뒤 돌아오는 응답입니다. 인터넷 연결 자체가 문제라면 404가 아니라 연결 실패(ERR_CONNECTION 계열)나 DNS 오류가 뜹니다.

Q2새로고침하면 404, 처음엔 정상인데 왜 그런가요?

SPA에서 흔한 증상입니다. 첫 진입은 클라이언트 라우터가 처리하지만, 하위 경로에서 새로고침하면 서버가 그 경로의 실제 파일을 찾다가 404를 냅니다. try_files로 index.html에 폴백시키면 해결됩니다.

Q3404와 403은 어떻게 다른가요?

404는 자원이 없을 때, 403은 자원은 있지만 접근 권한이 없을 때입니다. 보안상 자원의 존재를 숨기려고 일부러 403 대신 404를 반환하기도 합니다.

Q4404가 SEO에 나쁜가요?

404 자체는 정상적인 응답이라 그 존재만으로 페널티는 아닙니다. 문제는 없는 페이지를 200으로 응답하는 soft 404이거나, 중요한 페이지가 통째로 404가 되는 경우입니다. 옮긴 페이지는 301로 연결해야 평가가 이어집니다.

Q5커스텀 404 페이지는 꼭 만들어야 하나요?

필수는 아니지만 권장됩니다. 방문자가 길을 잃지 않도록 홈·검색·인기 글 링크를 담은 안내 페이지를 제공하면 이탈을 줄일 수 있습니다. 단, 안내 페이지를 보여주더라도 응답 코드는 404를 유지해야 합니다.

---

07 결론

404는 웹에서 가장 흔한 에러이면서, 가장 오해받는 에러이기도 하다. 인터넷이 끊긴 것도, 사이트가 죽은 것도 아니다. 단지 요청한 주소에 자원이 없다는 좁고 명확한 신호다.

실무 원칙은 다음과 같다.

첫째, 진단 범위를 "경로"로 좁힌다. 다른 페이지가 열린다면 문제는 그 주소 하나다.

둘째, 옮기거나 지운 페이지는 반드시 처리한다. 이동은 301, 영구 삭제는 410으로 명시하고, 없는 페이지를 200으로 응답하는 soft 404는 피한다.

셋째, SPA·서버 설정은 폴백을 미리 깔아둔다. try_files 한 줄이 새로고침 404를 막는다.

404 트러블슈팅 체크리스트

 

01주소 철자·슬래시·대소문자가 실제 경로와 일치하는지 확인.

02다른 페이지 정상 여부로 404인지 사이트 전체 장애인지 구분.

03서버 에러 로그에서 404로 찍히는 정확한 경로 확인.

04파일·라우트 존재와 document root·라우팅 규칙 점검.

05SPA는 try_files 폴백, 이전 URL은 301 리다이렉트 적용.

06soft 404 여부 점검 — 없는 페이지는 정직하게 404 코드 반환.

07방문자 이탈을 줄이는 커스텀 404 안내 페이지 제공.

---

본 글은 HTTP 404 Not Found 에러의 일반적 원인과 해결 방법을 정리한 자료다. 서버 설정 변경은 운영 환경에 적용하기 전 테스트 환경에서 충분히 검증한다.

 

#404 #NotFound #HTTP에러 #HTTP상태코드 #404에러해결 #페이지를찾을수없음 #soft404 #301리다이렉트 #Nginx #Apache #SPA라우팅 #웹개발 #서버에러 #SEO #트러블슈팅