IIS의 HTTP 404 Not Found 오류 해결 - 시스템 관리자를 위한 가이드

IIS에서 상세 오류를 활성화하고 정확한 요청 URL을 확인한 후, 사이트 바인딩과 비교하여 어떤 사이트나 vdir이 의도된 것인지 식별하세요. 이 첫 번째 조치는 종종 리소스가 누락되었는지, 손실되었는지, 또는 인프라의 다른 위치에 있는지 여부를 드러내어 매핑의 소유자를 빠르게 찾고 올바른 경로를 위치하는 데 도움이 됩니다.

404 오류가 누락된 파일, 잘못 구성된 가상 디렉토리, 또는 존재하지 않는 위치를 가리키는 리디렉트에서 비롯된 것인지 식별하세요. IIS 관리자에서 vdir 설정을 검사하고 디스크상의 물리적 경로를 확인한 후, 워커 프로세스가 여러 사이트에서 계속될 수 있도록 폴더의 권한을 확인하세요. 여러 사이트가 있는 경우, 루트 폴더와 제공하는 위치를 나열하여 사이트 간 혼란을 방지하세요.

퍼머링크를 사용하는 웹 앱의 경우, URL 재작성 규칙이나 핸들러 매핑이 실제 404를 친근한 페이지로 가리는지 확인하세요. web.config 또는 URL 재작성 규칙을 업데이트한 후, 브라우저와 서버 측 로그에서 인터넷 경로를 테스트하여 결과 URL이 실제 파일이나 유효한 경로로 해결되는지 확인하세요.

리소스가 존재하지 않으면, 플레이스홀더를 생성하거나 파일을 의도된 위치로 이동하거나, 리소스를 제공하기 위한 적절한 정적/ASP.NET 경로를 구성하세요. 각 사이트에 대해 소유자와 의도된 콘텐츠 위치를 기록하여 미래 식별을 가속화하세요. 퍼머링크를 사용하여 캐노니컬 URL이 기존 리소스에 매핑되는지 확인하여 미래의 잃어버린 404를 줄이세요.

그 후 체계적인 검증을 계속하세요: 인터넷 대면 URL을 확인하고 DNS와 호스트 헤더가 올바른 사이트를 가리키는지 확인하며, 퍼머링크를 실제 파일 경로에 매핑하세요. 여전히 404가 보이면 IIS 요청 로그에서 요청을 추적하여 경로가 손실된 위치를 식별하고, 이에 따라 조정하며, 변경 사항을 소유자와 팀에 문서화하세요.

IIS 로그에서 404 패턴과 실패한 URL 분석

최신 IIS 로그를 내보내고 404 응답을 필터링하세요. 빈번한 URL 경로와 처음 발견된 타임스탬프를 찾아 사이트에 도달하려는 사람들에게 영향을 미치는 반복 문제를 정확히 파악하세요.

404의 패턴은 일반적인 원인을 드러냅니다: 누락된 리소스, 잘못 구성된 vdir 항목, 그리고 링크의 오타. 일부 문제는 리디렉션되거나 이동된 콘텐츠에서 비롯되며, 다른 문제는 내부 탐색이나 외부 참조에서 옵니다. 인덱싱을 일관되게 유지하기 위해 노트에 vdir 값을 기록하세요. 상위 위반자 목록을 작성하고 시간 경과에 따른 카운트를 추적하여 가끔 누락과 정기적으로 반복되는 문제를 구분하세요.

리퍼러와 사용자 에이전트 필드를 사용하여 문제가 검색, 다른 사이트, 또는 직접 조회에서 오는지 평가하세요. 이는 근본 원인을 우선적으로 해결하고 사용자 경험을 마찰 없이 개선하는 데 도움이 됩니다.

