404 오류가 특정 파일에서만 발생하는 이유 9가지와 점검 순서

사이트 전체는 정상인데 이미지 한 장, 스크립트 하나에서만 붉은 줄이 뜨는 경우가 있습니다. 전체가 안 열리는 상황이라면 서버나 도메인을 의심하겠지만, 404 오류가 특정 파일에서만 나온다면 원인은 훨씬 좁은 곳에 있습니다.

404는 서버가 요청을 정상적으로 받았지만 그 경로에 해당하는 자원을 찾지 못했다는 응답입니다. 즉 연결과 권한에는 문제가 없고, 경로 또는 파일 존재 여부만 어긋난 상태입니다. 이 글은 특정 파일에서만 404 오류가 생기는 대표 원인을 나누고, 서버에 접속하지 않고도 범위를 좁히는 순서를 정리합니다.

404 오류가 뜻하는 것과 뜻하지 않는 것

404는 “요청은 받았고 처리도 했지만 해당 자원이 없다”는 의미입니다. 서버가 멈춰 있거나 도메인이 잘못되었다면 애초에 이 코드가 돌아오지 않습니다. 따라서 404 오류가 보인다는 사실 자체가 서버는 살아 있다는 증거입니다.

권한 문제와도 구분해야 합니다. 파일이 있지만 읽을 권한이 없으면 보통 403이 반환됩니다. 다만 보안 설정에 따라 존재 여부를 숨기려고 403 대신 404를 돌려주는 서버도 있어, 두 경우가 겹칠 수 있다는 점은 염두에 두는 편이 좋습니다.

서버 로그에는 404가 남습니다. 요청이 서버까지 도달했기 때문입니다. 로그에 기록이 없다면 브라우저가 요청을 만들지 않았거나 중간에서 차단된 것이므로 다른 문제로 봐야 합니다.

응답	뜻	서버에 파일이 있는가	확인할 곳
404 Not Found	요청한 주소에 해당하는 자원이 없음	대부분 없음	요청 URL과 문서 루트
403 Forbidden	자원은 있으나 접근이 막힘	있음	권한과 소유자 설정
410 Gone	예전에 있었고 의도적으로 없앰	없음	리다이렉션 규칙
200이지만 빈 화면	응답은 성공, 본문이 비어 있음	있음	Response 탭의 본문
(failed)	서버까지 닿지 못함	판단 불가	도메인과 네트워크

가정 예시 — 실제 응답은 서버 설정에 따라 달라질 수 있음

표에서 보듯 404 오류는 “주소에 맞는 자원이 없다”는 뜻이지 “파일이 서버에 없다”는 뜻이 아닙니다. 파일은 그대로 있는데 서버가 그 주소를 다른 곳으로 해석하고 있는 경우가 상당히 많습니다.

그래서 확인 순서는 파일 존재 여부가 아니라 주소 해석 과정부터 시작하는 편이 빠릅니다. 서버가 어떤 경로를 실제로 찾아갔는지 알면 404 오류의 원인이 대부분 드러납니다.

경로 대소문자 불일치

가장 많이 나오는 원인입니다. 윈도우와 맥은 파일 이름의 대소문자를 구분하지 않지만, 대부분의 리눅스 서버는 구분합니다. 로컬에서 Logo.png로 저장한 파일을 코드에서 logo.png로 부르면, 개발 환경에서는 열리고 서버에서만 404 오류가 납니다.

이 유형은 특정 파일에서만 발생한다는 특징이 뚜렷합니다. 다른 이미지들은 이름이 일치해서 정상이고, 문제가 된 한 장만 실패합니다. 요청 주소를 복사해 서버의 실제 파일 이름과 한 글자씩 대조하면 바로 확인됩니다.

예방하려면 파일 이름을 처음부터 소문자와 하이픈만 쓰는 규칙으로 통일하는 방법이 있습니다. 공백과 한글, 대문자가 섞이면 배포 환경이 바뀔 때마다 같은 문제가 반복됩니다.

배포에서 누락된 파일

빌드 결과물 중 일부만 업로드되는 상황도 흔합니다. 업로드 도구의 제외 규칙에 특정 확장자가 걸려 있거나, 전송 중 연결이 끊겨 일부 파일이 빠진 경우입니다. 폰트나 소스맵처럼 눈에 덜 띄는 파일에서 자주 나타납니다.

