Windows Server 2022上搭建IIS Web服务器：从安装到HTTPS配置完整指南

简介面向IT运维人员与系统管理员的Windows Server 2022 Web服务器搭建指南系统讲解从操作系统安装、服务器功能测试到挂载网站、配置域名解析的完整流程。内容源自实际部署经验依次展开服务器安装的七步操作包括安装介质准备、语言时区选择、许可协议确认、分区与格式化等并针对网络连接、硬件设备、操作系统三方面测试给出检查方法。在网站挂载环节详细说明创建网站目录、拷贝网站素材、修改端口与绑定域名等步骤强调端口不能重复使用等关键注意事项域名解析部分则介绍安装DNS服务器、配置DNS记录、实现网址与IP地址相互转换及解析测试形成从零到可访问网站的全流程闭环。资源为单个docx文档压缩包约1016KB内容分节清晰可当作操作手册按步骤查阅也适合初次接触Windows Server 2022或希望规范化部署流程的中级读者使用。已有2764人学习下载是快速落地Windows Server Web服务的实用参考资料。1. 我为什么在 2024 年还敢把 Web 服务搭在 Windows Server 2022 上如果你问十个人“Web 服务器用什么搭”九个半会回答“Linux Nginx”。这是实话但不是全部答案。某公司去年要把一套老旧的 .NET 业务系统从 Server 2008 迁出来我评估了一圈之后还是选了Windows Server 2022 的 Web 服务器方案也就是 IIS 10。当时旁边的人也觉得我疯了——放着 Nginx 不学去折腾一个“老古董”。真跑起来之后大家才发现IIS 10 没你想的那么弱而且 Windows Server 2022 那一堆新特性比如 QUIC 支持、默认 TLS 1.3放在内网业务场景里反而比 Linux 那一套省心得多。这篇文章就是把我这次搭建的过程完整拆开从装角色、建站点到配 HTTPS、调参数再到那些只有踩过坑才知道的细节。适合两类人看一类是公司里 Windows 环境占多数、被逼着要在 Server 上跑 Web 的运维另一类是想搞明白 IIS 和 Linux Web 栈到底差在哪里的开发。你不需要之前配过 IIS但最好对 DNS、端口、HTTP 这些基础概念有个大概印象。2. 选择与准备为什么是 Windows Server 2022 而不是随便拿台 PC 装个 IIS2.1 先搞明白这个标题里的“Web 服务器”到底指什么很多人一看到“Web 服务器搭建”就默认是 Apache 或 Nginx。但在 Windows Server 2022 的世界里Web 服务器主要指启用IISInternet Information Services角色。IIS 10 从 Windows Server 2016 开始就在内核层面支持 HTTP/2到 2022 版本又补上了 QUIC 协议的支持——就是在 UDP 上跑的类 HTTP/3 方案——以及更细粒度的动态压缩配置。我在做选型时对比过三个方向。第一个是 IIS 本身Windows 原生图形界面加 PowerShell 双重管理和 AD 域、组策略、Windows 防火墙深度打通第二个是在 Windows 上用 Docker 跑 Nginx 容器灵活是灵活但 Windows 容器和 Linux 容器的网络模型差异很大维护成本不低第三个是直接在 Windows 上装 Nginx 的 Windows 版这条路可以走但你放弃了 Windows 的服务管理集成、性能计数器、日志接入这些原生优势。对于多数企业内网业务——尤其是涉及 .NET、SQL Server 或者需要用 Windows 集成认证的系统——IIS 依然是成本最低的选择。它不是一个“强大的高性能 Web 服务器”但它是一个“和企业 Windows 环境融合得最好的 Web 服务器”。2.2 搭建前的系统准备网卡、防火墙、更新这三件事不能省拿到一台已经装好 Windows Server 2022 的机器后不要急着开 IIS 管理器。我一般按这个顺序做三件预处理第一件事确认计算机名和静态 IP。Web 服务器要求固定网络位置DHCP 分配的地址在租约到期之后换掉会让所有站点的 IP 绑定全部失效。在“设置 - 系统 - 关于 - 重命名此电脑”里设定一个有意义的主机名比如 web-prod-01。然后在网卡属性里把 IPv4 设置为静态地址同时写好 DNS 指向域控或公共 DNS。第二件事更新系统补丁。Windows Server 2022 的 IIS 组件有一些已知问题在累积更新里被修复比如某些情况下 HTTP/2 连接不释放的问题。我见过有人跳过更新直接搭站结果压测时连接数上不去排查半天才发现是系统版本太老。第三件事注册表里把 NIC 的电源管理关掉。这个比较少人提但对 Windows 服务器非常关键。在“设备管理器 - 网络适配器 - 属性 - 电源管理”里取消勾选“允许计算机关闭此设备以节约电源”。物理服务器上这个选项默认可能是开的一旦系统判定网卡空闲把它休眠了你的 Web 服务就彻底失联了。做完这三件事之后再装 IIS顺序不要反。2.3 安装 IIS 角色的两条路图形界面和 PowerShell 我都给你图形界面方式启动“服务器管理器”点“添加角色和功能”一路下一步到“服务器角色”这一步勾选“Web 服务器(IIS)”。它会弹出提示问你是否添加所需功能点“添加功能”继续。在“角色服务”这一步我通常保留默认的角色服务列表除非有特殊需要否则不额外勾选太多东西。PowerShell 方式一行命令搞定Install-WindowsFeature -Name Web-Server -IncludeManagementTools这里Web-Server对应 IIS 核心角色IncludeManagementTools会把 IIS 管理器控制台、PowerShell 模块这些管理工具一起装上。跑完这条命令之后用Get-WindowsFeature Web-Server确认状态是Installed。命令执行后检查结果安装状态列会从Available变成Installed。如果没有变成这个状态查看返回消息里的错误码最常见的错误是没联网导致无法从 Windows Update 拉取功能文件。2.4 装完先测默认站点确认 80 端口真的在提供服务装完 IIS 之后默认会在C:\inetpub\wwwroot生成一个默认站点绑定 80 端口。这时候我在浏览器里访问服务器本机的 IP如果能看到 IIS 默认的欢迎页说明整套基础链路是通的。这个默认页面测试是整条搭建流程里最好的起点检查。如果看不到页面别急着配置业务站点先排查基础问题。我是这么排查的第一步在服务器本地访问http://localhost能开说明 IIS 正常运行第二步换了另一台电脑访问http://服务器IP如果打不开大概率是 Windows 防火墙挡了入站 80 端口。放行端口用这条命令New-NetFirewallRule -DisplayName Allow HTTP 80 -Direction Inbound -Protocol TCP -LocalPort 80 -Action AllowDirection Inbound表示入站方向LocalPort 80限定端口范围Action Allow表示允许。这样防火墙规则就建好了默认站点应该就能从外部访问了。3. 把默认站点换成真正的业务站点绑定、物理路径与应用程序池3.1 应用程序池是什么、为什么要单独建在 IIS 的世界里应用程序池Application Pool是一个独立的进程边界。每个站点或每个应用都会被分配到一个池里池里的工作进程w3wp.exe负责处理 HTTP 请求。默认安装后有一个DefaultAppPool初始配置是 .NET CLR 版本 v4.0、托管管道模式为 Integrated。我不建议把所有站点都扔进DefaultAppPool。原因很简单一个池里的站点共享同一个进程其中一个站点代码崩溃或触发 CPU 占用过高时同池子的其他站点全部遭殃。生产环境里我习惯是“一个业务系统一个池”池名就用业务名命名比如oa-portal方便出问题时一眼定位。3.2 从零创建一个业务站点的完整操作假设我们要为某公司的 OA 系统搭建一个站点物理文件放在D:\Websites\oa域名先用内网地址oa.corp.local端口 80。先创建物理目录把.NET 项目发布后的文件放进去或者先放一个测试用的index.html验证链路。然后打开 IIS 管理器在左侧“网站”上右键 -“添加网站”。站点名填oa-portal应用程序池选择刚才新建的oa-portal池物理路径选D:\Websites\oa绑定类型http端口80主机名oa.corp.local。确定后站点就会出现在列表里。这里插一段独立的说明物理路径的权限是新手最容易忽略的。IIS 的工作进程默认使用IIS AppPool\oa-portal这个虚拟账号访问物理目录注意这个账号不是NETWORK SERVICE也不是IIS_USERS。如果你发现站点能启动但访问时提示401.3 未经授权访问被拒绝基本就是D:\Websites\oa目录没有给IIS AppPool\oa-portal读取权限。解决方式是右键目录 - 属性 - 安全 - 编辑 - 添加输入IIS AppPool\oa-portal至少给“读取”和“列出文件夹目录”权限。3.3 绑定Binding的三种写法IP、端口、主机名怎么配站点创建后在 IIS 管理器里能编辑“绑定”。这个绑定列表就是 IIS 接收请求的入口表一行绑定对应一个“IP:端口:主机名”三元组。三种写法的应用场景完全不同我快速讲一下。第一种是最常见的IP 地址 端口 主机名。比如10.10.10.5:80:oa.corp.local。这种写法的效果是当请求到达 10.10.10.5 的 80 端口并且 HTTP 请求头里的 Host 字段是oa.corp.local时这个请求才会被路由到oa-portal站点。其他 Host 头打到这个端口的请求IIS 会按照站点的优先级规则往下找找不到就返回 404。第二种是“全部未分配” 端口也就是不指定 IP所有网卡的这个端口都由这个站点接管。这种写法适合只有一台服务器、只跑一个站点的场景不用记 IP端口独占。缺点是想在同一个端口上再绑其他站点时就必须靠主机名来区分了。第三种是同一 IP 上用不同端口区分站点比如https用 443、API 服务用 8443。这种做法常见于开发环境生产环境不太推荐端口多了难维护。我平时调试时还会在绑定里临时加一条localhost的绑定方便本机测试不依赖 DNS。测试完了再删掉避免遗留没有用的绑定项造成混淆。3.4 快速验证站点生效的三种手段站点配置完之后我一般会做三个层级的验证。第一个层级是最基础的本机访问。在服务器上打开浏览器访问http://oa.corp.local要求能打开页面。如果打不开先看站点状态是否“已启动”再确认绑定里的主机名和访问地址一致。第二个层级是从另一台电脑访问。这时候 DNS 解析会接管一部分问题。oa.corp.local如果没在 DNS 服务器里建记录我就在客户端电脑的C:\Windows\System32\drivers\etc\hosts文件里临时加一行10.10.10.5 oa.corp.local来测试。生产环境不建议用 hosts 文件代替 DNS但排查时它是最快的“证明网络链路没问题”的手段。第三个层级是用命令行工具验证端口和请求状态。curl -I http://oa.corp.local-I参数表示只获取响应头不下载正文。返回HTTP/1.1 200 OK表示站点存活返回503 Service Unavailable说明站点停了或者应用程序池挂了这时去 IIS 管理器里看池状态返回502.3说明是网关错误多半是进程崩溃或超时。4. 常见问题与避坑记录我在 Windows Server 2022 Web 搭建中翻过的车4.1 默认文档没配置导致“目录浏览”暴露了物理路径现象访问站点根目录时没有弹出预期的首页反而列出了一个文件目录清单访客能看到物理目录里的所有文件名和目录结构。原因站点根目录没有配置默认文档Default Document。IIS 默认启用了目录浏览Directory Browsing当请求是目录路径且没有匹配到默认文档时它会直接把目录内容列出来给客户端看。我那次部署时忘了往站点里放index.html又把默认文档列表里的条目删了结果直接裸奔了出来。解决IIS 管理器里选中站点双击“默认文档”确保index.html、Default.htm、Default.asp这些常用文件名在列表里并且顺序符合你的需求。同时务必将“目录浏览”功能设置为禁用。顺序也是很重要的知识点IIS 会从上到下按顺序匹配默认文档第一个存在且可读取的文件就会当作首页响应给客户端。4.2 应用程序池回收导致凌晨线上服务闪断现象某业务系统总是在凌晨 3 点到 4 点之间出现偶发的 503 错误白天一切正常。查看事件日志发现对应应用程序池在这段时间被回收了。原因IIS 的应用程序池默认设置了“定期回收”机制默认触发条件是“在以下时间回收应用程序池(分钟)”为 1740 分钟也就是约 29 小时回收一次。部署时间如果刚好卡在凌晨回收动作就会造成请求中断。更隐蔽的是某些业务应用在进程重启后需要重新加载缓存短则几秒、长则几分钟这期间所有请求都会失败。解决在生产环境里我一般把“特定时间回收”设为每天凌晨非业务时间段比如 03:00 执行一次并且勾选“回收应用程序池时终止所有正在运行的进程”并设置合适的“限制回收时间”。关键是主动规划回收窗口而不是让系统随机触发。设置路径是“应用程序池 - 右键选中你的池 - 回收 - 特定时间”。改成定期固定时间之后凌晨闪断的问题就不再出现了。4.3 日志文件把 C 盘塞满现象某天早上站点突然从外部访问不到了登录系统检查发现系统盘可用空间为 0IIS 无法写日志所以拒绝继续处理请求。原因IIS 默认把访问日志写在C:\inetpub\logs\LogFiles默认按天一个文件。业务量大的时候一天能写几个 GB 的日志不加控制的话 C 盘迟早被填满。我当时监控不到位等到磁盘满了才发现。解决首先尽快清理磁盘空间删除过期日志文件释放空间恢复服务。然后是长期方案把日志目录挪到独立的数据盘并且部署日志轮转策略比如保留最近 30 天的日志更早的自动删除。IIS 本身没有内置“按大小自动清理”的能力我可以结合 Windows 计划任务定期执行清理脚本。$logPath D:\Logs\W3SVC* $cutTime (Get-Date).AddDays(-30) Get-ChildItem $logPath -Recurse -File | Where-Object { $_.LastWriteTime -lt $cutTime } | Remove-Item -Force这段脚本是查找日志目录下 30 天前修改过的文件并删除。$cutTime定义过期线Get-ChildItem加Recurse参数是遍历所有子目录因为 IIS 日志按站点 ID 分目录存放。把这个脚本加到 Windows 计划任务里每周跑一次日志目录就永远保持在可控大小内。4.4 Windows 防火墙规则冲突导致外部请求被随机丢弃现象防火墙规则里已经明确放行了 80 端口浏览器访问服务器的 IP 却时好时坏有时通有时不通重启 IIS 之后短暂恢复过一会儿又不行了。原因Windows 防火墙里同时存在多条规则可以匹配 80 端口的入站流量其中有“允许”的规则也有之前调试时留下的“阻止”规则。Windows 防火墙在处理入站连接时拒绝规则的优先级高于允许规则所以即使有允许规则存在碰到另一条阻止规则的匹配范围落在该 IP 上时请求一样会被丢弃。解决在“高级安全 Windows 防火墙”里按端口筛选出所有入站规则逐一检查“操作”列。把调试时加的那条“阻止”规则禁用或删除只保留有意义的“允许”规则。以后调试网络的连通性问题时先过一遍 “规则列表里是否存在阻止规则”这个检查项比反复重启服务要有效得多。4.5 忘记安装 ASP.NET 相关角色导致网页返回 500.19现象部署了一个 .NET 的 Web 项目请求页面时浏览器返回 500.19 错误错误代码后面跟着0x8007000d提示配置文件存在问题。配置文件明明是从开发环境原样复制过来的语法也检查过。原因IIS 的核心 Web 引擎装好了但是动态脚本处理组件没装。角色服务里需要勾选对应的 ASP.NET 版本组件才能让 IIS 识别和处理 .NET 应用的请求。只装了 Web-Server 核心角色就相当于一台只能跑静态文件的服务器壳子。解决在服务器管理器的“删除角色和功能”里重新打开安装界面在“角色服务”步骤勾选对应的动态内容模块。Install-WindowsFeature Web-Asp-Net45Web-Asp-Net45是 .NET 4.5 及以上版本的 ASP.NET 支持模块。装完之后重启 IISiisreset命令再刷新页面500.19 就变成了正常响应。这类问题排查时别先盯着代码先确认动态脚本引擎装全了没有。5. 把 HTTP 升级成 HTTPS证书申请、绑定替换与强制跳转5.1 证书从哪里来自签名、内网 CA 还是公网证书生产环境里的 Web 服务器HTTPS 已经是不需要讨论的默认项了。在 Windows Server 2022 上配 HTTPS 之前第一步是确定证书来源三种来源适用场景完全不同。自签名证书适合开发测试环境自己用 PowerShell 生成浏览器会报“不受信任”但测试链路够用了。生成命令New-SelfSignedCertificate -DnsName oa.corp.local -CertStoreLocation cert:\LocalMachine\My -FriendlyName OA Portal Test CertDnsName决定证书里写入的域名CertStoreLocation指定安装到本机证书存储的“个人”文件夹下。然后用Cert:\LocalMachine\My路径找到刚生成的证书把它导入到“受信任的根证书颁发机构”存储中本机访问时就不会再有任何提示了。内网 CA企业证书服务适合内网多个服务器需要统一信任链的场景。由某公司内部的证书颁发机构统一签发客户端电脑加入域后自动信任该 CA不会有任何弹窗。这个方式需要提前搭好证书服务但后续每台服务器的证书申请、续期都变得非常省事。公网证书适合服务器需要被互联网直接访问的场景。找正规证书服务商按域名申请然后把签发的证书导入服务器后配置到 IIS 站点绑定上。5.2 IIS 里绑定 HTTPS 和处理证书私钥过期问题拿到证书文件后一般是.pfx或.crt.key的组合把证书导入到 Windows 证书存储。双击.pfx文件按向导导入即可录入时注意勾选“允许在将来导出”这个选项不加的话证书备份会很麻烦。打开 IIS 管理器选中站点右键“编辑绑定” - 添加 - 类型选https端口443主机名填你的完整域名SSL 证书下拉列表里选择刚导入的证书。确认后站点就同时监听 80 和 443 了。这里有一个我踩过的坑证书的私钥在导入后被标记为“不可导出”导致后来做灾备迁移时发现导不出私钥只好重新申请证书。现在我的习惯是导入后立刻用certlm.msc打开“本地计算机证书”控制台找到证书右键导出一次验证私钥导出的可行性能导出来再放到生产上。5.3 让用户只能走 HTTPSURL 重写与站点级的 HTTP 到 HTTPS 跳转给站点配好 HTTPS 之后老用户访问http://oa.corp.local还是会直接打开 80 端口的内容除非我们把 HTTP 请求全量重定向到 HTTPS 上否则密码明文传输的通道就依然存在。IIS 里最干净的方式是用URL 重写URL Rewrite模块。它默认不在 IIS 安装包里需要单独下载安装。装完之后在站点根节点下双击“URL 重写”添加一条规则名称Redirect HTTP to HTTPS匹配 URL模式(.*)条件输入{HTTPS}与off匹配操作重定向到https://{HTTP_HOST}/{R:1}重定向类型301 永久重定向我补充一下这里的逻辑条件部分是检查当前请求是不是没走 HTTPS如果是就触发重定向动作。{HTTP_HOST}保持原请求里的域名避免多域名站点跳错地方。{R:1}对应匹配模式里的(.*)也就是原来的路径保证路径不丢。301 是永久跳转对搜索引擎友好用户浏览器也会缓存这个跳转结果以后直接输入域名也会自动走 HTTPS。配置完成后用浏览器测试一遍http://oa.corp.local确认 URL 变成了https://oa.corp.local且证书无报错。同时把前端的链接全部改成 HTTPS避免混合内容警告。6. 日常验证与常见实测技巧如何确认这台服务器一直健康整台 Web 服务器搭完后我习惯用几个固定的检查动作来确认它的健康状态不只是“能不能打开页面”这个表面指标。第一个技巧是用性能监视器Performance Monitor盯三个关键计数器Web Service(_Total)\Current Connections当前连接数、Web Service(_Total)\Bytes Total/sec总吞吐字节、W3SVC_W3WP(*)\% Processor Time工作进程 CPU 占用率。Windows Server 2022 的 PerfMon 可以把这些计数器的数据输出到日志文件保存方便出问题时回溯。我见过太多 “刚才还好好的” 情况有历史数据才能定位是流量突增还是代码死循环。第二个技巧是养成用命令行诊断的习惯出了状况不用打开一堆控制台窗口。检查站点状态用Get-Website Get-IISSiteBinding -Name oa-portal第一行查看所有站点的状态和绑定信息第二行针对单个站点查看绑定明细。查询结果里State字段显示Started才是正常绑定列表里protocol是https的条目确认端口和证书状态。第三个技巧是定期检查事件查看器里的 IIS 相关日志。Windows Server 2022 的 IIS 错误信息会写入 Microsoft-Windows-IIS-Configuration 管理事件日志以及应用程序日志里的 ASP.NET 来源。写一个简单的计划任务定时收集最近 24 小时的事件日志并落成文件可以为每周的巡检节省大量时间。我从第一次搭 IIS 到现在已经踩了不少坑最大的教训是Windows Server 的 Web 服务很大一部分问题出在“组件没装全”和“权限没给对”上出问题先查这两块能省下一大半的排障精力。另一个习惯是每次拿到新服务器都先把默认站点的目录浏览关掉这个动作我建议你也养成等出了问题再想起来就晚了。希望这篇笔记能帮你在 Windows Server 2022 上顺顺当当地把 Web 服务跑起来。本文还有配套的精品资源点击获取