URL 경로, 카운트, 처음 발견, 리퍼러, 노트를 포함한 테이블 형식의 404 뷰를 내보내세요. 이 인쇄 친화적 형식은 이해관계자를 업데이트하고 경로와 인덱싱을 최적화하기 위한 단일 진실 원천을 유지하는 데 지원합니다.

URL 경로	상태	카운트	첫 발견	리퍼러	노트
/images/logo.png	404	120	2025-11-01 08:23:11	https://example.com/home	디스크상 누락된 파일
/docs/guide.html	404	68	2025-11-02 09:12:05	https://example.com/manuals	/docs/user-guide.html로 이동됨; 링크 업데이트
/shop/vdir/index.html	404	42	2025-11-03 11:01:22	https://example.com/shop/	VDir 잘못 구성됨; 경로 확인

404 해결 및 방지 조치

누락된 리소스에 대해 파일을 복원하거나 올바른 URL로 301 리디렉션을 생성하세요. 잘못 구성된 vdir에 대해 IIS 관리자에서 vdir 경로를 확인하고 applicationHost.config를 확인하며 기존 물리적 경로를 확인하세요. 오타에 대해 링크를 수정하고 페이지에 대한 콘텐츠를 업데이트하며 내부 검색 인덱스를 정기적으로 새로 고치세요.

요약 보고서를 인쇄하고 지원 팀과 공유하세요. 작동한 것과 작동하지 않은 것을 추적하기 위해 변경 사항의 실행 목록을 계속 업데이트하세요. 여러 빈번한 위반자에 대해 대상 리디렉션을 구현하고 죽은 링크를 제거하여 미래 오류를 줄이세요.

수집한 패턴을 정기적으로 검토하여 404 처리 방식을 최적화하고, 프로덕션에 업데이트를 적용하기 전에 스테이징 환경에서 리디렉션을 테스트하세요. 이 접근 방식은 실수를 최소화하고 사이트 탐색 시 사람들에게 더 부드러운 경험을 제공하는 데 도움이 됩니다.

사이트 바인딩, 호스트 헤더 및 가상 디렉토리 확인

바인딩을 즉시 검토하고 수정하세요: 호스트 헤더, IP, 포트가 클라이언트 요청과 일치하고 사이트 이름이 사용 중인 URL에 해당하는지 확인하세요.

바인딩 확인

• IIS 관리자를 열고 Sites > [your site] > Bindings로 이동하세요. 올바른 IP와 포트로 http (및 사용 중인 경우 https)에 대한 바인딩이 있는지 확인하세요. 여러 사이트가 동일한 IP:port를 공유하는 경우: 요청을 적절히 라우팅하기 위해 현재 URL과 일치하는 호스트 이름 (호스트 헤더) 값을 추가하세요.

• 정확한 호스트 헤더로 요청 테스트: curl -I -H "Host: example.com" http://server/ 또는 브라우저 사용. 404가 지속되면 바인딩이 올바를 수 있지만 요청된 경로가 다른 사이트에서 처리될 수 있습니다.

• https의 경우, 바인딩의 호스트네임과 인증서가 일치하는지 확인하세요. 주제와 SAN을 확인하고 바인딩이 포트 443에서 올바른 인증서를 사용하는지 확인하세요. 불일치는 누락된 리소스처럼 보이는 실패한 요청을 초래할 수 있습니다.

• DNS와 프록시 계층 검사: 들어오는 요청이 예상 호스트 헤더를 전달하는지 확인하세요; 프록시 잘못 구성은 유효한 경로에 대한 404를 발생시킬 수 있는 잘못된 사이트에 요청을 착지시킬 수 있습니다.

가상 디렉토리 및 경로 구성

1. 사이트 아래에 가상 디렉토리 별칭이 존재하는지 확인하세요; 별칭은 URL 세그먼트로 나타나야 합니다 (예: /files). 오른쪽 창에서 물리적 경로를 검토하고 폴더가 존재하며 앱 풀 ID로 접근 가능한지 확인하세요.