확인은 간단합니다. 서버의 해당 폴더 목록과 로컬 폴더 목록을 나란히 비교하면 됩니다. 파일 개수만 세어 봐도 누락 여부가 드러나는 경우가 많습니다.

버전 관리 도구에서 무시 규칙에 걸려 있는 파일도 자주 빠집니다. 빌드 산출물 폴더가 통째로 제외되어 있으면 저장소에는 없고 로컬에만 존재하게 되어, 배포 서버에서는 404 오류가 발생합니다.

파일이 정말로 올라갔는지 확인할 때는 브라우저 대신 헤더만 받아 보는 방식이 확실합니다. 아래 명령은 본문을 받지 않고 응답 코드만 확인합니다.

snippetCODE

1
2

curl -I https://example.com/assets/app.js
curl -I https://example.com/assets/App.js

두 명령의 결과가 다르다면 대소문자 처리 방식이 원인입니다. 둘 다 404 오류가 나온다면 배포 자체가 누락되었을 가능성이 큽니다.

브라우저는 캐시와 확장 프로그램의 영향을 받지만 이 방식은 서버 응답만 그대로 보여 줍니다. 배포 직후에 한 번 실행해 두면 나중에 원인을 찾는 시간이 크게 줄어듭니다.

상대 경로와 절대 경로의 혼동

슬래시로 시작하는 절대 경로는 항상 사이트 최상위를 기준으로 삼습니다. 슬래시 없이 적은 상대 경로는 현재 문서의 위치를 기준으로 계산됩니다. 같은 코드라도 페이지가 놓인 깊이에 따라 실제 요청 주소가 달라집니다.

목록 페이지에서는 정상인데 상세 페이지에서만 404 오류가 난다면 이 유형일 가능성이 큽니다. 개발자 도구에서 실패한 요청의 전체 주소를 확인하면, 의도하지 않은 폴더가 중간에 끼어 있는 것이 보입니다.

하위 폴더에 설치된 사이트에서 특히 자주 겪습니다. 최상위 기준으로 적은 절대 경로가 하위 폴더를 건너뛰기 때문입니다. 이 경우 사이트 주소를 기준으로 경로를 만들어 주는 함수를 쓰는 편이 안전합니다.

리라이트 규칙과 퍼머링크

워드프레스처럼 주소를 재작성하는 시스템에서는 규칙이 깨지면 특정 유형의 주소만 404가 됩니다. 첫 화면은 열리는데 개별 글 주소에서만 실패하는 형태가 대표적입니다.

이때는 퍼머링크 설정을 한 번 다시 저장하면 규칙 파일이 새로 생성되어 해결되는 경우가 많습니다. 서버가 재작성 모듈을 지원하지 않거나 설정 파일을 읽지 못하는 환경이라면 서버 설정을 직접 확인해야 합니다.

규칙 문제는 파일 하나가 아니라 주소 패턴 전체에 영향을 줍니다. 실패하는 주소들이 공통된 형태를 갖고 있다면 개별 파일이 아니라 규칙 쪽을 먼저 보는 편이 빠릅니다.

캐시와 CDN이 만들어 내는 404

파일을 새로 올렸는데도 404 오류가 계속된다면 앞단 캐시가 “없음”이라는 결과를 저장하고 있을 수 있습니다. 일부 CDN은 실패 응답도 짧게 캐시하므로, 파일을 올린 직후 잠깐 동안 같은 결과가 이어집니다.

반대로 파일을 지웠는데 계속 열리는 경우도 같은 원리입니다. 배포 후에는 해당 경로를 무효화해 앞단 캐시를 갱신하는 절차를 함께 수행하는 편이 좋습니다.

브라우저 캐시도 영향을 줍니다. Disable cache를 켜고 다시 요청해 결과가 달라지는지 확인하면, 캐시 문제인지 서버 문제인지 갈라낼 수 있습니다.

확장자와 서버 설정

