시놀로지 NAS 워드프레스 404 오류가 특정 페이지에서만 발생하는 이유

워드프레스를 운영하다 보면 이상한 상황이 생길 때가 있습니다.

홈페이지는 정상적으로 열립니다.

다른 글도 잘 보입니다.

워드프레스 관리자 페이지에도 정상적으로 로그인됩니다.

그런데 특정 글이나 특정 페이지만 접속하면 갑자기 404 오류가 나타납니다.

처음에는 서버에 문제가 생겼다고 생각하기 쉽습니다.

하지만 워드프레스에서 특정 페이지만 404가 발생한다면 서버 전체의 문제라고 단정하기 어렵습니다.

오히려 중요한 것은 정상적으로 열리는 페이지와 404가 발생하는 페이지의 차이를 찾는 것입니다.

특히 시놀로지 NAS에 워드프레스를 설치해 운영하고 있다면 웹 서버, PHP, 워드프레스, 데이터베이스, 리라이트 설정 등 여러 계층에서 원인이 발생할 수 있습니다.

이번 글에서는 특정 페이지에서만 발생하는 404 오류를 무작정 설정부터 변경하지 않고 단계적으로 진단하는 방법을 정리해 보겠습니다.

특정 페이지만 404라면 무엇이 다른지부터 확인한다

404 오류의 가장 중요한 단서는 “특정 페이지만”이라는 것입니다.

만약 홈페이지부터 관리자 페이지, 모든 게시글까지 전부 접속되지 않는다면 서버나 웹 서비스 자체를 먼저 의심해야 합니다.

반대로 다음과 같은 상황이라면 접근 방법이 달라집니다.

증상	우선 확인할 부분
모든 페이지가 404	웹 서버, 도메인, 문서 루트
특정 글만 404	글 주소, 고유주소, 게시물 상태
특정 페이지만 404	페이지 설정, 고유주소, 리라이트
새 글만 404	고유주소 또는 리라이트 문제
오래된 글만 404	주소 변경, 삭제, 리디렉션
관리자에서는 보이는데 외부에서 404	URL 또는 웹 서버 처리
모바일에서만 404	캐시, 보안 플러그인, 리디렉션
특정 카테고리 글만 404	고유주소 구조 또는 플러그인

따라서 “워드프레스가 404 오류가 난다”라고 기록하는 것보다

“기존 글 100개 중 특정 글 2개에서만 404가 발생한다”

처럼 증상을 구체적으로 기록하는 것이 훨씬 유용합니다.

먼저 실제로 글이 존재하는지 확인한다

가장 먼저 확인할 것은 의외로 단순합니다.

해당 글이나 페이지가 실제로 존재하는가?

워드프레스 관리자에서 문제가 발생하는 글을 찾아봅니다.

확인할 항목은 다음과 같습니다.

• 글이 삭제되지 않았는가
• 휴지통으로 이동하지 않았는가
• 비공개 상태가 아닌가
• 예약 발행 상태가 아닌가
• 페이지가 정상적으로 게시되어 있는가
• 글의 고유주소가 변경되지 않았는가

특히 기존 글의 주소를 변경한 경우 주의해야 합니다.

예를 들어 기존 주소가

/wordpress-404-test/

였는데 고유주소를

/wordpress-page-error/

로 변경했다면 기존 주소로 접속했을 때 404가 발생할 수 있습니다.

이 경우 NAS의 웹 서버가 고장난 것이 아니라 예전 주소를 더 이상 워드프레스가 찾지 못하는 것일 수 있습니다.

주소창의 URL을 정상 페이지와 비교한다

특정 글에서만 404가 발생한다면 정상적으로 열리는 글 하나와 문제가 발생하는 글 하나를 비교해 보는 것이 좋습니다.

단순히 제목만 비교하는 것이 아니라 실제 URL을 확인해야 합니다.

예를 들어 정상적인 주소가

https://example.com/sample-post

이고 문제가 발생한 주소가

https://example.com/sample-post

처럼 되어 있다면 리디렉션이나 고유주소 처리 과정에서 차이가 발생할 가능성이 있습니다.

또 다음과 같은 부분도 확인해야 합니다.

• 슬래시(/) 유무
• 영문 대소문자
• 한글 주소
• 특수문자
• 주소에 포함된 숫자
• 기존 주소와 새로운 주소의 차이
• URL 인코딩 문제

특히 오래 운영한 사이트라면 글 주소를 여러 번 변경하면서 과거 URL과 현재 URL이 달라졌을 가능성도 있습니다.

워드프레스 고유주소 설정을 확인한다