2. 디렉토리가 코드를 실행해야 할 때 애플리케이션으로 변환하세요. 가상 디렉토리를 오른쪽 클릭 > Convert to Application, 올바른 애플리케이션 풀 선택, 풀 ID가 물리적 경로에 읽기 권한이 있는지 확인하세요.

3. 디렉토리 수준 URL에 의존하는 경우 기본 문서를 확인하세요; 유효한 기본 문서 (index.html, default.aspx 등)가 있는지 또는 링크에 명시적 파일 경로를 제공하세요.

4. 존재하지 않는 경로로 리디렉션할 수 있는 web.config 규칙과 URL 재작성을 검토하세요. 잘못된 규칙은 유효한 페이지에 대해 누락된 리소스 404를 생성할 수 있습니다; 충돌하는 규칙을 조정하거나 제거하세요.

5. 권한 유효성 검사: IIS_IUSRS와 앱 풀 ID에 물리적 경로에 대해 읽기/실행을 부여하고, 예상 사용자에 대한 NTFS ACL이 접근을 허용하는지 확인하세요. 누락된 권한은 콘텐츠가 사라진 것처럼 보이는 404를 종종 초래합니다.

6. 변경 후 다시 테스트: 문제 URL을 요청하고 200 또는 적절한 리디렉션을 확인하세요; 리디렉션이 루프되거나 리소스가 여전히 누락되면 재작성 규칙과 애플리케이션 풀의 시작 로그를 검토하세요.

바인딩이나 가상 디렉토리로 인한 누락된 페이지 문제를 드러내기 위해 기본 크롤을 사용하세요. IIS 로그에서 404 항목을 grep하여 어떤 요청이 실패하는지 찾은 후, 근본 원인을 해결하고 신선한 크롤로 다시 테스트하세요. 결과를 저장하고 문제를 처리하는 동안 관리자와 LinkedIn의 동료들에게 간결한 요약을 공유하여 모두를 일치시키세요.

파일 경로, 물리적 존재 및 파일 권한 유효성 검사

IIS 관리자에서 사이트의 물리적 경로를 확인하고 디스크상에 경로가 존재하는지 확인하세요. 사이트 또는 가상 디렉토리의 기본 설정에서 가리키는 폴더가 예상 콘텐츠를 포함하는지 확인하세요. 경로가 변경된 경우 원래 위치를 복원하거나 스냅인에서 매핑을 수정하여 요청이 올바른 폴더를 주소 지정하도록 하세요; 그렇지 않으면 IIS가 아무것도 로드하지 않고 404가 보입니다.

파일이 파일 시스템상에 실제로 존재하고 앱 풀 ID가 이를 탐색하고 읽을 권한이 있는지 확인하세요. 파일 탐색기 또는 icacls를 사용하여 폴더와 모든 상위 폴더의 ACL을 확인하세요. 콘텐츠 루트와 내부 파일에 앱 풀 ID (예: IIS APPPOOLYourAppPool)에 대해 읽기와 폴더 내용 나열 및 탐색을 부여하세요. 권한이 잘못된 경우 IIS가 접근 거부를 나타내고 엔진이 파일이 존재할 때도 404를 반환할 수 있습니다. ACL을 적절히 조정하고 재테스트하세요. 확실하지 않으면 파일이 로드되는지 확인하기 위해 알려진 사용자에게 일시적으로 읽기 접근을 할당하세요.

서비스하는 확장에 대한 MIME 유형 매핑을 확인하세요. 사이트의 MIME 유형을 열고 확장이 연결된 MIME 유형을 가지는지 확인하세요; 누락된 매핑은 종종 404를 발생시킵니다. 필요 시 일반 유형 (.html, .css, .js, 이미지, 폰트)을 추가하고 올바른 content-type이 전송되는지 확인하세요. 또한 퍼머링크 스타일 URL이 올바른 폴더에서 로드되는지 확인하세요; 퍼머링크 경로와 물리적 경로 간 불일치는 정적 및 동적 자산 모두에 404를 트리거할 수 있습니다.

