그냥 디렉터리 검색(Directory Browsing)을 켜면 되지 않나요?

그러면 에러 메시지는 사라지고 더 나쁜 문제가 생깁니다. 디렉터리 검색을 켜면 IIS가 그 폴더의 모든 파일 목록으로 요청에 응답합니다 — 노출할 생각이 없던 소스, 백업, 설정 파일까지 전부요. 게다가 실제 원인(대개 기본 문서 누락이나 앱 라우팅 실패)을 가려버립니다. 디렉터리 검색은 목록을 보여줘도 되는 내부 파일 공유 폴더에서만 켜세요. 실제 사이트라면 기본 문서를 추가하거나 라우팅을 고치세요.

ASP.NET / MVC / Core 앱인데 페이지가 있는데도 403.14가 납니다. 왜죠?

IIS가 루트 URL을 보고 일치하는 파일도 기본 문서도 못 찾아, 애플리케이션 라우팅이 돌기도 전에 포기했기 때문입니다. 403.14 가면을 쓴 404입니다. 요청이 관리 코드에 도달하지 못한 것이고, 원인은 대개 앱이 파이프라인에 연결되지 않은 것입니다 — 잘못된 응용 프로그램 풀 모드, IIS에 등록되지 않은 ASP.NET, 또는 (.NET Core라면) ASP.NET Core Module 핸들러가 담긴 `web.config`가 없거나 깨진 경우. 프레임워크가 요청을 받도록 핸들러 등록을 고치세요. 디렉터리 검색을 켜서 덮지 마세요.

403.14는 일반 403과 뭐가 다른가요?

점 뒤의 숫자는 이유를 정확히 알려주는 IIS 하위 상태(substatus)입니다. 순수 403(또는 403.1~403.12)은 진짜 접근 거부입니다 — 권한, IP 제한, 인증 규칙. 403.14는 더 좁고 거의 기계적입니다. URL이 디렉터리를 가리켰고, 그 디렉터리에 기본 문서가 없고, 디렉터리 검색이 꺼져 있어 IIS가 반환할 게 없는 상태입니다. 당신이 누구냐의 문제가 아니라, 그 경로에 내보낼 문서가 없다는 문제입니다.

조회수: 6

403.14 Forbidden IIS 오류 해결

IIS의 403.14 Forbidden 오류를 3단계로: 기본 문서, 확장자 없는 라우팅, 그 뒤에 숨은 진짜 404를 순서대로 점검. 무료 즉시 진단으로 바로 확인.

내 도메인에 이 문제가 있는지 지금 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

에러 문구는 무엇을 하라고 알려주는데, 그게 하필 하면 안 되는 일입니다.

HTTP 오류 403.14 - Forbidden. 이 디렉터리의 내용을 나열하지 않도록 웹 서버가 구성되어 있습니다.

문구를 곧이곧대로 읽으면 디렉터리 목록을 켜라고 사실상 부추기는 것 같습니다. 그렇게 하면 에러는 사라집니다 — 대신 폴더 안 모든 파일의 공개된 클릭 가능한 목록으로 바뀝니다. 소스, web.config, 마침 거기 있던 백업까지 전부요. 문제를 고친 게 아닙니다. 디렉터리 트리를 공개하고, 진짜 원인을 그 밑에 묻은 것입니다.

403.14가 실제로 뜻하는 것

점 뒤 숫자는 IIS 하위 상태이고 구체적입니다. 순수 403 — 또는 403.1부터 403.12까지 — 는 진짜 접근 거부입니다. NTFS 권한, IP 제한, 안 된다고 말하는 인증 규칙. 403.14는 다른 종류이고 거의 기계적입니다. 다음 세 가지가 동시에 참일 때 발생합니다.

URL이 특정 파일이 아니라 디렉터리를 가리킨다 (/app/index.html이 아니라 /app/).
그 디렉터리에 IIS가 내보낼 기본 문서가 없다.
디렉터리 검색이 꺼져 있다 (안전한 기본값).

그래서 IIS는 폴더 요청을 들고 있는데, 돌려줄 문서가 없고, 폴더 목록을 낼 권한도 없습니다. 내보낼 게 없으니 403.14를 반환합니다. 여기 없는 것에 주목하세요. 당신의 신원이나 권한과는 아무 상관이 없습니다. “보낼 게 없다”가 “Forbidden”으로 분장한 것입니다.