서버가 특정 확장자를 아예 서비스하지 않도록 설정된 경우도 있습니다. 보안상 실행 파일이나 설정 파일 확장자를 차단하는 규칙이 기본으로 들어가 있는 호스팅이 많습니다.

글꼴 파일이나 새로 등장한 형식의 확장자는 서버가 인식하지 못해 문제가 되기도 합니다. 이 경우 404 오류 대신 다운로드가 되거나 빈 응답이 오기도 하므로, 응답 헤더의 형식 표기를 함께 확인하는 편이 좋습니다.

업로드 폴더에 직접 접근을 막는 규칙이 걸려 있으면 그 폴더의 모든 파일에서 같은 결과가 나옵니다. 실패한 파일들이 한 폴더에 몰려 있다면 폴더 단위 규칙을 의심하십시오.

동적으로 만들어지는 주소에서 생기는 404

스크립트가 문자열을 조합해 주소를 만드는 경우, 조건에 따라 값이 비거나 undefined가 끼어들 수 있습니다. 이렇게 만들어진 주소는 서버 입장에서 존재하지 않는 경로이므로 404 오류로 처리됩니다.

실패한 요청의 주소를 그대로 읽어 보면 이런 유형은 금방 눈에 띕니다. 폴더 이름 자리에 빈 칸이 있거나 슬래시가 두 번 연속으로 들어가 있으면 조합 과정에 문제가 있다는 뜻입니다.

사용자 입력이나 서버에서 받은 값을 그대로 경로에 붙이는 코드는 특히 주의가 필요합니다. 값이 없을 때의 기본 동작을 정해 두지 않으면, 특정 조건에서만 404 오류가 나타나 재현이 어려워집니다.

주소를 바꿀 때 함께 준비할 것

글 주소 구조를 바꾸거나 카테고리를 정리하면 기존 주소는 모두 404가 됩니다. 검색 결과와 외부 링크는 여전히 옛 주소를 가리키므로, 새 주소로 연결해 주는 규칙을 함께 만들어 두어야 합니다.

연결 규칙은 영구 이동임을 명확히 알리는 방식으로 설정하는 편이 좋습니다. 그래야 검색 엔진이 새 주소를 기준으로 색인을 갱신하고, 기존 주소가 쌓아 둔 평가도 이어집니다.

변경 후에는 실제로 옛 주소가 새 주소로 넘어가는지 몇 개를 직접 열어 확인합니다. 규칙 순서가 꼬여 일부만 동작하는 경우가 자주 있습니다.

사이트맵도 함께 갱신해야 합니다. 옛 주소가 남아 있는 사이트맵을 제출하면 검색 엔진이 계속 404 오류를 만나게 되어 색인 처리가 늦어집니다.

주소를 정리할 때는 바꾸는 작업보다 예전 주소를 처리하는 작업이 더 중요합니다. 아래 항목을 함께 준비해 두면 이후에 생기는 404 오류를 크게 줄일 수 있습니다.

예전 주소와 새 주소를 짝지은 목록
목록을 반영한 이동 규칙과 적용 위치
사이트맵 재생성과 재제출 시점
본문과 메뉴에 남아 있는 예전 주소 검색 결과
변경 이후 일정 기간의 로그 확인 계획

목록을 만들어 두면 규칙이 몇 건인지, 어디까지 반영했는지 눈으로 확인할 수 있습니다. 규칙을 한꺼번에 넣기보다 몇 건씩 나누어 적용하고 결과를 확인하는 편이 안전합니다.

404 페이지 자체를 점검하는 방법

없는 주소를 요청했을 때 사이트가 실제로 404 상태 코드를 돌려주는지 확인이 필요합니다. 화면에는 “페이지를 찾을 수 없습니다”라고 표시하면서 상태 코드는 200으로 응답하는 사이트가 의외로 많습니다.

이 경우 검색 엔진은 그 페이지를 정상 페이지로 인식해 색인에 담습니다. 내용이 없는 페이지가 대량으로 색인되면 사이트 전체 평가에 도움이 되지 않습니다.

확인은 개발자 도구에서 아무 주소나 임의로 입력해 요청한 뒤 Status 열을 보면 됩니다. 200이 표시된다면 테마나 서버 설정에서 상태 코드를 바로잡아야 합니다.