사이트의 요청 승인 설정을 검토하세요. 스냅인에서 사이트의 Authorization Rules로 이동하고 클라이언트 ID가 요청된 폴더를 읽을 수 있도록 허용되는지 확인하세요. 거부 규칙이 파일을 차단하면 엔진이 일부 경로에 대해 404를 반환할 수 있습니다; 규칙을 제거하거나 좁히는 것이 도움이 됩니다. 공용 접근에 의존하는 경우 익명 인증이 활성화되었는지 확인하고, 여러 사이트가 동일한 콘텐츠 루트를 공유하는 경우 도메인 수준 또는 사이트 수준 설정을 확인하세요.

로그와 추적을 활성화하고 확인하세요. 404 오류에 대해 실패한 요청 추적을 켜거나 IIS 로그를 검토하여 히트 수와 요청 주소 식별하세요. 엔진에서 정확한 URL, 매핑된 경로, 파일 경로를 찾아보세요; 이 식별 데이터는 소스를 위치하는 데 도움이 됩니다. 정보를 사용하여 올바른 경로를 복원하고 로드 순서를 수정하며 좌절스러운 재발을 방지하세요. 인터넷 대면 사이트에서 도메인 프로필과 물리적 경로가 일치하는지 확인하세요; 작은 불일치는 여러 사이트의 접근을 깨뜨릴 수 있습니다. 변경 후 앱 풀을 재활용하여 새로운 매핑과 권한을 적용하세요. 지속적인 404를 처리하는 경우 근본 원인을 먼저 해결한 후 모든 사이트에 걸친 사용자 여정을 확인하세요.

URL 재작성 규칙 및 사용자 지정 오류 구성 검토

각 사이트의 현재 URL 재작성 규칙을 IIS에서 내보내고 알려진 좋은 기준선과 비교하여 404 결과를 초래하는 잘못 구성된 부분을 정확히 파악하세요. 이는 문제가 재작성된 URL, 누락된 리소스, 또는 부적절한 사용자 지정 오류 경로에서 비롯되는지 여부를 드러냅니다.

검사할 내용

web.config 또는 각 사이트의 URL 재작성 모듈을 통해 규칙을 찾으세요. 재작성 또는 리디렉션을 트리거하는 패턴과 조건을 검토하고 대상 URL이 기존 리소스 또는 사용자 지정 오류에 정의된 적절한 HTML 페이지로 가리키는지 확인하세요. 404 항목이 정의되었고 오류 페이지가 사이트 루트 아래에 존재하는 경로를 사용하는지 확인하세요. 동일한 애플리케이션 풀을 공유하는 사이트 간 충돌을 확인하세요.

평가 순서를 감사하세요: 첫 번째 일치 규칙이 추가 처리를 중지합니다. 사용자 지정 오류 핸들러가 실행되기 전에 404를 캡처할 수 있는 인바운드 또는 아웃바운드 규칙을 찾아보고 구성된 위치에 폴백 404 페이지가 있는지 확인하세요. 사이트별 구성을 재정의할 수 있는 전역 또는 사이트 수준 설정을 검토하세요.

수정 적용 방법

규칙이 잘못 구성된 경우 일치 패턴, 재작성 작업, 대상을 조정하세요. 누락된 리소스가 404가 아닌 응답을 반환하는 기존 경로로 재작성되지 않도록 확인하세요. 404 요청이 실제 HTML 파일로 라우팅되도록 사용자 지정 오류 섹션을 업데이트하고 파일이 올바른 권한으로 배포되었는지 확인하세요. 변경 후 앱 풀을 재활용하고 다른 클라이언트 환경에서 테스트하여 일관된 결과를 확인하세요. 서버 로그와 실패한 요청 추적 (FRT) 데이터를 사용하여 정확한 규칙과 최종 응답 페이지를 식별하세요.

