Windows Server 2025 / 为两个站点配置 IIS 绑定和应用程序池

IIS 绑定通过协议、IP 地址、端口和主机名选择站点，应用程序池则组织应用的运行与进程标识。要收到正确页面，DNS、绑定、内容目录和应用程序池都需要相互匹配。

区分四个配置层次

DNS 记录将名称解析为地址，但不会创建 IIS 绑定；设置绑定也不会注册 DNS 名称。IIS 绑定参考文档解释了协议以及 IP、端口和主机信息。添加或编辑之前，应检查服务器所有站点中的现有组合，仅仅显示名称不同并不能避免冲突。

从WEB1 上已正常工作的 172.24.50.30:8080 LabSite、原目录和 LabSitePool 开始。继续使用相同的获准客户端，以及已限制为实验用途的 TCP 8080 规则。在 WEB1 以管理员身份操作，先记录完整绑定、路径、池分配与状态；在 DC1 使用适当的 DNS 管理权限。本课仅增加实验名称 web.lab.example.test 和 status.lab.example.test，不修改公共 DNS 或生产站点。如果 StatusSite、目录、池或记录已经存在，应确认用途并在替换之前停止。

添加并验证 DNS 名称

1. 在 DC1 打开 DNS 管理器 → 正向查找区域 → lab.example.test，确认它是该服务器已有的实验区域，而不是 ad.example.test。
2. 先查看 web 是否已存在 A、别名或其他记录。名称空闲时才创建新主机（A），名称 web，地址 172.24.50.30；不覆盖其他值。本次 HTTP 访问不要求 PTR。
3. 同样检查并创建 status，指向相同地址，将两个名称和数值记录为自己的实验对象。
4. 确认 CLIENT1 内部 DNS 使用 DC1，即 172.24.50.10。PowerShell 明确指定查询的服务器可能与浏览器实际使用的解析器不同。
5. 从 CLIENT1 查询两个名称，检查返回的地址记录。若错误或地址不符，先解决 DNS，不通过不正确的绑定修改来掩盖问题。

Resolve-DnsName web.lab.example.test -Server 172.24.50.10
Resolve-DnsName status.lab.example.test -Server 172.24.50.10

Resolve-DnsName 的 Server 参数指定查询的 DNS 服务器。两个名称都预期得到 A 记录 172.24.50.30；未指定 Type 时，命令默认查询 A 和 AAAA，因此不要为仅使用 IPv4 的实验编造 IPv6 响应。明确查询 DC1 不代表浏览器也使用它，还应检查客户端配置与通常的名称解析，再测试 HTTP。

lab.example.test 是课程的 DNS 实验区域，与 Active Directory 域 ad.example.test 分开。文件型区域不会因为服务器成为域控制器就自动复制到 DC2。区域缺失时，应先检查 DC1 与预期配置；不要因为名称相近而改在 AD 区域添加记录，也不要为继续实验而转换区域存储类型。

为第一个站点设置主机名绑定

1. 在 IIS 管理器 → LabSite → 绑定准确选择 http / 172.24.50.30 / 8080、主机名为空的项，编辑前记录原值。
2. 只把主机名改为 web.lab.example.test 并确认，保留 IP、端口、类型、路径与池。
3. 修改后检查是否存在相同的完整绑定组合，不额外增加不必要的空主机名副本。
4. 在 CLIENT1 打开 http://web.lab.example.test:8080/，预期仍是上一课的 LabSite 页面。核对 URL 与内容，而不只是看到某个响应。

HTTP 请求中的 Host 标头表示请求的名称，不会验证用户身份。知道 web.lab.example.test 不代表获得身份或额外权限。把空主机名改为指定名称之后，直接访问 IP 可能不再选中 LabSite；如果还有其他匹配绑定，也可能收到不同响应。应使用各站点预定的名称与端口测试。

发生故障时，先检查名称是否解析为 172.24.50.30，再把请求的协议、8080 端口和名称与实际绑定比较。页面错误时，也要查看无主机名绑定及所选目录的文件内容。DNS 正确并不能保证网络路径、防火墙、权限、身份验证和池都正确。不要改用公共 DNS 代替内部 DNS，也不要全面关闭防火墙。

