1. IIS 到底是什么值不值得为它折腾一遍第一次接触 IIS 的朋友多半是被某个具体需求推着走的可能是公司内网要挂一个管理系统可能是前端同事扔给你一个 dist 压缩包让你“找个地方放一下”也可能是某个平台让你在网站根目录下放一个验证文件还特意叮嘱“申请提交前请勿关闭页面”。这时候你翻遍服务器发现上面已经装了 Windows Server桌面上没什么可用的 Web 服务软件那就只能把 IIS 请出来了。IIS 全称 Internet Information Services是 Windows 系统自带的 Web 服务器角色。注意是“角色”不是“软件”这四个字的差别很关键它不是一个独立安装包而是从系统组件里“开启”出来的一组服务包含 WWW 服务、管理控制台、FTP 服务、日志模块、请求筛选、压缩模块等一堆可以按需勾选的东西。你完全可以只装静态文件服务也可以把 ASP.NET、反向代理、URL 重写全部拉进来装多少取决于你要干什么。它最适合的场景其实很集中Windows 生态内部的 Web 托管。比如 ASP.NET / ASP.NET Core 应用、内网管理系统、静态前端产物、Unity WebGL 导出包、还有一些只提供 Windows 安装包的商业软件自带的 Web 端。反过来如果你要跑的是高并发公网业务或者团队里全是 Linux 运维习惯那 IIS 大概率不是第一选择。这中间没有谁高谁低只有合不合手。我见过太多人在第一步就卡住花了两个小时找“IIS 安装包下载”结果发现根本不需要下载。这个认知偏差本身就值得先说清楚后面安装环节会省掉大量无效搜索时间。1.1 一次典型的内网部署需求长什么样拿我最近处理过的一个场景举例一台 Windows Server 2019 的机器配置 4 核 8G装在一个不对外网开放的内网段里。需求很朴素——部署一个前端打包好的静态站点外加一个 Node.js 写的接口服务同时要支持 https 访问还要能让几个人同时在线用。这种需求如果用 Nginx你需要额外下载安装、配服务、写 systemd 或者注册 Windows 服务还得单独解决证书和日志轮转用 IIS 的话Web 服务器本身是系统自带的证书可以在图形界面里直接导入日志默认按天写在C:\inetpub\logs\LogFiles下谁来看都能看懂。对于“一次性交付、后续交给不太懂运维的同事维护”的场景图形界面 系统自带这两点价值比性能数字大得多。所以我一般会先把需求拆成三问第一访问者是内网还是公网第二后端是什么技术栈第三后续谁来维护。三个问题答完选型基本就定了。这套判断顺序比背参数表有用。1.2 IIS、Nginx、Tomcat 的取舍逻辑很多新手会把这三个混在一起比较其实它们的定位差别挺大的。IIS 是通用 Web 服务器Nginx 也是通用 Web 服务器但更偏 Linux 生态和反向代理Tomcat 是 Servlet 容器本质上是“跑 Java Web 应用的”当 Web 服务器用只是它的副业。对比维度IISNginxTomcat宿主系统WindowsLinux 为主Windows 版有但生态弱跨平台依赖 JVM配置方式图形界面 XML 配置文本配置为主XML 配置原生支持ASP.NET / ASP.NET Core静态资源、反向代理JSP / Servlet反向代理需装 URL Rewrite ARR内置配置简单可做但非强项上手门槛低界面引导强中需要理解配置语法中高需懂 Java 部署适合场景Windows 内网、.NET 应用高并发入口、容器化Java Web 应用我踩过的一个坑是在 Windows 上硬要用 Nginx 做主力结果证书自动续期、日志切割、开机自启这三件事全部要自己写脚本维护成本远超预期。后来换成 IIS同样的功能全是勾选项交付时的心理负担小太多。所以我的经验是在 Windows 服务器上除非团队有明确的 Nginx 技术沉淀否则优先 IIS反过来在 Linux 上就别硬塞 IIS 了。2. 动手之前版本对照与磁盘、账号规划安装 IIS 这件事真正的难点不在“装”而在“装之前想清楚”。我见过有人装完才发现系统是家庭版根本没有这个功能也见过有人把站点目录放在 C 盘根目录结果权限怎么调都不对。这些问题的根源都在准备阶段。准备阶段要做三件事确认系统版本能不能装、规划站点目录放在哪、想清楚站点用什么账号跑。这三件事加起来大概十分钟但能省掉后面两个小时。很多人急着点“下一步”最后都在权限报错里绕圈。顺便说一句热词里那句“win11 打开 iis 管理器”之所以被反复搜就是因为 Win11 家庭版根本没有 IIS 这个功能装不了也打不开。这不是操作问题是版本问题。所以第一步永远是查版本不是查教程。2.1 系统版本与 IIS 版本的对应关系IIS 版本是跟着系统走的不单独升级。这个表我建议直接截图存下来比每次现查快。操作系统自带 IIS 版本备注Windows 10 / 11 专业版、企业版、教育版IIS 10家庭版无此功能Windows Server 2016IIS 10服务器角色形式安装Windows Server 2019IIS 10目前内网部署最常见Windows Server 2022IIS 10组件更全推荐新项目用Windows 7IIS 7.5已不建议用于新项目这里有个很容易被忽略的点专业版和家庭版的差别在“可选功能”列表里。家庭版的“启用或关闭 Windows 功能”里根本找不到“Internet Information Services”这一项怎么搜都搜不到。所以如果你是个人电脑想练手先确认版本如果是公司机器直接问 IT 要 Server 系统更省事。另外提一句在某些精简版系统镜像上即使版本对IIS 组件也可能被裁掉了勾选时报“找不到源文件”。这种情况不用纠结换官方原版镜像是最快的路。2.2 目录结构与运行账号的规划站点目录我强烈建议不要放在 C 盘也别放在桌面或者用户目录下。原因有三一是 C 盘经常被安全策略限制写入二是用户目录的权限继承关系复杂三是备份的时候容易漏。我的习惯是在 D 盘建一个统一根目录D:\WebSites\ ├── _logs\ # 站点日志统一出口可选 ├── site-a\ # 站点 A 的物理路径 │ ├── index.html │ ── assets\ ├── site-b\ └── _backup\ # 发布前的旧版本备份这个结构的好处是所有站点平级权限一目了然备份直接打包D:\WebSites就行。_backup目录用来放上一版产物出问题可以秒回滚这个习惯我在生产环境救过自己不止一次。运行账号方面默认情况 IIS 会为每个应用程序池创建一个虚拟账号形如IIS AppPool\你的池名。这个账号是虚拟的不需要密码也不占系统用户列表权限最小是默认推荐方案。只有在必须访问网络共享、必须读注册表特定位置等少数场景下才考虑换成自定义账号。能用默认就用默认这是我在权限问题上的第一条铁律。2.3 安装前必须先看一眼的组件清单IIS 的安装是“按功能勾选”的勾少了后面要回来补勾多了增大攻击面。我按用途整理了一份常用清单照着勾基本够用静态站点必备Web 默认文档、静态内容、HTTP 错误、目录浏览可选、HTTP 日志性能相关静态内容压缩、动态内容压缩安全相关请求筛选、IP 和域限制管理相关IIS 管理控制台、IIS 管理脚本和工具反向代理必备URL 重写需单独下载模块、应用程序请求路由ARR需单独下载.NET 相关Web-Net-Ext45、Web-Asp-Net45、ISAPI 扩展、ISAPI 筛选器注意URL 重写和ARR不在系统自带组件列表里需要去官方模块页面单独下载安装。很多人对着功能列表找半天找不到就是因为这个。3. IIS 安装实操图形界面与命令行两条路准备工作做完就可以动手了。安装这条路我走过图形界面、PowerShell、服务器管理器三种入口结论是首次部署用图形界面批量部署用命令行。图形界面的好处是你能看到每一项勾选的位置出问题容易定位命令行适合已经熟悉组件名的人一条命令搞定但打错一个组件名就前功尽弃。下面的步骤我按系统分开写因为 Windows Server 和 Win10/Win11 的入口完全不同混着看会晕。另外安装完还有一个必做的验证动作很多人跳过这一步结果部署站点时才发现服务没起来。3.1 通过服务器管理器添加角色Server 系统在 Windows Server 2019 / 2022 上标准做法是走“添加角色和功能向导”打开服务器管理器点右上角“管理”菜单选择“添加角色和功能”。安装类型选“基于角色或基于功能的安装”下一步。服务器选择保持默认的本地服务器下一步。在“服务器角色”列表里勾选Web 服务器 (IIS)弹窗提示是否添加所需功能点“添加功能”。连续下一步到“角色服务”页面这里是勾选具体组件的地方按上一节的清单勾。确认页面勾上“如果需要自动重新启动目标服务器”然后安装。整个过程大概三到五分钟。安装完成后服务器管理器左侧会出现“IIS”节点说明角色注册成功。有个细节值得说“角色服务”页面是唯一需要认真看的一页其他页面直接下一步就行。我见有人在“功能”页面把 .NET Framework 全套都勾上结果平白多装了几百兆组件完全没必要。3.2 Win10/Win11 上开启 IIS 的正确姿势个人电脑上打开 IIS 走的是“可选功能”这条路入口有两个效果一样路径一控制面板 → 程序和功能 → 左侧“启用或关闭 Windows 功能”→ 勾选“Internet Information Services”。路径二按Win R输入optionalfeatures回车直接跳到同一个界面。展开“Internet Information Services”节点建议至少勾上这些子项Internet Information Services ├── Web 管理工具 │ ── IIS 管理控制台 ├── 万维网服务 │ ├── 常见 HTTP 功能 │ │ ├── 默认文档 │ │ ├── 目录浏览 │ │ ├── HTTP 错误 │ │ └── 静态内容 │ ├── 性能功能 │ │ ├── 静态内容压缩 │ │ └── 动态内容压缩 │ ├── 安全性 │ │ ├── 请求筛选 │ │ ── IP 和域限制 │ └── 应用程序开发功能 │ ├── .NET 扩展性 4.8 │ ├── ASP.NET 4.8 │ ── ISAPI 扩展 / 筛选器勾完点确定系统会自动拉取文件安装通常一到两分钟。装完打开方式很简单Win R输入inetmgr回车IIS 管理器就出来了。也可以在开始菜单直接搜“IIS”。如果搜不到回去检查是不是版本不支持。3.3 PowerShell 静默安装与无人值守脚本当你需要给十台机器装 IIS图形界面就太慢了。PowerShell 一条命令搞定这也是我后面做环境标准化时最常用的方式。Windows Server 上Install-WindowsFeature -Name Web-Server,Web-Mgmt-Console,Web-Static-Content, Web-Default-Doc,Web-Http-Errors,Web-Http-Logging,Web-Stat-Compression, Web-Filtering,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter -IncludeManagementToolsWin10 / Win11 上Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServerRole,IIS-WebServer,IIS-CommonHttpFeatures, IIS-StaticContent,IIS-DefaultDocument,IIS-HttpErrors,IIS-HttpLogging, IIS-ManagementConsole -All跑完可以用这条命令验证组件状态看State列是不是全部Enabled/InstalledGet-WindowsFeature -Name Web-* | Where-Object InstallState -eq Installed提示PowerShell 命令里的反引号 是续行符粘贴的时候注意别把空格带进去否则会报语法错误。这是个非常高频的粘贴事故。3.4 安装完成后的验证动作安装完别急着建站点先做三步验证能提前发现 90% 的安装问题第一步确认服务在跑。打开服务管理器找World Wide Web Publishing Service简称 W3SVC、Windows Process Activation ServiceWAS、IIS Admin Service这三个状态应该是“正在运行”。如果 W3SVC 没起来先手动启动看报什么错。第二步浏览器访问默认站点。打开http://localhost如果看到 IIS 的默认欢迎页说明 Web 服务本身没问题。看不到的话先看是不是 80 端口被别的程序占了。第三步查端口占用。这条命令是排查端口冲突的万能钥匙netstat -ano | findstr :80如果输出结果里有 PID再去任务管理器对一下是哪个进程。常见的占用者包括某些下载工具、数据库的 Web 控制台、其他 Web 服务软件。遇到“无法启动网站”的报错我第一反应永远是查端口第二反应才是查权限。4. 部署第一个静态站点从空目录到浏览器能打开安装环节走完接下来就是重头戏——把站点真正跑起来。这一节我用一个最小可复现的静态站点走完整流程末尾会给一份可以对照检查的清单。之所以强调“最小”是因为很多教程一上来就讲多站点、讲 SSL、讲负载均衡新手照着做必然在某一步卡住。静态站点部署的核心链路只有四个动作准备目录 → 新建站点 → 配权限 → 配默认文档。四步做完浏览器能打开这件事就成了一半。剩下的一半是各种边界情况的处理比如 MIME 类型、跨域、缓存策略这些我放到后面章节讲。4.1 站点目录怎么摆先在D:\WebSites\site-a下放一个index.html内容随便写点什么只要能区分出来就行!DOCTYPE html html langzh-CN head meta charsetUTF-8 title站点 A/title /head body h1站点 A 已部署成功/h1 p部署时间2024-01-01/p /body /html目录结构保持简单不要有多余的层级。有人习惯把站点放在D:\WebSites\site-a\dist\public\这种深路径下物理路径填长了一旦写错排查起来非常费劲。物理路径尽量扁平这是我多年来的习惯站点根目录直接对应打包产物的根。4.2 新建站点与绑定设置打开 IIS 管理器左侧展开服务器节点右键“网站”→ “添加网站”填三个关键项网站名称建议用英文 短横线比如site-a。中文名在命令行里操作时容易出编码问题。物理路径D:\WebSites\site-a。绑定类型httpIP 地址选“全部未分配”或者指定内网 IP端口填 80。填完点确定站点就出现在左侧列表里。这里有几个选择需要解释一下为什么为什么端口先填 80因为 80 是 HTTP 默认端口浏览器访问不用带端口号验证最直接。如果 80 被占用可以先用 8080 之类的端口验证功能等确认能通了再改回 80。为什么 IP 选“全部未分配”这个选项的意思是“监听本机所有网卡的该端口”服务器多网卡或者 IP 会变的情况下这样配最不容易出问题。如果服务器上有多个站点共用 80 端口就需要靠“主机名”来区分那就是另一个话题了。主机名什么时候填只有在同一台服务器上要跑多个不同域名的站点时才需要。单站点场景留空即可。4.3 权限配置IIS_IUSRS 与应用程序池标识站点建完浏览器访问可能报HTTP 错误 401.3 - Unauthorized或者HTTP 错误 500.19。这两个报错八成跟权限有关。正常的权限配置右键站点目录 → 属性 → 安全 → 编辑 → 添加。输入IIS_IUSRS检查名称确定。给它读取和执行、列出文件夹内容、读取这三个权限就够了。如果站点需要写文件比如上传目录再单独给上传子目录加“修改”权限不要整个站点给写权限。默认情况下应用程序池用的是IIS AppPool\site-a这个虚拟账号。这个账号要通过IIS_IUSRS组间接获得权限或者你也可以直接把它加进去效果一样。注意千万不要图省事给Everyone或者Users加完全控制权限。这是在给自己埋雷后续做安全扫描的时候第一个被点名。一个实测有效的验证方法在站点目录里放一个测试文件用应用程序池的标识去访问看看能不能读到。如果图形界面不方便验证直接用浏览器访问一个具体的静态文件路径比如http://localhost/test.txt能打开说明读取权限没问题。4.4 默认文档、MIME 类型与静态资源 404默认文档决定了访问目录时返回哪个文件。IIS 默认已经配了index.html、default.htm等几个一般不用改。但如果你用的是index.htm之外的自定义名字比如main.html就要手动加IIS 管理器 → 站点 → 双击“默认文档” → 右侧“添加” → 填main.html→ 上移到第一位。顺序很重要IIS 是按顺序找的找到第一个就返回。MIME 类型是静态部署里最容易被忽略的一块。现代前端产物里常见的.wasm、.webp、.woff2、.json在某些系统版本上默认没配浏览器请求时直接 404但文件明明就在目录里。这就是典型的 MIME 问题。处理方式有两种。图形界面站点 → 双击“MIME 类型” → 添加。或者在站点根的web.config里写?xml version1.0 encodingUTF-8? configuration system.webServer staticContent mimeMap fileExtension.wasm mimeTypeapplication/wasm / mimeMap fileExtension.json mimeTypeapplication/json / mimeMap fileExtension.webp mimeTypeimage/webp / mimeMap fileExtension.woff2 mimeTypefont/woff2 / /staticContent /system.webServer /configuration用web.config的好处是跟着代码走换台服务器部署不用重新配一遍。我现在的习惯是每个前端项目根目录都带一份web.config部署时直接进站点目录省一步操作。顺便说一下 Unity WebGL 导出包部署到 IIS 的情况。这类产物一般包含.wasm、.data、.js除了 MIME 之外还经常需要配置压缩相关的响应头。如果你的导出包启用了 Brotli 或 Gzip 压缩而服务器没开对应的压缩模块就会出现“加载到 90% 卡住”的现象。这个时候先看浏览器控制台报的是哪个文件再去对 MIME 和压缩配置比盲猜快得多。5. 进阶前端工程、反向代理与 .NET 运行时基础静态站点跑通之后实际项目里还有几类高频场景要处理。这一节挑三个最典型的单页应用的路由处理、前后端分离后的接口反向代理、以及 ASP.NET Core 应用部署时“IIS 里找不到对应运行时”的问题。这三个问题几乎每个 Windows 部署项目都会遇到至少一个。5.1 Vue3 / 单页应用部署与 history 路由坑Vue3 打包出来的 dist 目录直接丢到 IIS 站点目录首页能打开但一切换到二级路由再刷新立刻 404。原因很直白单页应用的/user/list这种路径其实是前端路由服务器上根本没有user/list这个文件或目录IIS 找不到就报 404。解决思路是配置一条重写规则把所有“找不到实际文件”的请求都指回index.html。前提是服务器已经安装了 URL Rewrite 模块然后在站点根目录的web.config里加?xml version1.0 encodingUTF-8? configuration system.webServer rewrite rules rule nameSPA-Fallback stopProcessingtrue match url.* / conditions logicalGroupingMatchAll add input{REQUEST_FILENAME} matchTypeIsFile negatetrue / add input{REQUEST_FILENAME} matchTypeIsDirectory negatetrue / add input{REQUEST_URI} pattern^/api/ negatetrue / /conditions action typeRewrite url/index.html / /rule /rules /rewrite /system.webServer /configuration这条规则的三个条件分别对应三种情况请求的不是真实文件、不是真实目录、且不是/api/开头的接口请求。第三条尤其重要如果漏了它接口请求也会被重写成 HTML前端拿到的就是一段 HTML 而不是 JSON排查起来非常迷惑。另外如果项目用了 Vue Router 的 hash 模式路径带#那就不需要这条规则了因为#后面的内容不会发给服务器。这也是为什么很多老项目默认用 hash 模式的原因之一。5.2 用 URL Rewrite ARR 做反向代理前后端分离的项目前端在 IIS 上后端在 Node.js 或者 Java 上直接让浏览器跨域访问接口会被拦。常规做法是在 IIS 上做一层反向代理把/api/的请求转发给本地后端。需要两个前置模块URL Rewrite和Application Request Routing (ARR)。装完之后有个关键步骤很多人会漏掉在 IIS 管理器根节点双击Application Request Routing Cache。右侧点Server Proxy Settings。勾选Enable proxy。应用。这一步不勾反向代理规则写了也不生效而且报错信息不明显容易让人误以为是规则写错了。然后站点级别的web.config加规则rule nameapi-proxy stopProcessingtrue match url^api/(.*) / action typeRewrite urlhttp://127.0.0.1:3000/{R:1} / /rule这里用127.0.0.1而不是localhost是因为在某些服务器环境下localhost解析会走 IPv6而后端服务只监听了 IPv4结果就是连接被拒。这个坑我踩过一次排查了大半天。配置项推荐值原因后端地址127.0.0.1避免 IPv6 解析问题超时时间30 到 120 秒默认偏短大文件上传容易断请求头保留开启否则后端拿不到原始 Host 和 IP是否缓存接口不缓存避免返回旧数据5.3 为什么 IIS 里找不到 .NET 8 的 CLR 版本这个问题在热词里被反复提到本质是概念混淆。在 IIS 里新建应用程序池时会看到一个“.NET CLR 版本”的下拉框选项一般只有“无托管代码”“v4.0”“v2.0”这几个。于是很多人就想去找 .NET 8 的选项找不到就以为装错了。其实 ASP.NET Core也就是 .NET 5 之后的版本根本不走这个 CLR 加载机制。它是以独立进程的方式运行的由 IIS 通过一个叫AspNetCoreModuleV2的模块把请求转发过去。所以IIS 里不需要装 .NET 8 的“CLR 版本”下拉框里永远不会有。需要装的是ASP.NET Core Hosting Bundle它会带上运行时和 IIS 模块。装完之后必须执行一次iisreset否则模块不生效。应用程序池的 .NET CLR 版本保持“无托管代码”即可。验证是否装好的方法dotnet --list-runtimes输出里应该能看到Microsoft.AspNetCore.App的条目。如果没有说明 Hosting Bundle 没装或者装完没重启。提示先装 IIS再装 Hosting Bundle顺序反了要修复一遍。这个顺序问题在官方文档里其实写了但很容易被忽略。5.4 Node.js 服务在 IIS 后面的部署方式Node.js 本身不适合直接挂在 IIS 上跑IIS 也不负责管理 Node 进程。常规做法是让 Node 服务在后端自己跑起来监听本地某个端口IIS 只做反向代理。这样就回到了上一节的 ARR 方案。Node 服务本身的守护需要额外工具比如把它注册成 Windows 服务或者用进程管理工具。这里不展开只强调一个点Node 服务的监听地址最好是127.0.0.1不要监听0.0.0.0避免直接被外部访问绕过 IIS 那层。这样做的价值在于日志、证书、限流这些统一在 IIS 层处理Node 层只关心业务逻辑。顺便说一句有些教程会推荐用iisnode模块直接托管 Node这个方案现在维护状态一般新项目不太建议。反向代理是更稳的选择。6. 权限与配置文件两个最容易被忽略的深水区前面讲的都是“正常路径”这一节讲异常路径。IIS 用得久了会发现真正难搞的报错都集中在这两块应用程序池的权限设置和配置文件 applicationHost.config。这两处的报错信息往往很晦涩光看提示很难判断原因。我把遇到过的几种典型情况和解法整理出来。6.1 应用程序池权限设置失败的排查思路有一种报错很典型设置应用程序池标识的时候失败提示需要手动设置权限后面跟着一串错误码比如0x80005000。这个错误码属于目录服务相关的错误出现的原因通常是账号解析失败。排查顺序我一般是这样第一步确认账号名写对了。自定义账号要写域名\用户名或者机器名\用户名只写用户名在某些环境下解析不出来。虚拟账号要写IIS AppPool\池名少一个反斜杠都不行。第二步确认账号存在且有权限。如果是域账号确认当前登录用户有没有权限去读取这个账号信息。这就是0x80005000最常见的成因——当前用户没有查询域账号的权限。第三步确认应用程序池的“标识”改对了地方。IIS 管理器里有两个地方能改身份相关设置站点 → 基本设置 → 连接为应用程序池 → 高级设置 → 标识。改错地方就等于没改。第四步确认密码没变。自定义账号如果改了密码应用程序池不会自动更新站点会直接 503。这种情况在新旧密码切换时特别常见。我的经验是能用应用程序池虚拟账号就别用自定义账号能避免掉这一整类问题。如果确实需要自定义账号就把它写进部署文档里交接的时候专门提示一句。6.2 applicationHost.config 报错的成因与处理另一个高频报错是操作时提示“执行此操作时出错”文件名指向C:\Windows\System32\inetsrv\config\applicationHost.config。这个文件是 IIS 的全局配置所有站点、应用程序池、绑定的信息都在里面。它出问题的原因就那么几种原因一文件被其他进程占用。比如你正在用文本编辑器开着它或者某个同步工具在扫描它。关掉相关程序再试。原因二配置文件被改坏了。手工编辑过 XML标签没闭合IIS 读不出来就报错。这种情况可以去C:\inetpub\history目录找历史备份里面按时间戳存了多份配置副本直接复制回来即可。原因三权限异常。这个文件默认只有特定账户能写。如果被改过权限IIS 管理器保存配置就会失败。原因四磁盘满或者文件系统异常。听起来离谱但真遇到过磁盘没空间导致写配置失败。处理这类问题的稳妥做法是先停服务再操作net stop WAS /y net stop W3SVC /y改完配置再启动net start W3SVC net start WAS顺序不能反WAS 要先起来。另外强烈建议改配置前先做一次备份下一节讲。6.3 IIS 配置的备份与还原IIS 的配置备份是个被严重低估的操作。它的成本极低但关键时刻能救命。备份命令就一行%windir%\system32\inetsrv\appcmd add backup before_deploy_20240101查看已有备份%windir%\system32\inetsrv\appcmd list backup还原%windir%\system32\inetsrv\appcmd restore backup before_deploy_20240101备份文件默认存在%windir%\system32\inetsrv\backup目录下每个备份是一个文件夹里面是完整的配置文件副本。这些文件建议同步一份到别的机器或者网盘因为服务器本身出问题时本机备份也一起没了。我的操作习惯是每次要改绑定、改应用程序池、改全局配置之前先敲一遍备份命令字段名带上日期和操作内容。这个习惯让我在一次误删站点配置后五分钟内恢复完成否则就要重建所有站点。还有一点IIS 本身在C:\inetpub\history目录下会自动保留一部分配置变更的历史版本这个是系统行为不用手动触发。手工备份和自动历史两者互补都值得知道。7. 报错速查与排查技巧实录最后这一节讲排查方法。IIS 的报错有个特点表面报错和真实原因经常不在一层。比如浏览器看到的 500 错误可能就是配置文件里一个标签写错了。所以排查不能靠猜要有一套固定顺序。我把自己常用的排查顺序整理成了三步再配一张高频报错对照表。这几条是我在实际项目里反复验证过的比搜索引擎上那些泛泛而谈的答案靠谱。7.1 排查的基本顺序第一步看浏览器报的具体状态码和子状态码。IIS 的错误页会给一个很具体的代码比如500.19、403.14、404.3这几个数字直接决定了排查方向。不要只看“500 服务器错误”这种笼统描述。第二步看 Windows 事件查看器。打开事件查看器 → Windows 日志 → 应用程序找来源是IIS-W3SVC-WP或者WAS的条目。这里记录的往往是最底层的原因比如组件加载失败、配置文件解析失败。第三步看站点日志。日志默认在C:\inetpub\logs\LogFiles\W3SVC1下按天分文件。每一行是一次请求包含时间、客户端 IP、方法、路径、状态码、耗时。这个日志能告诉你“到底哪个请求出了问题”在排查 404 和 500 时特别有用。我通常还会加一个第四步用最小可复现的方式验证。比如怀疑是权限问题就在站点目录里放一个纯静态的 txt 文件直接访问怀疑是 MIME 问题就换一张图片试着访问。用最小单元去验证假设比盯着代码猜快得多。7.2 高频问题速查表报错/现象大概率原因处理方向401.3 Unauthorized目录权限不足给IIS_IUSRS加读取权限403.14 Forbidden没有默认文档且目录浏览关闭加默认文档或开启目录浏览404.3 Not FoundMIME 类型未配置添加对应扩展名的 MIME 映射500.19 Internal Server Errorweb.config 有语法错误或段落被锁定检查 XML必要时解锁配置节500.21处理程序模块未安装补装对应版本的 .NET 组件503 Service Unavailable应用程序池已停止查看池的标识和密码是否正确二级路由刷新 404单页应用未配重写规则加 SPA fallback 规则接口请求返回 HTML重写规则没排除 API 路径在规则条件里加 API 排除网页能开但样式全丢静态资源被重写或路径错误检查重写条件和资源路径本地能访问、外部不行防火墙未放行端口在防火墙入站规则里放行这张表我建议直接抄下来贴在自己的运维笔记里。实际遇到报错的时候对照着看一眼能省掉大量搜索时间。7.3 几个我踩过的坑坑一改完配置没重启一直以为是配置写错了。改绑定、改应用程序池标识、装模块之后很多时候需要iisreset或者重启对应服务才生效。有几次我在那儿反复检查规则其实只是没生效。坑二多个站点共用 80 端口但没配主机名。结果两个站点互相抢请求访问哪个域名都随机返回另一个站点。这种情况下必须给每个站点配不同的主机名或者用不同的端口区分。坑三前端打包产物里带了web.config把服务器配置覆盖了。有些构建工具会生成自己的web.config部署时直接覆盖了站点原有的配置导致重写规则丢失。部署前对一下文件差异或者把服务器配置项合并进项目的web.config。坑四站点目录放在同步盘里。有些同事把站点目录放在带同步功能的目录下同步进程频繁读写文件句柄导致 IIS 有时读不到文件表现为间歇性 404。站点目录一定要放在本地磁盘。坑五以为“重启 IIS”就是重启电脑。iisreset命令会重启所有 IIS 服务速度快得多。养成用iisreset的习惯别动不动重启机器。还有个跟站点验证相关的小场景某些平台要求你把一个验证文件放到网站根目录并且提示申请提交前不要关闭页面。这种操作的本质就是往站点根目录写一个静态文件只要站点能正常对外提供静态资源访问把文件放进去、浏览器能直接打开就行。如果打不开回头检查文件名是否完全一致、有没有被重写规则拦截、扩展名对应的 MIME 是否配了。最后分享一个我自己的习惯每次部署完成后用浏览器无痕模式访问一遍完整流程从首页到二级路由到接口调用全部走一遍再交付。因为这个模式下没有缓存干扰能看到最真实的结果。踩过几次坑之后我发现真正省时间的不是排查得快而是交付前多验证一遍。