대상 테스트로 실패 재현 및 응답 모니터링

권장 사항: 대상 테스트로 404를 재현하고 공유 대시보드에서 응답을 모니터링하세요. 액세스 로그에 증거를 캡처하고 각 패턴에 소유자를 지정하여 수정 속도를 높이세요. 이 접근 방식은 관리자가 현재 영향을 보고 사이트 범위에 걸쳐 수정 우선순위를 정하는 데 도움이 됩니다.

사이트의 액세스 로그에서 지난 200개의 404 항목을 내보내세요. 각 항목에 대해 시간, 클라이언트 IP, 호스트네임, 요청 URL, 리퍼러, 사용자 에이전트, 상태, 응답 크기를 기록하세요. 관련 경로 아래 누락된 자산을 관찰하면 고립된 사례가 아닌 패턴을 나타냅니다. 이러한 신호에서 간결한 테스트 목록을 작성하여 다음 단계를 진행하세요.

경로 변형 테스트: 후행 슬래시 유무로 알려진 누락 URL 요청; 세그먼트의 대소문자 변경; 쿼리 문자열 추가 또는 제거; 정적 자산에 대한 응답을 동적 경로와 비교하세요. 서버가 의도하지 않은 리디렉션이나 재작성 전에 404를 반환하는지 확인하기 위해 GET과 HEAD 메서드 모두 포함하세요.

가능한 경우 실패한 요청 추적 (FRT)을 사용하고 동일한 타임스탬프에 대한 액세스 로그와 교차 확인하세요. 이러한 추적은 어떤 규칙이나 모듈이 리소스를 차단했는지 또는 리소스가 실제로 누락되었는지 나타냅니다. 결과를 대시보드 메트릭에 연결하세요: 경로별, 호스트별, 계정별 404 카운트. 이 우수한 상관관계는 조사를 가속화하고 현재 핫스팟을 드러냅니다.

재작성 또는 라우팅 계층 뒤의 리소스에 대해 관련 web.config, URL 재작성 규칙, IIS가 재작성 모듈을 통해 준수할 수 있는 htaccess-like 구성을 확인하세요. 404가 매핑 문제를 나타내는 경우 규칙이나 파일 경로를 조정하고 프로덕션으로 이동하기 전에 테스트를 다시 실행하여 수정을 확인하세요. 404가 차단된 리소스를 가리키는 경우 차단 목록이나 접근 제한을 확인하고 의도된 접근 패턴과 일치하는지 확인하세요.

대시보드에 결과를 문서화하고 사이트 소유자와 관리자와 요약을 공유하세요. 필요 시 크로스 팀 가시성을 위해 LinkedIn에 인사이트를 게시하세요. 프로세스는 반복 가능해야 합니다: 테스트 입력을 저장하고 응답을 캡처하며 액세스 로그에서 관련 로그를 첨부하여 계정 소유자나 보안 팀이 검토할 수 있도록 하세요.

회복력 개선 방법: 테스트 목록을 반복하고 상태 코드를 기록하며 스파이크를 플래그하는 작은 테스트 하네스를 구축하세요. 이러한 신호를 사용하여 누락된 자산에 조치를 취하고 콘텐츠 인벤토리를 업데이트하며 정당화될 때만 IP로 시끄러운 프로브를 차단하세요. 항상 현재 테스트 스위트를 사이트 인벤토리와 MIME 유형 매핑과 일치시켜 회귀를 방지하세요.

변경 전에 소유자 승인과 롤백 계획을 확보하세요. 지속적인 모니터링 대시보드는 404 비율이 안정적인지, 상승하는지, 또는 기준선으로 돌아가는지 나타내야 합니다. 잘 운영되는 테스트 체제는 인시던트 응답을 가속화하고 팀이 더 부드러운 사용자 경험을 제공하는 데 도움이 됩니다.