사실은 두 가지를 말하고 있다

403.14를 접근 문제로 읽기를 멈추면, 원인이 깔끔하게 둘로 갈립니다.

정적 사이트인데 진짜로 랜딩 문서가 없다. 폴더를 배포했고, /로 요청이 들어오는데, IIS가 집어들 index.html이나 default.aspx가 없습니다. 해결은 기본 문서를 추가하는 것입니다 — IIS 관리자에서 사이트를 열고 **기본 문서(Default Document)**를 더블클릭해, 실제로 배포한 파일이 목록에 있고 위쪽에 있는지 확인하세요. IIS는 목록을 위에서 아래로 매칭하므로, 배포한 index.html보다 index.htm이 위에 있으면 계속 못 찾고 넘어갑니다. 정직하고 지루한 경우입니다.

애플리케이션인데, 앱이 요청을 보기도 전에 요청이 죽었다. 이게 사람들을 헷갈리게 합니다. 페이지가 있다는 걸 알기 때문이죠. ASP.NET MVC나 ASP.NET Core 앱은 /products/42 같은 확장자 없는 URL을 서빙합니다 — 그 경로에 파일은 없습니다. 컨트롤러로 라우팅하는 건 프레임워크의 일이고, 프레임워크는 IIS가 요청을 관리 파이프라인으로 넘겨야만 받습니다. 페이지가 분명히 있는 앱에서 403.14가 뜬다면, IIS가 그 경로의 파일을 찾다 없고, 기본 문서도 없어서 — 라우팅이 돌기 전에 그만둔 것입니다. 403.14 가면을 쓴 404입니다.

IIS가 요청을 넘기지 않은 이유는 검색(browsing)의 문제가 아니라 등록의 문제입니다.

응용 프로그램 풀 모드가 틀렸거나, ASP.NET이 IIS에 등록된 적이 없다. 옛 .NET에선 aspnet_regiis -i가 고치던 부분이고, 요즘은 올바른 .NET 호스팅 구성 요소가 설치되고 풀의 파이프라인 모드가 앱과 맞는지 확인하는 것에 해당합니다.
ASP.NET Core라면 사이트의 web.config가 없거나 깨져서, 요청을 앱(Kestrel)으로 전달하는 ASP.NET Core Module 핸들러가 걸리지 않습니다. web.config를 내보내지 않은 게시나 덮어써진 게시가 정확히 이 증상을 냅니다.

runAllManagedModulesForAllRequests="true"로 설정하라는 조언을 볼 겁니다. 앱이 응답하게 만들 수는 있지만 무딘 도구입니다 — 정적 파일을 포함한 모든 요청을 관리 파이프라인으로 강제해 더 느리고, 장기적으로 원하는 상태가 아닙니다. 디렉터리 검색 켜기와 마찬가지로 증상만 가립니다. 확장자 없는 요청이 의도된 방식으로 프레임워크에 도달하도록 핸들러 등록을 고치세요.

밖에서 확인하라

HTTP 헤더 확인은 URL을 가져와 네트워크 밖에서 실제 상태 줄과 응답 헤더를 보여줍니다. 실제로 403.14를 받는지(그리고 앞단 프록시·로드밸런서가 아니라 IIS에서 나오는지) 확인하고, 캐시됐을지 모를 브라우저 탭을 믿지 말고 변경할 때마다 응답을 다시 점검하세요.

체크리스트

하위 상태를 읽으세요. 403.14는 “여기 보낼 문서가 없다”이지 “당신은 허용 안 됨”이 아닙니다. 권한 문제로 취급하지 마세요.
정적 사이트라면 올바른 기본 문서를 추가하고 목록에서 잘못된 기본값보다 위로 올리세요.
실제 페이지가 있는 앱이라면 요청이 코드에 도달하지 못하는 것입니다 — 응용 프로그램 풀 모드, ASP.NET/.NET 호스팅 설치·등록, 앱 핸들러가 담긴 유효한 web.config 배포를 확인하세요.
에러를 없애려고 디렉터리 검색을 켜지 마세요 — 파일을 노출하고 진짜 원인을 가립니다.
변경할 때마다 밖에서 URL을 다시 확인해, 캐시된 페이지가 아니라 서버를 테스트하세요.