Windows Server 2025 / IIS 사이트 바인딩·호스트 이름·응용 프로그램 풀을 설정하는 방법
IIS 바인딩은 프로토콜·IP·포트·호스트 이름으로 요청을 받을 사이트를 정하고, 응용 프로그램 풀은 웹 앱을 실행할 프로세스 경계를 정합니다. DNS 이름이 같은 서버 IP로 연결되더라도 바인딩과 풀을 알맞게 구성해야 원하는 사이트가 동작합니다.
DNS·바인딩·폴더·풀의 역할입니다
| 구성 | 역할 | 실습 예 |
|---|---|---|
| DNS | 이름을 IP로 해석 | web.lab.example.test → 172.24.50.30 |
| 바인딩 | 요청을 사이트에 연결 | http / .30 / 8080 / web.lab.example.test |
| 물리 경로 | 제공할 파일 위치 | C:\Sites\LabSite |
| 응용 프로그램 풀 | 프로세스 실행·ID·격리 | LabSitePool |
호스트 이름 바인딩은 요청에 담긴 이름을 확인합니다. DNS 레코드를 만든다고 IIS 바인딩이 생기지 않고, 바인딩을 만든다고 DNS가 자동 등록되는 것도 아닙니다. IIS binding 요소 설명의 IP·포트·호스트 조합을 기준으로 충돌을 확인하세요.
이 글은 WEB1의 LabSite가 172.24.50.30:8080에서 동작하는 상태를 전제로 합니다. 같은 포트에서 두 사이트를 이름으로 구분해 보되 공개 DNS나 실제 회사의 사이트 설정은 바꾸지 않습니다. 사용 중인 포트와 기존 바인딩을 먼저 기록합니다.
실습 DNS 이름을 추가합니다
- DC1의 DNS 관리자에서 기존 정방향 조회 영역 lab.example.test를 엽니다.
- 새 호스트(A) web을 만들고 172.24.50.30을 지정합니다.
- 두 번째 시험 이름 status도 같은 172.24.50.30으로 추가합니다.
- CLIENT1이 DC1의 내부 DNS를 사용하고 있는지 확인합니다.
- 두 이름을 Resolve-DnsName으로 조회해 .30이 반환되는지 확인합니다.
Resolve-DnsName web.lab.example.test -Server 172.24.50.10
Resolve-DnsName status.lab.example.test -Server 172.24.50.10lab.example.test는 강좌에서 별도로 만든 실습 영역입니다. AD 도메인 ad.example.test와 구분하며, 파일 기반 영역이라면 DC2에 자동 복제된다고 가정하지 않습니다. 존재하지 않는 영역에 레코드를 추가하려 하지 말고 먼저 해당 영역과 DNS 서버를 확인하세요.
첫 사이트에 호스트 이름을 지정합니다
- IIS 관리자 → LabSite → 바인딩에서 기존 http / .30 / 8080 / 빈 이름 항목을 선택합니다.
- 편집에서 호스트 이름을 web.lab.example.test로 지정하고 저장합니다.
- LabSite의 다른 바인딩과 중복되지 않는지 확인합니다.
- CLIENT1에서 http://web.lab.example.test:8080/을 엽니다.
HTTP의 호스트 헤더는 보안상의 사용자 인증이 아닙니다. 허용된 이름을 안다고 사용자를 신뢰하는 방식으로 사용하지 않습니다. 이름을 지정한 뒤 IP 주소로 접속하면 같은 페이지가 나오지 않을 수 있으므로 이름 기반 사이트는 실제 이름으로 시험하세요.
변경 후 접속되지 않으면 DNS 조회 결과와 웹 요청을 구분합니다. 이름이 .30으로 해석되는지 확인한 뒤 포트·바인딩 이름을 비교합니다. 방화벽을 다시 전부 허용하거나 DNS를 공용 서버로 바꾸는 방식으로 해결하지 않습니다.
두 번째 사이트와 풀을 분리합니다
- 새 C:\Sites\StatusSite 폴더에 index.html을 만들고 첫 사이트와 구분되는 StatusSite 시험 문장을 적습니다.
- 새 풀 StatusSitePool을 만들고 관리 코드 없음·ApplicationPoolIdentity를 선택합니다.
- 해당 폴더에 IIS AppPool\StatusSitePool의 읽기 및 실행 권한을 부여합니다. 기존 SYSTEM·관리자 권한은 보존합니다.
- 새 사이트 StatusSite에 새 풀과 폴더를 지정합니다.
- 바인딩은 http / 172.24.50.30 / 8080 / status.lab.example.test로 지정합니다.
- StatusSite의 익명 인증 편집에서 응용 프로그램 풀 ID를 선택합니다.
- CLIENT1에서 두 이름으로 접속해 서로 다른 시험 문장이 나오는지 비교합니다.
IP와 포트가 같아도 서로 다른 호스트 이름으로 구분할 수 있습니다. 같은 프로토콜·IP·포트·이름을 두 사이트에 중복 등록하지 않습니다. 이름이 비어 있는 기본 수신 바인딩이 남아 있다면 어떤 요청을 받을지 함께 조사하세요.
두 사이트를 다른 풀에 배치하면 풀 재활용·중지나 계정을 구분하기 쉽습니다. 다만 같은 OS·커널·저장소를 쓰므로 별도 VM과 같은 보안 경계는 아닙니다. 풀 ID와 자원 접근 설명에 맞춰 각 콘텐츠에 필요한 최소 권한만 부여합니다.
풀 중지와 재활용의 영향을 확인합니다
- 두 사이트가 정상인 시점과 풀 상태를 기록합니다.
- 실습 전용 StatusSitePool만 중지합니다.
- status 주소와 web 주소를 각각 새 요청으로 확인해 차이를 기록합니다.
- StatusSitePool을 다시 시작하고 복구됐는지 확인합니다.
중지한 풀의 사이트에서는 503 등 서비스 불가 응답이 나올 수 있으며, 별도 풀인 LabSite는 계속 확인해야 합니다. 같은 호스트의 자원 고갈이나 공유 의존성까지 격리되는 것은 아닙니다. 사이트 중지와 풀 중지는 적용 범위가 다르므로 버튼을 누르기 전에 대상을 확인하세요.
재활용은 작업 프로세스를 새로 만드는 동작이며 앱의 메모리 상태·세션·진행 중 작업에 영향을 줄 수 있습니다. 정적 사이트의 간단한 관찰을 업무 앱의 무중단 보장으로 일반화하지 않습니다. 정리할 때 새 사이트·풀·DNS 레코드만 기록한 대로 제거하고, LabSite의 바인딩을 되돌릴지는 이후 HTTPS 실습 사용 여부를 보고 결정합니다.
