企业官网建设流程全解析

简介：面向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 装个 IIS

2.1 先搞明白这个标题里的“Web 服务器”到底指什么

很多人一看到“Web 服务器搭建”就默认是 Apache 或 Nginx。但在 Windows Server 2022 的世界里，Web 服务器主要指启用IIS（Internet 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 Allow

Direction 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 盘塞满

现象：某天早上站点突然从外部访问不到了，登录系统检查发现系统盘可用空间为 0，IIS 无法写日志所以拒绝继续处理请求。

原因：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-Net45

Web-Asp-Net45是 .NET 4.5 及以上版本的 ASP.NET 支持模块。装完之后重启 IIS（iisreset命令），再刷新页面，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 Cert"

DnsName决定证书里写入的域名，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 让用户只能走 HTTPS：URL 重写与站点级的 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 服务跑起来。

本文还有配套的精品资源，点击获取