404 페이지를 점검할 때 함께 확인할 것은 응답 코드입니다. 화면에는 “페이지를 찾을 수 없습니다”라고 적혀 있는데 실제 응답은 200으로 나가는 구성이 의외로 흔합니다.

이 경우 검색엔진은 그 주소를 정상 페이지로 인식합니다. 사람이 보는 화면과 기계가 받는 응답이 어긋나 있으므로, 404 오류 화면은 반드시 404 응답과 함께 나가도록 맞춰야 합니다.

안내 문구에는 돌아갈 수 있는 경로를 함께 두는 편이 좋습니다. 홈으로 가는 링크와 검색 창만 있어도 이탈이 눈에 띄게 줄어듭니다.

호스팅 환경별로 달라지는 확인 지점

공유 호스팅에서는 서버 설정 파일에 직접 손대기 어려운 경우가 많습니다. 이때는 관리 패널에서 제공하는 파일 관리자와 오류 로그 화면을 활용해 404 오류의 발생 시각과 요청 경로를 확인합니다.

클라우드 환경이라면 앞단에 로드 밸런서나 오브젝트 스토리지가 놓여 있는 경우가 많습니다. 정적 파일을 스토리지에서 서비스한다면 파일 권한이 공개로 설정되어 있는지, 경로 규칙이 맞는지 함께 확인해야 합니다.

컨테이너로 배포하는 환경에서는 이미지 안에 파일이 포함되었는지가 관건입니다. 로컬에서는 폴더가 연결되어 보이지만 실제 이미지에는 빠져 있어 배포 후에만 404 오류가 나타나는 사례가 흔합니다.

어느 환경이든 확인 순서는 같습니다. 요청 주소를 그대로 열어 보고, 서버의 실제 경로와 대조하고, 앞단 캐시를 걷어 낸 뒤 다시 확인하는 세 단계면 원인 대부분이 드러납니다.

호스팅 환경	주소 해석을 담당하는 곳	404 오류가 자주 생기는 지점	확인 방법
공유 호스팅	.htaccess	규칙 우선순위 충돌	파일을 잠시 비우고 비교
VPS·전용 서버	Nginx server 블록	location 순서	설정 문법 검사 후 재적용
컨테이너 배포	이미지에 포함된 파일 목록	빌드 단계 누락	컨테이너 안에서 경로 직접 확인
정적 호스팅	서비스의 라우팅 설정	새로 고침 시 경로 처리	대체 문서 설정 확인
워드프레스	퍼머링크 설정	규칙이 저장되지 않음	설정 화면에서 다시 저장

가정 예시 — 실제 설정 항목은 서비스와 버전에 따라 다름

환경이 다르면 같은 404 오류라도 확인해야 할 파일이 달라집니다. 어느 계층이 주소를 해석하는지부터 정하면 불필요한 설정 파일을 뒤지지 않아도 됩니다.

환경을 옮기는 작업을 했다면 옮기기 전 설정과 옮긴 뒤 설정을 나란히 비교해 두는 편이 좋습니다. 같은 파일을 그대로 복사해도 주소를 해석하는 계층이 달라지면 404 오류가 새로 생길 수 있습니다.

특히 정적 호스팅으로 옮긴 경우에는 화면 안에서 이동할 때는 정상인데 새로 고침만 하면 실패하는 형태가 자주 나타납니다. 이때는 파일이 아니라 대체 문서 설정을 확인해야 합니다.

404 오류를 좁히는 점검 순서

아래 순서는 위에서부터 차례대로 확인하도록 정리한 것입니다. 앞 단계에서 원인이 드러나면 뒤 단계는 건너뛰어도 됩니다.

1단계 · 실패한 주소를 그대로 복사해 확인

개발자 도구에서 실패한 요청의 주소를 복사해 주소창에 그대로 붙여 넣습니다. 이때 정상적으로 열린다면 파일이 아니라 그 주소를 만든 코드 쪽에 문제가 있습니다.

주소창에서도 404 오류가 나온다면 서버가 그 경로를 찾지 못한 것이므로 다음 단계로 넘어갑니다.

2단계 · 대소문자와 보이지 않는 문자 확인

