IIS 安装配置和网站部署流程这套东西我前后折腾了差不多七八年从最早的 Windows Server 2008 到现在的 Server 2022从内网 OA 系统到前端 Vue 项目的静态托管几乎每种场景都踩过坑。很多人觉得 IIS 是老古董可真到了企业内网、政企项目、需要和 Windows 域账号打通的场景里它依然是绕不开的一环。这篇文章不写给完全没碰过服务器的人看也不写给已经能闭眼配站点的高手看而是写给那些知道 IIS 是啥、但每次配都心里没底、报个 500 错误就抓瞎的同行。我会把安装、应用程序池、站点绑定、权限设置、备份还原、报错排查这几块按真实操作顺序捋一遍重点讲清楚每一步为什么要这么选而不是只甩一堆勾选框。看完你至少能做到拿到一台干净的 Windows Server两小时内把站点跑起来并且知道出问题时该看哪个日志。1. 先想清楚为什么要用 IIS 而不是别的1.1 IIS 在企业内网里的真实位置我见过太多人一上来就问为什么不用 Nginx这问题本身没毛病但在很多实际项目里根本没得选。政企客户的服务器是 Windows Server域控是 Active Directory站点要读域账号做 Windows 身份验证某些老系统的 COM 组件只有 Windows 上能跑前端打包出来的静态资源又要跟后端 .NET 服务放一起。这时候你上 Nginx光是 Windows 身份验证这一条就得写一堆额外模块维护成本反而更高。IIS 最大的优势不在于性能而在于它和 Windows 生态的耦合度。应用程序池可以指定成域账号跑站点权限能直接继承 NTFS 权限日志走的是系统事件查看器出问题的时候系统管理员和开发能坐在同一套工具链里排查。我在一个制造业客户那儿做过统计他们内网 40 多个站点清一色 IIS运维团队只有两个人照样管得过来靠的就是这套生态自带的一致性。当然 IIS 也有明显的短板并发能力比 Nginx 弱静态资源处理没那么多花活配置界面在 Server Core 上基本没法用。所以我的判断逻辑很简单——如果这个站点需要和 Windows 域、.NET 运行时、COM 组件打交道或者客户运维只会 Windows那 IIS 就是对的如果是纯静态高并发、或者要跑在 Linux 容器里那老老实实上 Nginx。1.2 装之前先想清楚三件事在点开启用或关闭 Windows 功能之前有三个问题必须先有答案否则装完大概率要返工。第一个是站点到底跑什么。纯静态 HTML 加 JS那只需要静态内容模块要跑 ASP.NET Core那得额外装 Hosting Bundle要跑老式 ASP.NET WebForms得勾 .NET Extensibility 和 ASP.NET 那两个版本要跑 PHP那还得配 FastCGI。我见过有人一股脑全勾上结果服务器上多出一堆用不到的模块每次系统更新都要跟着打补丁纯属给自己找事。第二个是服务器有没有外网。没外网的话.NET Hosting Bundle、URL Rewrite 这些组件都得提前下好离线包别等到部署当天才发现下载不了。第三个是有没有人帮你开防火墙。IIS 装完默认只监听 80 端口在本地80、443 这些端口要不要放行安全组要不要改这些如果不在装之前确认站点配好了从外部访问不了你还以为是 IIS 的问题。提示如果是临时测试机我建议直接装完整版 IIS别省那几个模块。省下来的磁盘空间换来的是各种某功能不可用的报错不值当。2. IIS 安装的两种路径与勾选清单2.1 图形界面安装该勾哪些Windows Server 2019 和 2022 上装 IIS最稳的路径是服务器管理器里的添加角色和功能。一路下一步到服务器角色这一步展开Web 服务器(IIS)这里有个坑不要只勾最外层那个框一定要展开把Web 服务器下的常见 HTTP 功能运行状况和诊断安全性应用程序开发按需勾上。我的固定勾选组合是这样的常见 HTTP 功能全勾默认文档、目录浏览、HTTP 错误、静态内容、HTTP 重定向运行状况和诊断里勾HTTP 日志记录和请求监视器安全性里至少勾请求筛选应用程序开发里根据技术栈勾。特别说一下目录浏览很多人不勾结果访问一个没有默认文档的目录直接 403还以为是权限问题其实是这个功能没开。.NET 相关的那几个勾选项名字很像容易搞混NET Framework 3.5 Features是给老 WebForms 用的NET Framework 4.8 Features下的ASP.NET 4.8是给 MVC 和 WebAPI 用的Application Development下的ASP.NET通常指老版本。如果只是托管 ASP.NET Core 应用这些其实都不需要勾真正需要的是单独下载的 .NET Hosting Bundle这个后面会详细讲。Windows 11 上开 IIS 又是另一回事。路径是控制面板 - 程序 - 启用或关闭 Windows 功能勾Internet Information Services然后展开万维网服务再勾子项。Win11 默认装出来的 IIS 只有最基础的功能连 ASP.NET 都没有纯粹够你跑个静态页面做本地调试。想打开管理器就 WinR 输入 inetmgr这是最快的方式别去开始菜单里翻。2.2 PowerShell 一行命令搞定批量安装服务器多了以后图形界面一个个点太慢我一般用 PowerShell 批量装。核心命令是 Install-WindowsFeature但要注意功能名别写错写错了它只会报找不到不会猜你想装什么。Install-WindowsFeature -Name Web-Server, Web-Common-Http, Web-Default-Doc, Web-Dir-Browsing, Web-Http-Errors, Web-Static-Content, Web-Http-Redirect, Web-Http-Logging, Web-Request-Monitor, Web-Filtering, Web-Stat-Compression, Web-Mgmt-Console, Web-Mgmt-Service -IncludeManagementTools-IncludeManagementTools这个参数千万别漏漏了之后 inetmgr 打不开你还得单独装管理控制台。跑完命令可以用Get-WindowsFeature Web-*确认一下状态显示 Installed 的就是装上了。这里我要提醒一个实操细节生产环境我一般不装 Web-Mgmt-Service远程管理服务因为那个服务会开一个 8172 端口安全审计的时候容易被挑刺。远程管理我改用 WinRM 或者直接 RDP够用而且更干净。2.3 装完先做这三项自检IIS 装完别急着配站点先做三件事。第一浏览器访问http://localhost看到 IIS 那个默认的欢迎页说明万维网服务和默认站点是通的。如果打不开先看服务里 W3SVCWorld Wide Web Publishing Service有没有起来再看得 80 端口有没有被占用netstat -ano | findstr :80一条命令就能查出来是谁占的。第二打开事件查看器看 Windows 日志下的应用程序和系统有没有红色错误。刚装完的机器一般会有一些系统层面的信息性事件但如果有 error 级别且和 IIS 相关的先处理掉再往下走。第三确认 .NET 运行时版本。命令行跑dotnet --list-runtimes如果是要托管 ASP.NET Core 应用这里必须能看到 Microsoft.AspNetCore.App。没有的话装 Hosting Bundle注意装完之后要执行net stop was /y再net start w3svc或者直接 iisreset否则 IIS 的工作进程不会加载新的运行时模块站点照样报 500.31。很多人卡在iis 中没有 .net8这个问题上根子就在这里——不是 IIS 没装好是 Hosting Bundle 没装或者装完没重启 IIS。3. 应用程序池与站点参数怎么配才不返工3.1 应用程序池标识和权限设置失败的那些坑应用程序池是 IIS 里最容易被忽视、也最容易出事的一环。默认情况下新建的应用程序池标识是 ApplicationPoolIdentity这其实是一个虚拟账号名字类似IIS AppPool\你的池名它背后对应的是 IIS_IUSRS 组。给站点目录授权的时候你可以直接授权给IIS AppPool\站点池名粒度更细比直接给 IIS_IUSRS 更安全。但真正麻烦的是那类iis应用程序池权限设置失败请手动为其设置 localsystem 权限的报错。我遇到过好几种触发场景。一种是服务器加了域通过组策略把某些本地账号的权限裁剪了IIS 在创建虚拟账号的时候申请不到必要的权限于是报未知错误 0x80005000。这个错误的本质是 ADSI 接口调用失败往往是 DNS 解析不正常或者域控联系不上导致的。排查的时候先nslookup一下域控名字再看系统日志里有没有 Netlogon 相关的错误。另一种场景是站点目录放在了网络共享上虚拟账号没法访问 UNC 路径这时候只能把应用程序池标识改成域账号同时确保那个域账号在共享目录上有读写权限。改成 Localsystem 是最省事但也最危险的做法因为 Localsystem 权限太大一旦站点被拿下等于整台机器沦陷。我个人的原则是测试环境随意生产环境坚决不用 Localsystem宁可多花十分钟配域账号。还有一个细节是加载用户配置文件这个选项。默认是 False对于大多数站点都够用。但如果你的应用依赖当前用户的临时目录或者注册表配置那就得改成 True代价是每次回收池都要加载一遍用户配置文件稍微慢一点。3.2 绑定、端口、主机头的组合逻辑站点绑定这块核心就三样东西IP、端口、主机头。单站点的情况下IP 选全部未分配端口 80主机头留空这是最省的配法。一个服务器要跑多个站点就得靠主机头来区分比如a.example.com和b.example.com都指向同一个 IP 的 80 端口IIS 根据请求里的 Host 字段分发给对应的站点。这里有几个新手常翻车的地方。主机头填了域名但本地测试的时候用 IP 访问IIS 找不到匹配的站点会把请求交给默认站点于是你看到的是别人的页面。解决办法是要么本地加 hosts 记录把域名指过去要么测试阶段先不加主机头。端口冲突也是高频问题。80 被默认站点占了你新建站点也用 80 又没配主机头保存的时候不会报错但访问行为不可预期。我习惯的做法是新建站点先用 8080 之类的高位端口测试确认应用本身没问题了再改成 80 加主机头。HTTPS 绑定涉及证书。测试环境可以用自签证书生产环境必须用受信任的 CA 签发的。导入证书的位置很关键服务器证书要存在本地计算机 - 个人存储里存错位置在 IIS 的证书下拉框里根本看不到。绑定 443 的时候勾需要服务器名称指示可以让同一个 IP 端口上挂多个证书但要确认客户端支持。3.3 静态站点和动态应用的差异化设置静态站点和 ASP.NET 站点在应用程序池配置上差别很大。纯静态站点的池.NET CLR 版本选无托管代码管道模式用集成。这样 IIS 不用加载 .NET 运行时工作进程更轻跑起来更省内存。我托管 Vue 打包出来的 dist 目录就是这么配的一个 2 核 4G 的服务器能轻松扛住几十个静态站点。ASP.NET Core 应用的池.NET CLR 版本也只能选无托管代码因为 ASP.NET Core 运行在独立的 Kestrel 进程里IIS 只是通过 ANCM 模块做反向代理。这个点很多人理解错了以为要选 .NET CLR 版本结果选了半天站点也起不来。管道模式必须是集成经典模式不支持 ASP.NET Core。传统 ASP.NET Framework 应用才需要选具体的 CLR 版本一般是 v4.0管道模式优先集成。回收设置也值得调。默认是 1740 分钟29 小时回收一次对于低流量站点太频繁了我一般改成 0不自动回收配合定时任务在凌晨回收或者干脆设成 1440 分钟。闲置超时默认 20 分钟就回收这个对于内网低频访问的系统很不友好用户早上来访问第一个请求要等进程重新起来会卡好几秒。我一般把它设成 0也就是不因闲置回收。4. 手把手把站点从零跑起来4.1 目录结构和 NTFS 权限的正确姿势站点的物理路径我有个固定习惯不放系统盘放数据盘路径形如D:\Sites\站点名。系统盘一旦满了IIS 的日志和临时文件也写不进去整个服务会跟着出问题。数据盘单独挂一块容量给足日志和站点分开两个目录。目录结构上我一般这样分D:\Sites\site-a\wwwroot放站点文件D:\Sites\site-a\logs放自定义日志IIS 的日志另外配到D:\IISLogs\site-a。这样备份的时候站点和数据一起打包日志单独处理不会把日志混进代码里。权限配置是重灾区。新建目录默认继承父级权限可能带着一堆不相干的账号。我的做法是先关掉继承清掉所有继承来的权限然后只加三个Administrators 完全控制、SYSTEM 完全控制、IIS AppPool\站点池名读取和执行静态站点或修改需要写文件的站点。具体操作是在目录属性-安全-高级里点禁用继承选择从此对象中删除所有已继承的权限然后逐个添加。命令行用 icacls 更快icacls D:\Sites\site-a\wwwroot /inheritance:r icacls D:\Sites\site-a\wwwroot /grant Administrators:(OI)(CI)F icacls D:\Sites\site-a\wwwroot /grant SYSTEM:(OI)(CI)F icacls D:\Sites\site-a\wwwroot /grant IIS AppPool\site-a-pool:(OI)(CI)R(OI)(CI)表示对象继承和容器继承也就是这个权限会往下传。R 是读取M 是修改F 是完全控制。生产环境给应用池账号的开到 M 就够了不要给 F。注意千万别把 Everyone 加进去图省事。很多能跑起来就行的教程这么教但在安全扫描里这是明确的扣分项而且真的会带来风险。4.2 部署验证文件这类特殊需求怎么处理有一种需求我遇到过好几次客户让你在网站根目录下放一个特定的验证文件用来证明这个域名确实是你控制的。文件内容是一串固定的字符串路径通常是/.well-known/xxx.txt或者根目录下的verify.txt。看起来简单但 IIS 上有几个坑。第一个坑是.well-known这种以点开头的目录。Windows 资源管理器默认不允许创建以点开头的文件夹但其实是可以建的只是在资源管理器里可能不显示。用命令行 mkdir 建没问题。建完之后要确认 IIS 没有因为请求筛选规则把这类路径拦掉。第二个坑是 MIME 类型。.txt默认是允许的但如果验证文件是.json或者没有扩展名IIS 会因为找不到 MIME 类型返回 404.3。解决办法是在站点的 MIME 类型里加一条或者干脆把文件内容改成 IIS 认识的形式。第三个坑最隐蔽如果你在前端项目里配了 URL Rewrite 把所有请求都重写到 index.html那验证文件也会被重写掉外部访问拿到的是一堆 HTML 而不是验证字符串。这时候必须在 rewrite 规则里加一条排除规则把验证文件路径排除在重写之外。rule nameExclude verify file stopProcessingtrue match url^verify\.txt$ / action typeNone / /rule顺序很关键这条排除规则必须放在通用重写规则之前否则不生效。我见过有人规则顺序放错了排查了一下午最后发现就是这个。验证通过之后别忘了把这类文件清理掉或者至少确认它不包含任何敏感信息。4.3 前端项目和反向代理怎么配合现在前端项目基本都是 Vue 或者 React 打包成静态资源后端是独立的 API 服务。部署方式有两种一种是前后端分开前端静态站点一个域名后端 API 另一个域名靠 CORS 通信另一种是同域名用 IIS 的 URL Rewrite 加 ARR 做反向代理把/api的请求转发到后端端口。第二种在内网项目里更常见因为不用处理跨域Cookie 也能直接带上。配置需要装两个扩展URL Rewrite 和 Application Request RoutingARR。装完之后在 IIS 管理器里会多出URL 重写和服务器场两个图标。反向代理的核心配置写在 web.config 里大概是这个样子configuration system.webServer rewrite rules rule nameAPI Proxy stopProcessingtrue match url^api/(.*) / action typeRewrite urlhttp://127.0.0.1:5000/{R:1} / /rule rule nameSPA Fallback stopProcessingtrue match url.* / conditions logicalGroupingMatchAll add input{REQUEST_FILENAME} matchTypeIsFile negatetrue / add input{REQUEST_FILENAME} matchTypeIsDirectory negatetrue / /conditions action typeRewrite url/index.html / /rule /rules /rewrite /system.webServer /configurationSPA Fallback 那条规则是给前端路由用的保证刷新页面不会 404。这里有个顺序问题API Proxy 必须放在 SPA Fallback 前面否则/api/xxx会被先兜到 index.html 去。ARR 还有个反代开关要手动打开。在 IIS 根节点上双击Application Request Routing Cache右侧点Server Proxy Settings勾上Enable proxy。这一步漏了重写规则写得再对也转不出去请求会返回 404 而且日志里看不出明显原因。5. 备份还原和站点迁移怎么做才靠谱5.1 applicationHost.config 的备份与还原IIS 的所有站点、应用程序池配置都存在一个文件里C:\Windows\System32\inetsrv\config\applicationHost.config。这个文件出问题整个 IIS 就瘫了所以它必须备份。备份方式有几种。最直接的是复制文件Copy-Item C:\Windows\System32\inetsrv\config\applicationHost.config D:\Backup\iis\applicationHost_$(Get-Date -Format yyyyMMdd).config这个操作要以管理员身份跑因为那个文件普通账号读不了。我一般是写个计划任务每天凌晨跑一次保留最近 30 天。IIS 管理器里也有内置的备份功能在根节点上右键配置编辑器旁边那个共享配置里能找到。但我更推荐命令行的方式因为可以自动化。appcmd这个工具也能导出配置%windir%\system32\inetsrv\appcmd list site /config /xml D:\Backup\iis\sites.xml %windir%\system32\inetsrv\appcmd list apppool /config /xml D:\Backup\iis\apppools.xml还原的时候如果只是站点配置坏了把备份的 applicationHost.config 复制回去然后 iisreset 就行。但要注意这个文件里有机器特有的信息比如应用程序池的 SID 映射直接从别的机器拷过来的文件可能不能直接用。跨机器迁移用 appcmd 导出站点定义再导入更稳妥。我踩过的一个坑是某次系统更新后 IIS 起不来日志说 applicationHost.config 的第 xxx 行有语法错误。打开一看是之前手动编辑的时候漏了个引号。所以我现在改这个文件之前一定先复制一份带时间戳的备份改完立刻 iisreset 验证不等到出事才发现。提示Windows Server 有个执行此操作时出错文件名: c:\windows\system32\inetsrv\config\administr...的报错通常是配置文件权限被改过或者文件被占用。先确认 IIS 服务停了没再检查文件的 NTFS 权限是不是被安全软件动过。5.2 跨服务器迁移的打包思路迁移站点我一律走配置导出 文件复制 权限重建三步。第一步在源机器上用 appcmd 导出所有站点的配置导出内容包括站点名、物理路径、绑定信息、应用程序池名。导出的 XML 拿到目标机器上把物理路径替换成本地的路径然后导入。重名的站点和池要先改名字不然会冲突。第二步复制文件。这里要注意排除掉 logs、temp 这些目录还有web.config里可能写死了源机器路径的地方。复制完之后检查.config文件里的连接字符串、文件路径、端口号这些是跨机器最容易出问题的。第三步也是最容易被忽略的一步重建权限。文件复制过去之后NTFS 权限大多数情况下不会跟着来因为目标机器上没有源机器的那套账号。所以要重新给应用程序池账号授权按前面 4.1 的方式走一遍。整个流程里我觉得最省时间的是提前写一个 PowerShell 脚本把目录创建、权限设置、站点导入、绑定配置这些串起来。我自己的脚本大概 80 行能覆盖 90% 的场景。脚本里特别注意把$PSScriptRoot用上保证不管从哪个目录调用都能找到相对路径的资源。6. 那些五花八门的报错按这个顺序查6.1 权限类报错0x80005000 和手动设 Localsystem前面提过 0x80005000这里再系统说一下排查路径。这个错误码对应的含义是指定的目录服务对象不存在出现在 IIS 里通常和应用程序池标识设置、或者站点创建时申请权限有关。排查顺序我一般是这样的先ping域控确认网络通再nslookup域名确认解析正常然后看事件查看器系统日志里有没有 Netlogon 552 之类的错误最后检查本地的 IIS_IUSRS 组还在不在被安全基线工具删掉过的情况我见过不止一次。如果这些都没问题那可能是组策略里的拒绝通过远程桌面服务登录或者作为服务登录权限被收紧导致虚拟账号没法被创建。这种时候最现实的解法是给应用程序池指定一个真实的域账号绕开虚拟账号这条路。设置方式是在应用程序池-高级设置-标识里选自定义账户填域账号和密码。但要注意这个域账号必须在目标目录上有权限而且密码策略改了之后要同步更新否则池会因为密码过期起不来。所以我现在更倾向于用 gMSA组托管服务账号密码由系统自动管理不会过期。配置略微麻烦一点但长期省心。6.2 500.19 和配置锁的纠缠500.19 这个错误码几乎每个 IIS 管理员都见过含义是配置数据无效。最常见的原因是 web.config 里用了某个 section但对应的模块没装或者被锁了。典型案例站点里配了 URL Rewrite但服务器上没装 URL Rewrite 模块一访问就 500.19错误详情里会明确说哪个 section 不认识。解法就是装模块或者去掉相关配置。另一个典型案例是配置被 section 锁了。比如在站点级 web.config 里写httpErrors但服务器级的 applicationHost.config 把这个 section 设成了 overrideModeDeny站点就没法覆盖。排查的时候点开错误详情能看到是哪个 section 被锁然后用 appcmd 解锁%windir%\system32\inetsrv\appcmd unlock config /section:system.webServer/httpErrors我的原则是站点级的 web.config 只放自己项目必须的配置其他能放服务器级的都放服务器级。移动端配置能减少很多这种冲突。6.3 403、404、端口占用这套组合拳403 一般是权限或者目录浏览的问题。前者的排查方式是看错误详情里的由 xxx 模块处理的请求如果是 IIS 的授权模块那就查目录权限如果明确说禁止目录浏览那要么加默认文档要么把目录浏览打开但生产环境不建议开。404 有两个版本IIS 自己的 404 和应用返回的 404。IIS 的 404.3 是 MIME 类型没配前面提过404.4 是没有处理程序不带子码的 404 就是文件真的不在了。应用返回的 404 得去应用程序日志或者应用自己的日志里查IIS 看不到。端口占用最直接的排查就是netstat -ano | findstr :端口号。找到 PID 之后用tasklist | findstr PID看是哪个进程。Windows 上占 80 端口的大户是 IIS 自己、SQL Server Reporting Services会占 80、还有某些第三方服务。IIS 自己的话确认是不是默认站点没删掉。还有一个隐蔽的Windows 的HTTP.sys驱动会预留一些端口给其他服务用预留了之后 IIS 就绑不上。用netsh http show urlacl能列出所有预留要清理的话用netsh http delete urlacl url...。6.4 几个我经常遇到的边角问题下面这张表是我这些年攒下来的高频问题和对应的解法基本都是三分钟内能定位的。现象大概率原因快速处理站点浏览显示默认欢迎页主机头没匹配上落到默认站点检查绑定和 hosts页面白屏但状态 200前端路由没配 Fallback加 URL Rewrite 兜底规则上传大文件 413请求限制默认 30M改 maxAllowedContentLength应用池频繁重启内存阈值触发或代码崩进程查事件日志看退出原因改配置后不生效配置未提交或进程未回收iisreset 或回收对应池HTTPS 访问证书错误绑定的证书不对或链不全检查绑定和中间证书静态资源 404 但文件存在MIME 类型缺失补 MIME 映射定时任务跑在站点里报错池闲置回收后定时器停了设置池不闲置回收上传大小限制这块单独说一下IIS 里有三个地方管着请求大小maxAllowedContentLength在 system.webServer/security/requestFiltering 下单位是字节、maxRequestLength老式 ASP.NET 的单位是 KB、还有应用的 Kestrel 或 Tomcat 自己的一层。三层都要改只改一层没有用。这三个数我一般设成一致的比如都设 200MB免得互相打架。7. 一些配多了才有的经验最后说几个不太成体系但很实用的经验。第一给每个站点单独写日志目录并且把 IIS 的日志格式设成 W3C 扩展字段里勾上 cs-host 和 cs-uri-query。默认格式里没有 cs-host多站点在同一台服务器上时日志分不清是哪个域名的请求排查问题的时候会很痛苦。第二应用程序池的启动模式在 2019 及以后的版本里可以设成 AlwaysRunning配合站点的预加载已启用能让站点在 IIS 启动的时候就跑起来第一个请求不用等。这个对那种要求打开页面必须一秒内出结果的系统很有用。第三快速失败保护这个功能要留心。默认情况下如果一个工作进程在 5 分钟内崩溃 5 次IIS 会直接停掉整个应用程序池这时候所有访问都返回 503。定位阶段这个功能挺烦人的可以先关掉让进程反复重启方便看日志。但上线之后一定要开着否则一个崩溃的进程会无限重启把 CPU 吃满。第四定期清理日志。IIS 的日志增长很快一个中等流量的站点一个月能攒好几个 G。我不是很推荐用 IIS 自带的日志滚动那个是按文件大小切不如直接写个计划任务按日期删。删的时候注意别删当天的否则正在写的文件句柄会出问题。第五IIS 的配置改完之后一定要导出备份。我自己的习惯是任何一次生产变更之后立刻跑一遍备份脚本然后给备份文件打上变更说明的标签。出问题的时候能精确回滚到某一个变更点这个比什么都强。第六如果站点要和其他 Windows 服务共用一台机器务必先算内存。IIS 的工作进程加上 SQL Server 加上其他服务很容易把内存吃干净然后各种服务开始来回抢内存症状表现为偶尔卡顿莫名其妙重启。我一般的分配原则是给 IIS 留 30% 到 40% 的内存剩下的按重要性分。第七Server Core 上配置 IIS 全靠命令行和远程管理图形界面基本没有。如果团队里没有能熟练用 appcmd 和 PowerShell 的人就别上 Server Core正常装带桌面的版本省下来的沟通成本比省下来的那点资源多得多。这套东西说起来不复杂但每一个点都是我在真实的项目里被坑出来的。IIS 的文档其实写得挺全问题在于它把每个功能都孤立地讲很少告诉你这几个设置之间是有依赖的。上面这些组合式的经验希望能帮你少走点弯路。真到了现场卡住的时候先别慌着改把错误详情完整读一遍看清楚是哪个模块、哪个 section、哪个权限出的问题十有八九就这一条信息就能定位了。