특정 글에서 404가 발생할 때 가장 먼저 확인할 설정 중 하나가 고유주소입니다.

워드프레스 관리자에서 고유주소 설정을 확인합니다.

여기서 중요한 것은 단순히 현재 설정이 무엇인지 보는 것만이 아닙니다.

최근에 다음과 같은 변경이 있었는지도 확인해야 합니다.

• 고유주소 구조 변경
• 워드프레스 이전
• 웹 서버 변경
• Web Station 설정 변경
• PHP 버전 변경
• 플러그인 설치
• 캐시 플러그인 변경
• 보안 플러그인 변경

특히 고유주소 구조를 변경한 직후 특정 글에서 404가 발생하기 시작했다면 시간적인 연관성을 먼저 확인해야 합니다.

문제가 발생한 시점과 설정 변경 시점을 비교하면 원인을 좁히는 데 도움이 됩니다.

고유주소 설정을 다시 저장하는 이유

워드프레스에서는 고유주소 설정을 다시 저장하는 과정이 리라이트 규칙을 다시 적용하는 데 도움이 될 수 있습니다.

이 때문에 404 오류가 발생하면 고유주소 설정 화면에서 현재 설정을 확인한 뒤 별도의 구조 변경 없이 저장하는 방법이 흔히 사용됩니다.

다만 이것을 모든 404 문제의 해결책으로 생각하면 안 됩니다.

저장 후 정상적으로 동작한다면 리라이트 규칙이나 관련 설정이 영향을 받았을 가능성을 생각해 볼 수 있습니다.

반대로 저장해도 특정 글만 계속 404라면 다른 원인을 찾아야 합니다.

진단에서 중요한 것은

“설정을 저장했더니 됐다”

에서 끝나는 것이 아니라

“왜 특정 페이지에서만 문제가 발생했는가?”

까지 확인하는 것입니다.

새 글도 404인지 테스트한다

이 단계가 상당히 중요합니다.

문제가 발생한 기존 글만 확인하지 말고 테스트용 글을 하나 만들어 봅니다.

예를 들어 제목을 간단하게 작성하고 공개한 다음 바로 해당 URL로 접속합니다.

결과에 따라 진단 방향이 달라집니다.

테스트 결과	가능성이 높은 방향
기존 글만 404	해당 글의 주소나 상태 확인
기존 여러 글이 404	고유주소·리라이트 확인
새 글도 404	웹 서버와 리라이트 설정 확인
페이지는 정상, 글만 404	글 고유주소 구조 확인
글은 정상, 페이지만 404	페이지 설정 및 리라이트 확인

새 글까지 404라면 특정 콘텐츠의 문제가 아니라 워드프레스가 요청된 URL을 실제 콘텐츠로 연결하는 과정을 집중적으로 살펴봐야 합니다.

웹 서버가 요청을 어떻게 처리하는지 확인한다

시놀로지 NAS에서 워드프레스가 정상적으로 동작하려면 단순히 워드프레스 파일이 존재하는 것만으로는 충분하지 않습니다.

요청은 여러 단계를 거칩니다.

브라우저 → NAS → 웹 서버 → PHP → 워드프레스 → 데이터베이스

특정 URL을 요청했을 때 웹 서버가 워드프레스까지 요청을 전달하지 못하면 404가 발생할 수 있습니다.

반대로 웹 서버는 정상적으로 워드프레스에 요청을 전달했지만 워드프레스가 해당 콘텐츠를 찾지 못하는 경우도 있습니다.

겉으로는 둘 다 404처럼 보일 수 있지만 원인은 다릅니다.

따라서 404가 발생했다고 해서 무조건 워드프레스 관리자에서만 해결하려고 하면 안 됩니다.

Web Station을 사용한다면 문서 루트를 확인한다

시놀로지 NAS에서 Web Station으로 워드프레스를 운영한다면 웹 포털과 문서 루트가 올바르게 연결되어 있는지도 확인해야 합니다.

특히 다음과 같은 변경 이후 문제가 발생했다면 주의합니다.

• Web Station 설정 변경
• 가상 호스트 변경
• 도메인 변경
• 문서 루트 변경
• PHP 프로파일 변경
• 웹 서버 백엔드 변경
• 사이트 파일 이동

예를 들어 워드프레스 파일은 A 폴더에 있는데 웹 포털이 B 폴더를 바라보고 있다면 정상적인 사이트 동작을 기대하기 어렵습니다.

다만 홈페이지가 정상적으로 열리고 특정 글만 404라면 문서 루트 전체가 잘못된 가능성은 상대적으로 낮습니다.