创建使用独立标识的第二个站点

1. 只有目录不存在时才创建 C:\Sites\StatusSite，并保存独立的 UTF-8 index.html。可以复制上一课 LabSite 的完整 HTML 文档，只在这个副本把 title 和 h1 的文字改成 StatusSite，把段落改成 This page is served by StatusSite on WEB1.，保留 HTML 结构，不修改 LabSite 原文件，并确认实际扩展名。
2. 名称未使用时才创建 StatusSitePool，选择 No Managed Code 和 ApplicationPoolIdentity，不为省事而共用 LabSitePool。
3. 在新目录属性 → 安全中将位置选为 WEB1，添加 IIS AppPool\StatusSitePool，为目录与文件授予读取和执行、列出文件夹内容、读取，保留 SYSTEM 与管理员权限，不给 Web 进程写入或完全控制。
4. 在网站 → 添加网站创建 StatusSite，使用 C:\Sites\StatusSite 与 StatusSitePool，核对这三个值。
5. 绑定设为 http / 172.24.50.30 / 8080 / status.lab.example.test，不误用 web.lab.example.test，也不改用其他端口破坏比较条件。
6. 在 StatusSite 启用匿名身份验证，并选择应用程序池标识；确认默认文档已启用且包含 index.html，池与站点能够启动。
7. 从 CLIENT1 分别打开 http://web.lab.example.test:8080/ 与 http://status.lab.example.test:8080/，应显示 LabSite 和 StatusSite 的不同消息。如果相同，先检查绑定、路径和文件，再进行停止实验。

两个站点能够共享 IP 和端口，是因为本课 HTTP 请求的主机名不同。不要重复完整组合，也不要误把同一个主机名用于两个站点。检查残留空主机名绑定会接收哪些请求，不要在不了解用途时删除其他绑定。按名称区分站点不能代替身份验证，也不会自动完成 HTTPS 证书配置。

独立的池便于分别管理标识、停止与回收，但仍共享操作系统、内核、存储及主机资源。其边界不同于独立虚拟机，也不能保证任何过载都被限制在单个池内。应按应用程序池标识指南为各标识提供最小必要权限；StatusSitePool 不需要额外访问另一个站点的内容。

比较停止与回收应用程序池

1. 记录两个站点的正常响应、URL、时间、池分配及两个池的状态。没有基线时，原本已经发生的故障不能证明是停止某个池造成的。
2. 在 IIS 管理器 → 应用程序池仅选择 StatusSitePool 并停止，操作前再次核对名称，不停止 LabSitePool 或整个 IIS。
3. 从 CLIENT1 向两个名称发送新请求，避免把浏览器缓存页面当成服务器的新响应。在网络面板与日志中检查 HTTP 状态，并分别记录两个站点。
4. 选择 StatusSitePool → 启动，用新请求确认恢复，结束前也要再次验证 LabSite。

StatusSitePool 停止时，其站点可能返回 HTTP 503，而使用另一个池的 LabSite 预期仍正常响应。必须检查两边，不能把任意一个错误当作隔离已经生效的证明。如果两个站点都失败，应检查池分配、站点状态和共享资源。区分停止站点与停止池，本次比较不使用 iisreset，也不重启服务器。

回收应用程序池会替换工作进程，可能影响内存会话及正在执行的任务。IIS 支持回收触发条件与进程重叠设置，观察静态页面并不能保证应用服务没有中断。若要手动比较“回收”，应在两个站点都恢复后只操作 StatusSitePool，记录前后状态与请求，并在结束时复核两个页面；不要修改阈值或计划以制造故障。清理时只移除 StatusSite、确认没有其他应用使用后的 StatusSitePool、自己的可丢弃文件及新增 status 记录。若继续 HTTPS 实验，保留 LabSite 与 web 绑定；若在此结束，则恢复先前记录的原绑定，并检查依赖后仅移除自己的新增 DNS 记录，不删除区域或域记录。