很多刚接触Windows服务器的人，第一次听说IIS都是一脸懵——这到底是个什么东西？为什么别人让我装个网站动不动就说“开一下IIS”？其实说白了，IIS（Internet Information Services）就是微软Windows系统里自带的Web服务组件，装上它，你的Windows机器就能像Linux上的Nginx或Apache一样对外提供网页访问。尤其在企业内网、Windows/.NET技术栈、或者你手上只有一台Windows Server又不想额外折腾Docker的时候，IIS就是最省事的方案。
这篇我把自己这些年装IIS、配IIS、被IIS各种报错折磨的经验完整梳理一遍。不光是“下一步下一步”的安装向导，还包括装完之后必做的验证、你大概率会遇到的权限和配置文件报错、以及怎么把第一个网站真正跑起来。无论你是刚入行的运维、需要自己搭测试环境的后端开发，还是公司里兼职管服务器的IT，按这篇走一遍都能把IIS从零到落地摸通。
1. 为什么我建议新运维先把IIS装明白
先别急着点安装向导，我想先花点时间说说选型的事。总有人问：现在都是Nginx和Docker的天下了，还有必要学IIS吗？我的回答是：要看你在什么环境里干活。
如果你所在的公司是典型的Windows生态——AD域控、Exchange、SQL Server、SharePoint——那IIS根本绕不开。微软系产品对IIS的依赖是写进架构里的，很多企业应用在部署文档里第一行就是“请先安装IIS功能”。再加上.NET Framework和ASP.NET相关的老系统，只有IIS才能跑得最省心。虽然Kestrel可以独立托管.NET应用，但企业要的往往是Windows集成认证、应用程序池隔离、图形化管理这些能力，IIS依然是生产环境的默认选择。
反过来，如果你的业务是纯静态站点、前后端分离的Node.js应用、或者容器化微服务，那确实不一定需要IIS。Nginx在并发性能和配置灵活性上有优势，Docker则让环境一致性变得很简单。但即便是这些场景，IIS也可以作为一个边缘入口做反向代理。我见过不少混合架构，外层Nginx转发，内层IIS承载Windows集成认证的旧系统。
所以我的建议是：不要抱着“这技术过时了”的心态跳过IIS。它不是你想象中的上古遗留物，到今天依然是Windows平台上部署Web服务最权威、最标准、和系统层集成最深的方式。把这套东西装明白，本质上是搞懂了Windows服务器的角色管理、进程隔离、权限体系和安全模型的一整套逻辑。
顺便辟个谣：IIS不是一个需要去官网下载的独立软件包，它是Windows操作系统内置的一项“功能”或“角色”。你不需要找什么“IIS安装包.exe”，只要在系统设置或服务器管理器里把对应功能勾上，系统就会从本地组件库里把文件装好。这个认知很多人搞错，导致到处找下载，浪费时间还容易中招。
2. 安装前先看清：系统版本、IIS版本与准备工作
2.1 不同Windows版本对应的IIS版本
IIS是跟着Windows版本走的，不同系统装出来的IIS版本和功能集有一些差异。装机之前先认清自己手上的系统是什么，避免照着别人的教程点了一堆结果发现选项对不上。
| Windows系统版本 | 对应IIS版本 | 常见使用场景 |
|---|---|---|
| Windows Server 2022 | IIS 10.0 | 最新服务器系统，生产环境主力 |
| Windows Server 2019 | IIS 10.0 | 目前存量服务器中占比很高 |
| Windows Server 2016 | IIS 10.0 | 老项目常见运行环境 |
| Windows 10 / 11 专业版/企业版 | IIS 10.0 | 开发调试、本机测试、演示环境 |
| Windows 10 / 11 家庭版 | 部分组件受限 | 建议升级系统版本或换专业版 |
判断系统版本很简单，按下Win + R，输入winver回车，弹窗里会显示完整的系统版本和内部版本号。服务器系统还能在“服务器管理器”首页看到当前OS信息。
这里提醒一下：家庭版Windows虽然也能看到“启用或关闭Windows功能”里的IIS条目，但有些子组件是缺失的，比如IIS管理器控制台在某些家庭版上无法使用。如果你是想本机做开发测试，建议至少用专业版。
2.2 安装前的环境检查清单
正式开始安装之前，花两分钟做这三件事，能让你后面少踩很多坑：
- 确认管理员权限：无论是图形界面还是命令行，装IIS都必须以管理员身份操作。普通用户账号在UAC弹窗时直接让你怀疑人生。
- 确认系统激活状态：未激活的Windows Server可能出现组件安装失败，或者装完IIS后服务无法启动。别问我怎么知道的，有一次我拿了个未激活的评估版Server 2019装了半小时，最后发现是激活状态的问题。
- 确认当前是否已安装IIS：有些系统镜像默认带了IIS，重复安装会浪费时间，也可能造成组件状态异常。检查方法很简单，在“服务”里找
World Wide Web Publishing Service（W3SVC），如果存在且启动类型是自动或手动，说明IIS已经装过了。也可以用命令行Get-Service W3SVC查看。
2.3 关于联网和系统更新源
图形界面从“服务器管理器”装IIS时，默认会从系统本地源或Windows Update服务器拉取组件文件。如果服务器处于内网隔离环境、没有配置WSUS（Windows Server Update Services）或者无法访问微软更新服务器，安装过程可能卡在“正在安装”很长时间甚至报错。
对于离线环境，两个办法：
一是提前准备好系统镜像，挂载后指定源路径。在服务器管理器里打开“添加角色和功能”时，向导会让你选“从服务器池中选择服务器”，这步不会触发下载；真正缺文件时，可以到“本地服务器”页面的“Windows更新”设置里指定备用源。
二是直接用命令行指定Source参数，这个后面在PowerShell章节细说。总的来说，先在软件源列表里确认能正常获取组件，再开始安装，能避免装到一半卡死的尴尬。
3. 图形界面安装全流程：服务器管理器与Windows功能两种路径
3.1 服务器系统：使用服务器管理器添加角色和功能
Windows Server系统的标准安装路径是：打开“服务器管理器” → 点击右上角“管理” → “添加角色和功能”。接下来会进入一个向导：
- “开始之前”页面直接下一步；
- “安装类型”选择“基于角色或基于功能的安装”；
- “服务器选择”确认选中的是本机；
- “服务器角色”这步是核心，勾选“Web服务器(IIS)”，弹出的“添加Web服务器(IIS)所需的功能”对话框直接点“添加功能”；
- “功能”页面如果有其他需要可以顺带勾选，比如“.NET Framework 4.8功能”、“Telnet客户端”之类，IIS本身不强依赖这些；
- 走到“Web服务器角色(IIS)”页面继续下一步，在“角色服务”列表里仔细勾选你需要的内容。
“角色服务”这一步很关键，很多人只勾了一个大项，结果ASP.NET用不了、管理工具也没有。我建议的常用组合是：
- 常见HTTP功能：默认全勾（静态内容、默认文档、HTTP错误等）；
- 运行状况和诊断：建议至少勾上“HTTP日志记录”和“请求监视”，排错必用；
- 应用程序开发：按需勾选。.NET应用对应勾“.NET Extensibility”和“ASP.NET”；历史遗留系统可能要勾“ASP”；CGI偶尔会用到；WebSocket协议是在现代应用里常用到的，建议勾上；
- 安全性：如果不需要单独配置SSL证书或URL授权，可以保持默认。等真正用到再回来补装；
- 管理工具：务必展开“IIS管理脚本和工具”和“IIS管理服务”，IIS管理器控制台就在这里。很多人装完找不到图标就是漏了这步。
勾完之后点“安装”，等待进度条走完，右上角会提示“安装成功”。不需要重启系统，但保险起见，如果提示需要重启的组件较多，可以顺手重启一次。
3.2 桌面级系统：控制面板的“启用或关闭Windows功能”
如果你用的是Windows 10/11开发机，路径完全不同，但也更简单：控制面板 → “程序” → “启用或关闭Windows功能”（也可以直接按Win + R输入optionalfeatures回车）。弹出的“Windows功能”窗口里找到“Internet Information Services”：
- 把“Internet Information Services”主项勾上；
- 展开它，勾选“万维网服务 → 应用程序开发功能”里的
.NET Extensibility 4.8和ASP.NET 4.8； - 再勾选“Web 管理工具 → IIS 管理控制台”；
- 确定后系统会自动配置，等待完成。
桌面版IIS装完之后，在开始菜单搜索“IIS”就能看到“Internet Information Services (IIS)管理器”。如果找不到这个管理器，多半是上面的管理控制台没有勾上，回去重新打开功能窗口补勾即可。
3.3 两种路径的适用性判断
很多教程告诉你服务器系统要这样装、桌面系统要那样装，但实际工作中还有个变通场景：你手里的Windows Server版本太老（比如Server 2008 R2），控制面板里其实也有“打开或关闭Windows功能”入口。这个功能面板在服务器系统上同样存在，只是入口藏得深一点，路径是“控制面板 → 程序和功能 → 打开或关闭Windows功能”。如果你不想走服务器管理器向导，也可以在这里直接勾IIS，效果等价。
我的经验是：生产服务器优先用服务器管理器，因为能看到更强的进度反馈和依赖检查；开发机或快速验证环境用optionalfeatures，点几下就完事，不用来回翻向导。
4. PowerShell与DISM批量安装：适合无人值守和脚本交付
如果你只需要在一台机器上装一次IIS，图形界面绰绰有余。但如果你要一次性交付几十台服务器，或者想在CI/CD流程里自动准备一台Web服务器，图形界面就完全不现实了。这时候PowerShell和DISM就是正解。
4.1 PowerShell安装IIS角色
以管理员身份打开PowerShell，执行：
Install-WindowsFeature -Name Web-Server -IncludeManagementTools这条命令的意思很直白：安装Web服务器角色，并且把管理工具（IIS管理器、命令行工具等）一并带上。-IncludeManagementTools这个参数建议每次都带上，否则装完连管理器图标都没有，还得手动补装。
如果只需要IIS核心引擎，不需要管理界面，可以简化为：
Install-WindowsFeature Web-Server4.2 常用子功能与安装参数
实际部署中常常需要按项目定制子功能，比如装完IIS还要支持ASP.NET。可以先用Get-WindowsFeature Web-*查看所有和Web相关的功能名称，然后按需组合：
Install-WindowsFeature -Name Web-Server, Web-Asp-Net45, Web-WebSockets, Web-Mgmt-Console -IncludeManagementTools常用功能名称对照表（这部分名称在Server 2016/2019/2022和Win10/11上基本一致，只是桌面版部分功能可能不可用）：
| 功能名称 | 作用 |
|---|---|
| Web-Server | IIS核心引擎 |
| Web-WebServer | Web服务器角色，通常和Web-Server互相关联 |
| Web-Static-Content | 静态内容托管 |
| Web-Asp-Net45 | ASP.NET 4.5/4.8支持 |
| Web-Net-Ext45 | .NET扩展性支持 |
| Web-WebSockets | WebSocket协议支持 |
| Web-Mgmt-Console | IIS管理器图形界面 |
| Web-Mgmt-Tools | IIS管理脚本和工具 |
| Web-Http-Logging | HTTP日志记录 |
| Web-Request-Monitor | 请求监视器 |
| Web-Http-Errors | HTTP错误页 |
| Web-Default-Doc | 默认文档（默认页） |
| Web-Dir-Browsing | 目录浏览 |
4.3 DISM方式的补充
如果你的Windows镜像本身比较精简，或者PowerShell的Install-WindowsFeature在当前系统上不可用（比如某些Win10精简版移除了服务器管理器模块），可以改用DISM：
dism /online /enable-feature /featurename:IIS-WebServerRole /featurename:IIS-ManagementConsole /allDISM的注意点是它不会自动把依赖项抓全，有时候你需要先开IIS-WebServerRole再开其他子功能。/all参数表示启用所有父功能，这个参数建议保留。
4.4 离线环境指定源路径
前面提到的离线环境问题，在PowerShell里可以通过-Source参数指定安装源，比如：
Install-WindowsFeature Web-Server -Source D:\sources\sxs -IncludeManagementTools这个D:\sources\sxs就是系统安装镜像里sources\sxs文件夹的解压路径。离线部署时，先把安装镜像ISO挂载到服务器上，再把这个参数指过去，就能正常安装，这也是批量交付时最稳的方式。
5. 装完别急着用：验证环境、认识IIS管理器、放行防火墙
5.1 三步验证IIS是否真正可用
装完IIS后，我习惯用以下三步确认环境是好的，而不是直接丢一个网站上去然后一脸懵地排查：
第一步，打开浏览器，访问http://localhost。如果出现IIS默认欢迎页（那个“Windows Server”或“Internet Information Services”的蓝色页面），说明核心服务已经正常启动。这一步也顺带验证了IIS默认站点Default Web Site的状态。
第二步，打开“服务”管理器，确认World Wide Web Publishing Service的状态是“正在运行”，启动类型是“自动”。如果服务没起来，八成是端口被占用或配置文件有问题，这种问题越早发现越好排查。
第三步，用命令行查看站点监听状态：
netstat -ano | findstr :80如果能看到LISTENING状态且进程PID对应的进程是System或w3wp.exe相关进程，说明80端口已经在正常监听了。看到这个结果心里就有底了——IIS真的装好了，不是在装样子。
5.2 认识IIS管理器的核心界面
打开IIS管理器，左侧是“连接”面板，顶部是当前服务器节点，展开后能看到“应用程序池”和“网站”两个核心目录。中间区域是功能视图，按模块组织的，比如“ASP.NET”、“IIS”、“管理”等分组。右侧是“操作”栏，所有针对当前选中对象的快捷操作都在这。
几个必须记住的位置：
- 应用程序池（App Pool）：每个网站运行时的进程隔离容器。你把鼠标点到一个网站名称上，右侧操作栏里才有“基本设置”和“应用程序池”。不同的网站可以分配到不同的池，互相隔离，一个崩溃不影响另一个。
- 默认站点：安装后自动生成，物理路径在
C:\inetpub\wwwroot。这个目录就是IIS的网站根目录的默认位置。 - 配置存储：IIS的配置集中在
C:\Windows\System32\inetsrv\config下的applicationHost.config，里面是全局配置。没事不要手动改，改错了整个IIS可能起不来。后续遇到一堆报错都和这个目录的权限有关。
5.3 防火墙放行HTTP/HTTPS端口
IIS装好后，很多人在本机能访问，但局域网其他电脑访问不了，第一个想到的往往是IIS配置错了。实际上大部分情况是Windows防火墙默认拦截了80端口。
打开“Windows Defender防火墙高级安全”，点“入站规则” → “新建规则” → 选择“端口” → 协议选TCP、端口填80,443→ 允许连接 → 应用到所有配置文件。或者直接用命令行：
netsh advfirewall firewall add rule name="IIS HTTP 80" dir=in action=allow protocol=TCP localport=80 netsh advfirewall firewall add rule name="IIS HTTPS 443" dir=in action=allow protocol=TCP localport=443这里特别提醒：如果你用的是云服务器（阿里云、腾讯云等），光改服务器内的防火墙不够，云控制台里的“安全组”也要放行对应端口。每次我在云服务器上排查半天发现是安全组没放开，都想抽自己。
防火墙放行之后，在另一台电脑浏览器输入服务器的IP地址，能看到IIS欢迎页，说明网络层全通了。到这一步，IIS安装才算真正画上句号。
6. 高频报错排雷：0x80005000、administration.config、.NET 8缺失
装了这么多年IIS，我总结出一个规律：安装过程本身顺顺利利的人，反而会在装完之后被各种报错折腾得够呛。下面这三个是搜索量最高、也最折磨人的，我把完整排查思路写出来，你照着链路走，能比自己瞎试省一天时间。
6.1 应用程序池权限设置失败：未知错误(0x80005000)
先描述一下这个报错的典型场景：你在IIS管理器的“应用程序池”里选中一个池，点右键“高级设置”，想改“标识”（Process Model → Identity）为LocalSystem或自定义账号，结果弹窗报错：“请手动为其设置localsystem权限未知错误(0x80005000)”。这个报错把我当年气得够呛，因为这问题不是你的操作不对，而是IIS管理器在读写配置时出了问题。
0x80005000这个错误码，从我的排查经验看，最常见的根因是系统时间异常。AD域环境里，如果服务器时间跟域控时间偏差太大，Kerberos认证会失败，任何对配置库的写入操作都可能报这个错。不少公司内网服务器没配好时间源，跑着跑着时间就漂移了。
完整排查链路建议这样走：
- 第一，检查系统时间。用
w32tm /stripchart /computer:ntp.aliyun.com（或者你的内网时间服务器）对比时差，差超过5分钟就先用w32tm /resync强制同步一次。 - 第二，检查事件查看器。打开“Windows日志 → 系统”，过滤来源为
Schannel或Krb5的错误事件。如果有大量Kerberos相关的错误，那基本锁定时间或域认证问题。 - 第三，还是报错就检查配置目录权限。IIS管理器读写的是
C:\Windows\System32\inetsrv\config，如果这个目录的NTFS权限被改过、或者Authenticated Users组失去读权限，也会报类似错误。右键该文件夹 → 属性 → 安全 → 确认Authenticated Users至少要有“读取和执行”权限。 - 第四，如果前三步都不管用，直接绕开图形界面。用命令行修改应用程序池标识：
%windir%\system32\inetsrv\appcmd.exe set apppool "DefaultAppPool" /processModel.identityType:LocalSystem命令行能改成功说明配置文件本身没坏，只是IIS管理器的权限交互有问题；命令行也失败，那就要考虑修复.NET Framework或者修复安装IIS了。
6.2 “执行此操作时出错，文件名：C:\Windows\System32\inetsrv\config\administration.config”
这个报错比上面那个还常见，通常是在IIS管理器里做任何操作时弹出来的（比如启动默认网站），报错信息末尾会带着配置文件路径...\config\administration.config。第一次见到的时候我还以为IIS安装损坏了，差点重装系统。
这个报错的根源几乎都指向IIS配置目录权限异常或配置文件被锁定。IIS管理器启动时会读取administration.config和applicationHost.config，一旦读不到或没有权限，就会以这种形式弹错。
排查步骤：
- 第一步，先检查文件是否存在。资源管理器进入
C:\Windows\System32\inetsrv\config\，看看administration.config文件在不在。不在就从别的同系统版本机器上拷一份过来，或者用DISM修复系统文件。 - 第二步，检查文件的访问权限。右键
administration.config→ 属性 → 安全，确认SYSTEM和Administrators有完全控制权限。如果是Authenticated Users权限丢失导致IIS管理器无法读取，可以用icacls命令重置：
icacls C:\Windows\System32\inetsrv\config\administration.config /grant "SYSTEM:(F)" "Administrators:(F)" "Authenticated Users:(RX)"- 第三步，如果权限没问题，考虑是否有第三方软件在占用。杀毒软件或安全软件经常会把IIS的配置文件目录列入防护名单，导致IIS管理器无法正常读写。把
C:\Windows\System32\inetsrv目录加入杀毒软件白名单再试。 - 第四步，尝试命令行工具看能否绕过IIS管理器：
%windir%\system32\inetsrv\appcmd.exe list sites如果appcmd命令能正常返回网站列表，说明IIS引擎本身是健康运行的，问题出在IIS管理器的配置交互上。这种时候的终极解决手段是把IIS管理器组件卸载重装一次（还是在“启用或关闭Windows功能”里操作），配置文件不用删，管理器重新注册一遍通常就好了。
6.3 新装了.NET 8，IIS里却没有ASP.NET Core Module
现在的.NET生态有个高频场景：你在服务器上装了.NET 8 Hosting Bundle（所谓“托管捆绑包”），系统也提示安装成功，但打开IIS管理器看模块列表，找不到AspNetCoreModuleV2，发布上去的.NET网站直接返回502.3或500.19。
这个坑的本质是安装顺序和模块注册问题。.NET Core Hosting Bundle在安装时会向IIS注册原生模块，但如果你在装Bundle之前没装IIS，注册动作会被跳过。你实际上是“先装了.NET再装IIS”，方向反了。
解决办法：
- 重新运行一次.NET 8 Hosting Bundle的安装程序，选择“修复”或“卸载后重装”，安装程序会检测到IIS环境并重新注册模块。
- 重装完执行
iisreset重启IIS服务，然后重新打开IIS管理器，在“模块”里确认有AspNetCoreModuleV2。 - 另外，IIS管理器的“应用程序池”里，.NET 8网站的池的“.NET CLR版本”建议设置为“无托管代码”，因为.NET 8应用自己是独立运行时的，不需要IIS托管CLR。这是很多人忽略的点：选了
.NET CLR版本 v4.0反而会报错，选“无托管代码”才正确。
6.4 为什么你的站点总是403.14或404
这两个报错其实不是IIS安装问题，但只要建了站就会遇到，我顺手一起说了。
- 403.14：IIS默认禁止目录浏览，如果你的站点根目录下没有默认文档（
index.html或default.aspx），访问http://服务器IP/就会报403.14。解决方法是确认根目录有默认文档，或者在IIS管理器“默认文档”里加上你的首页文件名。 - 404：文件放在别的盘符或外部目录，IIS进程（应用程序池身份）没有该目录的读取权限，就会返回404而不是403。解决办法：在网站的“物理路径”指向的目录上，给
IIS_IUSRS组添加读取权限，操作方法是在资源管理器里右键文件夹 → 属性 → 安全 → 编辑 → 添加 → 输入IIS_IUSRS→ 给予“读取和执行”权限。
7. 把网站真正跑起来的完整流程：创建站点、绑定、权限与备份还原
7.1 准备站点文件和物理路径
不管你是要部署.NET应用、还是Unity WebGL导出的纯静态页面、或者就是一个最简单HTML测试页，先把文件放到位。我习惯把站点目录和系统盘分离，比如放在D:\WebSites\MySite，好处是系统盘崩了重装不丢网站文件，也方便直接备份目录。
文件放好后，在IIS管理器左侧“网站”上右键 → “添加网站”。界面上的几个字段要理解透了再填，别乱来：
- 网站名称：只是个标识，和实际绑定的域名/端口无关，随意但有意义就行。
- 应用程序池：默认会创建一个同名的新池。如果已有想要的池，可以直接选。
- 物理路径：指向你的站点文件目录，这里要注意别只填根目录，如果你希望
http://ip/直接打开站点，路径就要指向含默认文档的那一层。 - 绑定类型：HTTP对应80端口，HTTPS对应443端口。刚开始测试用HTTP就行。
- IP地址：默认“全部未分配”即可，意思是服务器上所有IP都能访问这个站点。
- 端口：默认80。如果你同一台机器要跑多个网站，可以用不同端口区分，比如
:8080。 - 主机名：也就是域名。内网测试没域名可以留空，留空就是通过IP访问；填了域名就只允许通过该域名访问（需要在DNS或hosts里解析）。
7.2 给网站配置好默认文档和目录权限
添加完站点后，如果直接访问出现403.14，按前面说的去处理默认文档。IIS的默认文档优先级是Default.htm、Default.asp、index.htm、index.html、iisstart.htm，没有你要的首页就手动添加。
目录权限这一步特别容易被跳过。很多开发者在本地开发时用的是管理员账号，文件权限随便改，但IIS的应用程序池身份默认是ApplicationPoolIdentity，一个低权限账号。你直接把整个网站目录从开发机复制到服务器，没有单独给IIS授予权限，网站就会各种404或403.19。
最省事的授权方式：右键网站文件夹 → 属性 → 安全 → 编辑 → 添加 →IIS_IUSRS→ 勾选“读取和执行”、“列出文件夹目录”、“读取”权限。这就够了，不需要给Everyone，也别给写入权限，减少安全风险。
如果网站需要写日志或上传文件，单独给对应的子目录（比如/logs、/uploads）额外添加修改和写入权限即可。全开权限虽然能跑，但是把整个站的安全等级拉低了。
7.3 HTTPS绑定和证书配置
现在部署新站点，强烈建议直接上HTTPS，即使内网访问用自签名证书也比裸HTTP强。IIS里绑定HTTPS证书的操作路径是：选中站点 → 右侧“绑定” → 添加 → 类型选https→ 端口443 → 选择SSL证书。如果服务器上没有证书，先通过“服务器证书”模块导入或创建自签名证书，再回来绑定。
自签名证书在浏览器上会提示不安全，但内网测试可以接受。生产环境建议用正规CA签发证书或者内网部署企业CA。这个流程不复杂，但优先级值得排在建站最开始，因为半路再切HTTPS还要改站点内的绝对路径引用，麻烦。
7.4 站点上线后的备份与还原
站点上线以后，真正的运维压力才开始。IIS的配置、网站文件、应用程序池设置，这三样东西只要一个没了，恢复起来都要大半天。所以备份策略一定要现在就做，别等故障发生。
IIS自带的命令行工具appcmd.exe支持备份和还原IIS配置：
%windir%\system32\inetsrv\appcmd.exe add backup "PreUpdateBackup"这条命令会把applicationHost.config等配置打包到C:\Windows\System32\inetsrv\backup\PreUpdateBackup目录。需要还原时执行：
%windir%\system32\inetsrv\appcmd.exe restore backup "PreUpdateBackup"如果你改配置之前忘了备份，还可以用appcmd list backup看看系统有没有自动生成的历史备份（IIS默认会在某些操作前自动备份，比如用服务器管理器装角色时）。
网站文件层面，不要用系统自带的“备份服务器状态”那种大而全的东西，直接打一个压缩包把整个站点目录和相关数据库备份带走，这才是最实用的小备份策略。我见过太多人只备份了文件忘了备份配置，恢复完发现IIS管理器里面网站列表是空的。配置和文件要一起备份，二缺一等于没备份。
7.5 Unity WebGL项目部署到IIS的两个特殊点
如果你是用Unity做WebGL项目然后在Windows服务器上部署（这是目前挺常见的一个组合，很多公司内部工具和展示项目都这么干），有两个IIS配置是必踩的点：
一是MIME类型。Unity WebGL导出的文件里有.json、.js、.data、.wasm等后缀，IIS默认并不认识.json对应的MIME类型。你部署完访问页面显示404.3，大概率不是路径问题，而是IIS没把.json映射到正确MIME。解决办法：站点 → “MIME类型” → 添加：
| 扩展名 | MIME类型 |
|---|---|
| .json | application/json |
| .wasm | application/wasm |
| .data | application/octet-stream |
| .mem | application/octet-stream |
| .symbols.json | application/json |
| .unityweb | application/octet-stream |
二是“.dll文件被锁定”的问题。Unity WebGL项目虽然主要靠WebAssembly，但有时服务器上会有.NET相关的.dll，如果你用Debug模式构建然后频繁覆盖旧文件，IIS可能会因为文件被进程占用导致复制失败。解决办法是发布网站时先停止对应站点或应用程序池，再覆盖文件，覆盖完重新启动。这也是为什么很多人都强调“发布=停止站点→复制文件→启动站点”三步走的原因。
最后说两个装了这么多年才真正想明白的心得
第一个心得关于故障排查的顺序。IIS的报错信息往往很唬人，什么0x80005000、什么administration.config，看起来像天书。但实际排障不需要懂Windows内部，你只要记住一条铁律：先低后高、先网络后应用、先日志后猜测。先确认服务有没有启动、80端口通不通、防火墙放没放行；再看事件查看器里的系统日志和应用日志；最后才动手改配置。按这个顺序来，90%的IIS问题都能在三步之内定位。
第二个心得是给刚入行的朋友的建议。很多人上来就怼Docker、怼K8s，反而把IIS这种系统自带的基础能力忽略了。但实际上，Windows生态里的很多东西就是绕不开IIS的，与其到急用时才慌慌张张去搜教程，不如现在就找一台机器把安装、建站、改权限、对配置、备份还原这些流程全部走一遍。所有报错都在自己可控的环境里踩一遍，等线上出问题时，你才会有底气说一句：这问题我见过。