이것이 바로 증상 범위를 먼저 좁혀야 하는 이유입니다.

워드프레스가 아니라 웹 서버에서 404를 반환하는지 구분한다

404를 진단할 때 중요한 질문이 하나 있습니다.

“이 404를 누가 만들었는가?”

워드프레스가 해당 글을 찾지 못해서 404를 보여주는 것인지, 웹 서버가 요청 자체를 처리하지 못해서 404를 반환하는 것인지 구분해야 합니다.

브라우저의 개발자 도구를 활용하면 조금 더 구체적으로 확인할 수 있습니다.

Network 탭에서 문제가 발생하는 URL을 요청하고 응답을 확인합니다.

특히 다음을 살펴봅니다.

• HTTP 상태 코드
• 요청 URL
• 리디렉션 여부
• 응답 헤더
• 응답 내용
• 요청이 여러 번 반복되는지

단순히 화면에 “페이지를 찾을 수 없습니다”라고 표시되는 것보다 실제 HTTP 응답을 확인하는 것이 훨씬 정확합니다.

301이나 302가 먼저 발생하는 경우도 있다

처음부터 404가 발생한다고 생각했지만 실제로는 여러 번의 리디렉션을 거친 후 404가 발생하는 경우도 있습니다.

예를 들어

기존 주소 → HTTPS → 새로운 주소 → 최종 404

와 같은 흐름이 만들어질 수 있습니다.

이 경우 최종 화면만 보고 404 문제라고 판단하면 원인을 놓칠 수 있습니다.

따라서 Network에서 요청 흐름을 확인해 보는 것이 좋습니다.

특히 다음과 같은 설정을 최근 변경했다면 확인 대상입니다.

• HTTPS
• Reverse Proxy
• 도메인
• 워드프레스 URL
• 사이트 URL
• 리디렉션 플러그인
• 보안 플러그인

특정 글만 404라면 플러그인도 의심해야 한다

워드프레스 플러그인은 사이트 전체에 영향을 주는 것처럼 보이지만 실제로는 특정 URL이나 특정 콘텐츠에만 작동하는 경우도 있습니다.

예를 들어 다음과 같은 기능을 가진 플러그인이 원인이 될 수 있습니다.

• 리디렉션
• SEO
• 캐시
• 보안
• 접근 제한
• 사용자 권한
• URL 변경
• 커스텀 포스트 타입
• 페이지 빌더

특히 플러그인을 설치하거나 업데이트한 직후부터 특정 URL이 404가 되었다면 시간적인 연관성을 확인해야 합니다.

이때 플러그인을 여러 개 한꺼번에 비활성화하기보다는 최근 변경된 항목부터 하나씩 확인하는 것이 좋습니다.

그래야 어떤 변경이 문제를 만들었는지 추적할 수 있습니다.

캐시 때문에 404가 계속 보일 수도 있다

실제 원인을 해결했는데도 브라우저에서는 계속 404가 나타나는 경우가 있습니다.

이럴 때는 캐시를 확인해야 합니다.

확인할 대상은 하나가 아닙니다.

• 브라우저 캐시
• 워드프레스 캐시
• 캐시 플러그인
• 서버 측 캐시
• Reverse Proxy 관련 캐시
• CDN을 사용한다면 CDN 캐시

예를 들어 서버 설정을 수정한 뒤 서버에서는 정상적으로 페이지가 열리는데 특정 PC에서만 계속 404가 나타난다면 서버 자체의 문제인지 캐시 문제인지 분리해서 확인해야 합니다.

다른 브라우저나 시크릿 모드에서 같은 URL을 테스트하는 것도 좋은 방법입니다.

NAS 로그도 확인해야 한다

워드프레스 관리자에서 원인을 찾지 못했다면 NAS의 로그를 확인합니다.

특히 문제가 발생한 정확한 시간대를 기록해 두는 것이 좋습니다.

예를 들어

2026년 9월 14일 오전 8시 15분 특정 글 404 발생

처럼 기록해 두면 로그와 대조하기 쉬워집니다.

로그에서 확인할 수 있는 내용은 환경에 따라 다르지만 다음과 같은 정보를 찾아볼 수 있습니다.

• 웹 서버 요청
• 404 응답
• PHP 오류
• 권한 오류
• 잘못된 경로
• 리디렉션
• 서버 오류

중요한 것은 로그에서 “오류가 있다”는 사실만 찾는 것이 아닙니다.

문제가 발생한 URL과 시간대가 실제 로그에 나타나는지를 확인하는 것입니다.

