HTTP Error 500.19는 제 애플리케이션 코드 문제인가요?

아닙니다. 500.19는 애플리케이션이 실행되기 *전에* 발생합니다. IIS는 설정 파일들 — applicationHost.config와 사이트 디렉터리 트리의 web.config들 — 을 읽는 도중에 이 오류를 반환하고, 그중 하나라도 읽을 수 없으면 즉시 멈춥니다. 컨트롤러도, 시작 코드도, DB 연결도 아무것도 실행되지 않았습니다. 그래서 해법은 코드가 아니라 거의 항상 설정 파일, 잠긴 섹션, 누락된 모듈, 파일 권한에 있습니다. 앱을 뒤지는 건 전형적인 오후 낭비입니다.

500.19 페이지의 0x8007000d 코드는 무슨 뜻인가요?

0x8007000d는 Win32 ERROR_INVALID_DATA입니다 — IIS가 파싱할 수 없는 XML이나 인식하지 못하는 섹션을 만난 것입니다. 두 가지가 압도적으로 흔합니다: web.config가 malformed(엉뚱한 태그, 깨진 문자, 잘못된 병합)거나, 이 서버에 설치되지 않은 모듈의 설정 섹션을 참조하는 경우입니다. URL Rewrite 모듈 없이 ` ` 섹션을 쓴 게 교과서적 사례입니다 — 설정은 유효한데, 모듈이 설치된 적이 없어 서버가 ` `가 뭔지 모르는 것입니다.

잘 되던 설정을 복사했는데 왜 500.19 0x80070021이 뜨나요?

0x80070021은 ERROR_LOCK_VIOLATION입니다: 설정하려는 섹션이 상위 레벨에서 잠겨 있습니다. 많은 IIS 섹션은 `overrideModeDefault="Deny"`로 출고되므로, 같은 web.config가 한 서버에선 합법이고 다른 서버에선 applicationHost.config 구성에 따라 거부됩니다. 설정이 바뀐 게 아니라 잠금이 다른 것입니다. `appcmd unlock config -section: `으로 섹션 잠금을 풀거나 설정을 applicationHost.config로 올리세요 — 앱에 실제로 필요한 설정을 지우지는 마세요.

조회수: 16

HTTP Error 500.19 (IIS 설정 오류)

HTTP Error 500.19는 IIS가 설정 파일을 못 읽은 것. HRESULT 16진수로 XML·잠긴 섹션·권한 중 원인을 짚는다. 무료 즉시 진단.

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

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

Problem

IIS에 사이트를 배포하고 열면, 홈페이지 대신 서버가 생성한 살벌한 페이지가 뜹니다: HTTP Error 500.19 - Internal Server Error, 그리고 “The requested page cannot be accessed because the related configuration data for the page is invalid”라는 문구. 그 페이지 어딘가에 Config Error라고 적힌 줄, Config Source라고 적혀 XML 세 줄을 보여 주는 줄, 그리고 — 다들 건너뛰는 부분 — 16진수로 된 Error Code가 있습니다. 그 16진수 코드가 진단의 전부입니다. 나머지는 배경일 뿐입니다.

Symptoms

사이트(또는 가상 디렉터리)로 가는 모든 요청이 500.19를 반환합니다; IIS가 설정 읽기를 끝내지 못하므로 아무것도 통과하지 못합니다.
오류 페이지가 Config Source 파일을 지목합니다 — 보통 앱 폴더의 web.config, 때로는 applicationHost.config.
0x8007000d, 0x80070021, 0x80070005, 0x800700b7 같은 Error Code가 상단에 나타납니다.
배포 직후, 서버 이전, 모듈 제거, 다른 머신에서 설정을 복사한 뒤에 자주 발생합니다.
외부 HTTP 점검은 서버가 살아 있고 5xx를 반환함을 보여 줍니다 — 즉 DNS·TLS·라우팅은 정상이고 문제는 전적으로 오리진의 설정에 있습니다.

What 500.19 Actually Means

IIS는 사이트의 유효 설정을 계층 병합으로 구성합니다: 머신 전역 applicationHost.config, 그다음 사이트 루트부터 요청 경로까지 각 폴더의 web.config. 이 작업은 요청을 애플리케이션에 넘기기 전에 이루어집니다. 500.19는 IIS가 “그 병합 설정을 구성할 수 없다”고 말하는 것이고, 구성할 수 있을 때까지 아무것도 서빙하지 않습니다.

그래서 500.19는 500이 아닙니다. 순수 500은 코드가 실행되어 예외를 던진 것입니다. 500.19는 코드가 아예 시작되지 못한 것입니다 — 서버가 그것을 시작하는 데 필요한 설정조차 조립하지 못했으니까요. 이 구분이 중요한 건 어디를 보지 말아야 하는지를 알려 주기 때문입니다: 앱도, DB도, 프레임워크도 아닙니다. 문제는 IIS가 읽는 파일, 그 파일을 읽을 권한, 또는 설정 섹션에 의미를 부여하는 모듈에 있습니다.

16진수 Error Code가 하위 진단이고, 각 값은 특정 지점을 가리킵니다. 맨 마지막이 아니라 맨 처음 읽어야 할 것으로 다루세요. Config Source 아래의 XML 조각은 문제가 된 줄을 보여 주지만, 16진수는 그것이 왜 문제인지를 알려 줍니다 — malformed, 잠김, 읽기 불가, 중복은 모두 똑같은 빨간 페이지를 띄우지만 해법은 완전히 다른 네 가지입니다.