리눅스 계열 서버는 대소문자를 구분합니다. 파일 이름을 직접 복사해 비교하면 눈으로 놓치기 쉬운 차이를 찾을 수 있습니다.

주소에 공백이나 한글이 섞여 있으면 인코딩 과정에서 경로가 달라지기도 합니다.

3단계 · 문서 루트 기준으로 경로 계산

서버가 기준으로 삼는 폴더가 어디인지 확인합니다. 문서 루트가 예상과 다르면 파일이 있어도 서버는 다른 폴더를 찾습니다.

설정 파일에 적힌 경로와 실제 배포 경로를 나란히 놓고 비교하면 차이가 바로 보입니다.

4단계 · 주소 재작성 규칙 비활성화 후 비교

리라이트 규칙을 잠시 꺼 놓고 같은 주소를 요청해 봅니다. 규칙을 껐을 때 정상이라면 원인은 규칙의 순서나 조건입니다.

워드프레스라면 퍼머링크 설정 화면에서 저장만 다시 눌러도 규칙이 새로 만들어집니다.

5단계 · 캐시와 CDN 우회

앞단 캐시가 예전 404 응답을 그대로 들고 있는 경우가 있습니다. 캐시를 비우거나 원본 서버에 직접 요청해 결과를 비교합니다.

원본은 정상인데 앞단만 404 오류를 준다면 캐시 무효화가 필요한 상황입니다.

6단계 · 서버 로그에서 실제 경로 확인

접근 로그에는 서버가 실제로 찾아간 경로가 남습니다. 요청 주소와 로그의 경로가 다르다면 그 사이에서 주소가 바뀐 것입니다.

로그에 요청 자체가 남지 않는다면 요청이 서버에 닿기 전에 처리된 것이므로 앞단 구성을 확인해야 합니다.

내 상황에 맞는 404 오류 판단 기준

한 파일만 실패한다 — 이름 대소문자와 오타, 배포 누락을 먼저 봅니다.
한 폴더의 파일이 모두 실패한다 — 폴더 접근 규칙이나 업로드 누락입니다.
특정 주소 패턴만 실패한다 — 리라이트 규칙과 퍼머링크 설정을 확인합니다.
페이지 깊이에 따라 달라진다 — 상대 경로와 절대 경로 혼동입니다.
올렸는데도 계속 실패한다 — 앞단 캐시가 실패 결과를 들고 있을 수 있습니다.

404 오류를 확인하는 5단계 체크리스트

실패한 요청의 전체 주소를 복사합니다. 눈으로 읽지 말고 그대로 복사해야 오타가 보입니다.
그 주소를 새 탭에 직접 붙여 넣어 엽니다. 여기서도 404면 서버 경로 문제입니다.
서버의 실제 파일 이름과 한 글자씩 대조합니다. 대소문자와 확장자를 특히 유의합니다.
같은 폴더의 다른 파일을 열어 봅니다. 그것도 실패하면 폴더 단위 문제입니다.
Disable cache를 켜고 다시 확인합니다. 결과가 바뀌면 캐시가 원인입니다.

404 오류에서 흔히 생기는 오해 3가지

첫 번째, 서버가 다운됐다고 보는 시각입니다. 404는 서버가 정상 동작 중이라는 증거입니다. 서버가 멈췄다면 502나 연결 실패가 나옵니다.

두 번째, 파일을 다시 올리면 무조건 해결된다는 생각입니다. 경로 자체가 틀렸다면 몇 번을 올려도 같은 결과가 나옵니다. 요청 주소와 실제 경로를 먼저 대조해야 합니다.

세 번째, 404 페이지를 예쁘게 만들면 문제가 해결된다는 판단입니다. 사용자 경험은 나아지지만 원인은 그대로입니다. 자원 파일의 404 오류는 화면 깨짐으로 이어지므로 반드시 원인을 찾아야 합니다.

덧붙이면 404 오류가 몇 건 있다고 해서 곧바로 순위가 떨어지는 것은 아닙니다. 다만 예전에 유입이 있던 주소가 오래 방치되면 그만큼의 유입이 사라지므로, 건수보다 어떤 주소가 실패하고 있는지를 보는 편이 실질적입니다.

404 오류 자주 묻는 질문