파일이 존재한다고 해서 URL이 정상인 것은 아니다

워드프레스 초보 운영자가 자주 하는 오해가 있습니다.

“NAS 폴더에 워드프레스 파일이 있으니 해당 페이지도 존재해야 한다.”

하지만 워드프레스의 글은 단순한 HTML 파일 하나로 존재하는 구조가 아닙니다.

글의 내용과 정보는 데이터베이스에 저장되고 URL 요청에 따라 워드프레스가 해당 콘텐츠를 찾아서 페이지를 만들어 줍니다.

따라서 특정 글이 404라고 해서 NAS의 폴더에서 해당 글 이름의 파일을 찾을 필요는 없습니다.

오히려 다음을 확인해야 합니다.

URL → 워드프레스 고유주소 → 리라이트 → 워드프레스 → 데이터베이스 → 해당 콘텐츠

어느 단계에서 연결이 끊겼는지를 찾는 것이 핵심입니다.

데이터베이스 문제인지 구분하는 방법

특정 글 하나만 404라고 해서 곧바로 MariaDB 문제라고 생각할 필요는 없습니다.

데이터베이스 자체에 문제가 있다면 일반적으로 여러 기능에서 이상 증상이 나타날 가능성이 높습니다.

예를 들어

• 관리자 페이지도 이상함
• 여러 글이 열리지 않음
• 글 저장이 실패함
• 검색 기능이 이상함
• 카테고리 목록이 정상적으로 표시되지 않음

등이 함께 나타날 수 있습니다.

반대로 다른 글과 관리자 기능이 모두 정상인데 특정 글 하나만 404라면 데이터베이스 전체 장애보다는 해당 콘텐츠의 URL이나 상태를 먼저 확인하는 것이 합리적입니다.

“특정 페이지만 404” 진단 순서

실제로 문제가 발생했을 때는 다음 순서로 확인하면 불필요한 설정 변경을 줄일 수 있습니다.

1단계: 문제 범위 확인

홈페이지와 다른 글이 정상적으로 열리는지 확인합니다.

2단계: 해당 콘텐츠 확인

관리자에서 글 또는 페이지가 실제로 존재하고 공개 상태인지 확인합니다.

3단계: URL 비교

정상 페이지와 문제가 발생한 페이지의 URL 구조를 비교합니다.

4단계: 최근 변경 확인

고유주소, 플러그인, 테마, PHP, Web Station 등의 변경 여부를 확인합니다.

5단계: 고유주소 확인

워드프레스의 고유주소 설정과 리라이트 관련 상태를 확인합니다.

6단계: 새 글 테스트

새로운 테스트 글을 만들어 동일한 문제가 발생하는지 확인합니다.

7단계: HTTP 응답 확인

브라우저 개발자 도구의 Network에서 404가 실제로 어디에서 발생하는지 확인합니다.

8단계: NAS 로그 확인

문제가 발생한 시간대의 웹 서버 및 PHP 관련 로그를 확인합니다.

9단계: 플러그인 확인

최근 설치·업데이트된 플러그인이나 URL 관련 플러그인을 우선 확인합니다.

10단계: 캐시 확인

브라우저와 워드프레스 및 서버 측 캐시를 순서대로 확인합니다.

이런 경우에는 원인을 다르게 봐야 한다

404라는 결과가 같더라도 상황에 따라 진단 방향은 달라집니다.

상황	우선 의심할 부분
특정 오래된 글만 404	주소 변경 또는 삭제
새 글도 모두 404	고유주소·리라이트
특정 카테고리만 404	카테고리 URL 및 플러그인
특정 페이지 유형만 404	페이지 구조 또는 커스텀 포스트 타입
관리자에서는 정상, 외부에서 404	웹 서버·URL·리라이트
특정 브라우저에서만 404	캐시·확장 기능
최근 플러그인 설치 후 발생	플러그인 충돌
NAS 설정 변경 후 발생	Web Station·웹 서버 설정
주소 변경 직후 발생	이전 URL과 현재 URL 비교

이처럼 같은 404라도 증상을 세분화하면 조사해야 할 범위가 크게 줄어듭니다.

404를 해결하는 것보다 중요한 것은 원인을 기록하는 것

NAS에서 워드프레스를 운영하다 보면 한 번 해결한 문제가 몇 달 뒤 다시 발생할 수 있습니다.

그때 “고유주소 저장했더니 됐음” 정도로만 기억하고 있다면 같은 문제를 다시 처음부터 조사해야 합니다.