Top 3 Causes

malformed XML 또는 설치되지 않은 모듈의 섹션 — 0x8007000d. web.config에 깨진 XML(닫히지 않은 태그, 잘못된 병합, 괄호가 빠진 복붙)이 있거나, 이 서버에 모듈이 설치된 적 없는 <rewrite>, <applicationInitialization>, ARR/<proxy> 블록 같은 섹션을 선언한 경우입니다. 설정 자체는 완벽히 유효한 경우가 많습니다; 서버가 그 기능이 없어서 섹션을 인식하지 못하는 것뿐입니다. 단서: Config Source가 당신이 설치를 잊은 그 모듈의 섹션을 정확히 가리킵니다. URL Rewrite(또는 해당 모듈)를 설치하거나 섹션을 제거하세요.
상위 레벨에서 잠긴 설정 섹션 — 0x80070021. 섹션이 applicationHost.config에서 overrideModeDefault="Deny"로 설정되어, 이를 정의하려는 web.config가 거부됩니다. 이것이 “내 컴퓨터에선 됐는데” 오류입니다: 같은 설정, 다른 잠금 상태. 단서: 같은 설정 파일이 한 서버에선 깔끔히 배포되고 다른 서버에선 500.19를 냅니다. appcmd unlock config -section:system.webServer/<section>으로 풀거나 설정을 applicationHost.config로 승격하세요 — 앱이 의존하는 설정을 그냥 지우지는 마세요.
앱 풀 ID가 콘텐츠나 설정을 못 읽음 — 0x80070005. 0x80070005는 ERROR_ACCESS_DENIED입니다: 워커 프로세스 ID(IIS AppPool\<PoolName> 또는 ApplicationPoolIdentity)가 물리 경로나 web.config에 읽기 권한이 없거나, UNC 공유용 가상 디렉터리의 “Connect as…” 자격 증명이 틀렸거나 만료됐습니다. 단서: 설정 내용이 아니라 파일이 어디 있는지, 풀이 누구로 실행되는지에 따라 움직입니다. 앱 풀 ID에 사이트 폴더 읽기 권한을 부여하거나 UNC 자격 증명을 고치세요.

Diagnose with DechoNet

HTTP Check는 서버가 도달 가능하고 타임아웃이나 연결 거부가 아니라 5xx를 반환하는지 확인합니다 — 즉 서버는 살아 있고 실패는 다운된 오리진·DNS 미스·닫힌 포트가 아니라 설정임을 알려 줍니다. 외부 점검이 아예 연결조차 못 하면 잘못된 계층을 뒤지고 있는 것입니다.
SSL Check는 TLS 핸드셰이크가 완료되는지 검증해, web.config를 파헤치기 전에 인증서나 HTTPS 바인딩 문제가 서버 오류로 위장한 게 아닌지 배제합니다.
DNS Check는 호스트명이 당신이 실제로 편집 중인 서버로 해석되는지 확인합니다 — “설정을 고쳤는데 안 먹힌다”는 사례의 놀랄 만큼 많은 수가 DNS가 다른 곳을 가리켜 엉뚱한 박스에 편집을 적용한 경우입니다.

Resolution Checklist

16진수 Error Code를 먼저 읽으세요. 0x8007000d(유효하지 않음/인식 불가), 0x80070021(잠김), 0x80070005(권한 거부), 0x800700b7(중복 항목)는 각각 해법이 다릅니다. 아래 전부가 어느 코드인지에 달려 있습니다.
0x8007000d면 Config Source가 지목한 web.config를 열고 XML을 검증하세요 — 나쁜 문자 하나, 닫히지 않은 요소 하나로도 충분합니다. XML이 깨끗하면, 실패한 섹션이 이 서버에 설치되지 않은 모듈(URL Rewrite, Application Request Routing, Application Initialization)의 것인지 확인하세요.
0x80070021이면 페이지가 지목한 정확한 섹션에 대해 %windir%\system32\inetsrv\appcmd unlock config -section:<section-name>을 실행하거나 applicationHost.config 레벨에서 override를 설정하세요.
0x80070005면 앱 풀 ID에 물리 경로 읽기 권한을 부여하고(icacls "C:\path" /grant "IIS AppPool\YourPool:(OI)(CI)R"), UNC “Connect as” 자격 증명을 다시 확인하세요.
0x800700b7(“Cannot add duplicate collection entry”)면 두 번 정의된 설정을 찾아 — 대개 부모 web.config와 자식에 같은 <add>가 있습니다 — 하나를 제거하거나 <add> 앞에 <remove>를 쓰세요.
수정 후, 외부에서 사이트가 캐시된 오류 페이지가 아니라 실제 200(또는 앱의 실제 응답)을 반환하는지 확인하세요.

When to Escalate

Config Source가 앱의 web.config가 아니라 applicationHost.config를 가리키면 문제는 앱이 아니라 서버 전역입니다 — 머신 레벨 설정을 편집하기 전에 IIS 호스트 소유자와 조율하세요. 거기서의 unlock이나 override 변경은 서버의 모든 사이트에 영향을 줍니다.
16진수 코드의 특정 원인을 해결했는데도 500.19가 지속되면, 전체 오류 페이지(코드, Config Source, 파일 경로)를 캡처하고 Windows 애플리케이션 이벤트 로그를 확인하세요; 깨지거나 부분 설치된 모듈은 섹션을 등록된 채 비작동 상태로 남길 수 있고, 이는 설정 편집이 아니라 복구나 재설치가 필요합니다.