서버에 파일이 분명히 있는데 404가 납니다

요청 주소가 그 파일을 가리키지 않는 경우입니다. 문서 최상위 폴더가 어디로 설정되어 있는지, 요청 주소에 하위 폴더가 빠지거나 더해지지는 않았는지 확인해 보십시오.

이미지만 404가 나고 CSS는 정상입니다

업로드 폴더 접근 규칙이나 이미지 최적화 플러그인이 원인인 경우가 많습니다. 원본 경로를 직접 열어 결과를 비교해 보면 구분됩니다.

검색 결과로 들어오면 404가 뜹니다

주소 구조를 바꾼 뒤 예전 주소를 처리하지 않은 상황입니다. 새 주소로 연결해 주는 규칙을 추가하면 방문자 이탈과 색인 손실을 함께 줄일 수 있습니다.

404가 검색 순위에 얼마나 영향을 주나요

존재하지 않는 페이지에 404를 돌려주는 것은 정상 동작입니다. 다만 중요한 페이지가 404로 바뀌면 색인에서 빠지므로, 주소를 바꿀 때는 연결 규칙을 함께 준비하는 편이 좋습니다.

로그에서 404를 한 번에 모아 볼 수 있나요

서버 접근 로그에서 상태 코드 열을 기준으로 걸러 내면 됩니다. 검색 도구의 색인 보고서에서도 발견된 404 목록을 확인할 수 있습니다.

플러그인을 지웠더니 404가 늘었습니다

플러그인이 제공하던 파일을 테마나 다른 코드가 계속 참조하고 있기 때문입니다. 실패한 요청의 Initiator를 확인해 참조하는 쪽을 정리해야 합니다.

배포할 때마다 다른 파일에서 404가 납니다

빌드 결과에 해시가 붙는 구조라면 예전 파일을 참조하는 화면이 남아 있을 수 있습니다. 캐시된 HTML이 옛 파일 이름을 들고 있는 경우가 대표적입니다.

404 페이지가 아니라 빈 화면이 나옵니다

서버가 404 응답과 함께 본문을 비워 보내는 설정입니다. 응답 코드는 404 오류인데 화면만 비어 보이므로 개발자 도구에서 상태 코드를 확인해야 합니다.

검색엔진에 등록된 주소만 404가 납니다

주소 구조를 바꾼 뒤 예전 주소를 연결해 두지 않은 경우입니다. 예전 주소에서 새 주소로 이동 규칙을 만들어 두면 유입이 끊기지 않습니다.

편집팀 노트 — 404 오류를 직접 따져보며 정리한 기준

이 글을 정리하면서 편집팀은 같은 파일을 여러 경로와 설정으로 옮겨 가며 응답을 확인했습니다. 가장 자주 시간을 뺏긴 지점은 파일이 서버에 있는지부터 확인하는 순서였습니다.

파일 존재 여부는 대부분 문제가 아니었습니다. 404 오류의 원인은 파일이 없어서가 아니라 서버가 다른 경로를 찾아갔기 때문인 경우가 훨씬 많았습니다.

그래서 편집팀은 확인 순서를 주소 해석 과정부터 시작하도록 바꿨습니다. 요청 주소, 문서 루트, 재작성 규칙, 로그에 남은 경로를 나란히 놓고 보면 어느 단계에서 어긋났는지 드러납니다.

마지막으로 주소를 바꿀 때는 예전 주소를 함께 처리해 두기를 권합니다. 이동 규칙 하나를 남겨 두는 것만으로 이후에 생길 404 오류를 상당 부분 줄일 수 있습니다.

핵심 요약

특정 파일에서만 발생하는 404 오류는 서버 장애가 아니라 경로 불일치 문제입니다. 대소문자, 배포 누락, 상대 경로 계산, 리라이트 규칙, 앞단 캐시가 대표적인 원인이며 이 순서로 확인하면 대부분 해결됩니다.

요청 주소를 눈으로 읽지 말고 그대로 복사해 새 탭에서 열어 보는 것이 가장 빠른 첫걸음입니다. 이 글은 정보 제공을 위한 정리이며, 실제 적용은 사용 중인 서버 환경에 맞춰 확인하시기 바랍니다.