가능하면 다음 정도는 기록해 두는 것이 좋습니다.

발생 시점

문제가 발생한 URL

정상적으로 열리는 URL

최근 변경한 설정

HTTP 응답 코드

NAS 및 웹 서버 상태

실행한 조치

조치 후 결과

이 기록이 쌓이면 단순한 오류 해결 기록이 아니라 자신의 NAS 환경에 맞는 진단 데이터가 됩니다.

시놀로지 NAS 워드프레스 404 오류에서 피해야 할 행동

문제가 발생하면 인터넷에서 찾은 해결 방법을 하나씩 전부 적용하고 싶은 마음이 생깁니다.

하지만 이것은 오히려 원인을 찾기 어렵게 만들 수 있습니다.

예를 들어

• 고유주소 변경
• 플러그인 여러 개 비활성화
• PHP 버전 변경
• Web Station 설정 변경
• 파일 권한 변경
• 캐시 삭제
• 데이터베이스 수정

을 한꺼번에 실행하면 무엇 때문에 문제가 해결됐는지 알 수 없습니다.

특히 운영 중인 사이트라면 설정 변경 전 현재 상태를 기록해 두는 것이 좋습니다.

한 번에 하나를 확인하고 결과를 기록하는 방식이 가장 안전합니다.

마무리

시놀로지 NAS에서 운영하는 워드프레스에서 특정 페이지 하나만 404가 발생한다고 해서 NAS 서버 전체에 문제가 생겼다고 판단할 필요는 없습니다.

오히려 정상적으로 열리는 페이지가 있다는 것은 중요한 단서입니다.

이때는

콘텐츠 존재 여부 → URL → 고유주소 → 리라이트 → 웹 서버 → 플러그인 → 캐시 → 로그

순서로 범위를 좁혀가는 것이 효율적입니다.

특히 가장 중요한 것은 404 오류 자체보다 정상 페이지와 문제가 발생한 페이지가 무엇이 다른지 찾는 것입니다.

워드프레스의 문제 해결은 무조건 설정을 바꾸는 작업이 아니라, 증상을 기준으로 어느 계층에서 문제가 발생했는지를 좁혀가는 과정에 가깝습니다.

시놀로지 NAS에서 워드프레스를 운영한다면 이런 방식으로 하나씩 원인을 기록해 두는 것이 장기적으로 훨씬 강력한 운영 방법이 될 수 있습니다.

워드프레스 404 오류 진단 체크리스트

확인 항목	결과
홈페이지 정상 접속	□
다른 글 정상 접속	□
관리자 페이지 정상 접속	□
문제가 발생한 글이 실제 존재	□
글 공개 상태 확인	□
URL 변경 여부 확인	□
고유주소 설정 확인	□
새 글 테스트	□
HTTP 404 응답 확인	□
최근 플러그인 변경 확인	□
Web Station 변경 확인	□
PHP 변경 확인	□
NAS 로그 확인	□
캐시 확인	□

자주 묻는 질문

워드프레스 특정 글 하나만 404가 발생하면 NAS 고장인가요?

그럴 가능성은 낮습니다. 다른 글과 홈페이지가 정상적으로 열리는 상황이라면 해당 글의 URL, 게시 상태, 고유주소, 리라이트 또는 관련 플러그인부터 확인하는 것이 좋습니다.

고유주소를 다시 저장하면 404가 해결될 수 있나요?

리라이트 규칙과 관련된 문제라면 도움이 될 수 있습니다. 하지만 모든 404 오류가 해결되는 것은 아닙니다. 저장 후 문제가 해결됐다면 왜 리라이트 처리가 영향을 받았는지도 함께 확인하는 것이 좋습니다.

새 글까지 404가 발생한다면 무엇을 확인해야 하나요?

기존 콘텐츠 하나의 문제가 아니라 워드프레스의 고유주소 처리 또는 웹 서버의 리라이트 설정을 우선 확인하는 것이 좋습니다.

404 오류가 발생한 글의 파일을 NAS에서 찾아야 하나요?

일반적인 워드프레스 글은 각각 독립적인 HTML 파일로 저장되는 방식이 아닙니다. 글 데이터는 데이터베이스에 저장되고 요청된 URL에 따라 워드프레스가 콘텐츠를 구성합니다.

플러그인을 전부 삭제하거나 비활성화해야 하나요?

처음부터 전부 변경하는 것은 권장하지 않습니다. 최근 설치하거나 업데이트한 플러그인, URL·리디렉션·캐시·보안과 관련된 플러그인부터 하나씩 확인하는 것이 원인 추적에 유리합니다.