搞Windows开发或者运维的人，迟早要面对“把本地网站跑起来给别人看”这个需求。我在本地做项目演示、给同事内网传文件页面、调试前后端接口时，最常用的就是IIS——Windows自带的web服务器，不需要额外装Apache或Nginx，装好就能用。这篇教程会把两种IIS安装方法完整走一遍，再带你把第一个可访问的网站部署出来，同时把应用程序池权限、多站点绑定、日志分析这些高频问题一并说清楚。无论你是刚入门的新手，还是需要在Windows Server上快速搭内网服务的开发者，都可以按下面的步骤直接操作。
1. 两种IIS安装方法，按你的环境选一个就行
1.1 方法一：Windows功能面板图形化安装
图形化安装是大多数人第一次接触IIS的方式，操作直观，不容易出错。以Windows 10/11为例，打开“控制面板”，找到“程序”，点击“启用或关闭Windows功能”，在弹出的列表里找到“Internet Information Services”。
这里要注意，不要只勾最外层的复选框。IIS的功能是分层的，展开“Internet Information Services”之后，你会看到“Web管理工具”和“万维网服务”两大块。我的建议是至少勾选以下几项：
- Web管理工具下的“IIS管理控制台”，否则装完之后找不到IIS管理器入口。
- 万维网服务下的“常见HTTP功能”，默认会包含“静态内容”“默认文档”“HTTP错误”等子项，托管静态HTML页面靠这些。
- 应用程序开发功能下的“.NET Extensibility”“ASP.NET”或“CGI”，取决于你要跑什么类型的站点。如果只是HTML和静态资源，可以都不勾，但后期要跑PHP或ASP程序就得回来补装。
在Windows Server 2016/2019/2022上，路径稍有不同：打开“服务器管理器”，点击“添加角色和功能”，在“服务器角色”里勾选“Web服务器(IIS)”，然后一路下一步。过程中同样会出现角色服务列表，按需勾选就行。
一个常见的坑是：有人只勾了“IIS管理控制台”，没勾“万维网服务”，结果装完打开管理器发现无法启动网站。记住一个关系——IIS管理器只是“遥控器”，万维网服务才是真正的“发动机”。
1.2 方法二：PowerShell命令行安装
命令行安装适合批量部署、远程操作、无人值守场景。你在本地实验时也可以直接用，比点鼠标快很多。
以管理员身份打开PowerShell，执行下面这条命令：
# 适用于Windows Server系统 Install-WindowsFeature -Name Web-Server -IncludeManagementTools如果你用的是Windows 10/11客户端系统，命令要换成Enable-WindowsFeature：
# 适用于Windows客户端系统 Enable-WindowsFeature -Online -FeatureName IIS-WebServerRole, IIS-ManagementConsole两条命令的区别在于底层实现不同。Install-WindowsFeature是服务器管理器对应的PowerShell模块，Enable-WindowsFeature本质上是DISM的前端封装，在客户端系统上更常见。实际上在某些较新系统里两条命令都能用，但为了稳，我建议按上面的对应关系执行。
命令执行完，系统会提示是否需要重启。一般首次安装IIS不用重启，但如果你同时装了.NET Framework相关功能，可能会要求重启，照做就行。
验证安装是否成功，有几个常用命令：
# 查看Web服务器功能状态 Get-WindowsFeature Web-Server # 查看关键服务是否在运行 Get-Service W3SVC # 查看IIS默认站点 Get-Website如果Get-Website能返回一个名称为“Default Web Site”的站点，说明安装成功。此时打开浏览器访问http://localhost，能看到IIS默认欢迎页，就稳了。
1.3 安装完必做的验证检查
装完之后我习惯做三个检查，避免后面排错时多绕弯子。
第一，确认80端口被监听。在命令行执行：
netstat -ano | findstr :80正常会看到类似TCP 0.0.0.0:80 LISTENING的记录。如果没看到，说明World Wide Web服务没起来，去服务管理器里检查W3SVC服务的启动类型和状态。
第二，确认IIS管理器能正常打开。按Win+R输入inetmgr回车，能弹出IIS管理器窗口就说明管理组件没问题。这一步还能顺带确认应用程序池列表是否正常加载。
第三，确认C:\inetpub\wwwroot目录已生成。这是默认站点对应的物理路径，如果目录不存在，默认网站打不开，通常是因为安装过程异常中断，需要卸载重装。
安装这一步看着简单，却是后面所有问题的根源。我在帮别人排查IIS问题时，第一句话永远是“你先确认一下功能装全了没”，因为缺角色服务导致的报错占了很大比例。
2. 创建你的第一个本地网站
2.1 准备站点目录与测试首页
IIS安装完成只是起点，真正的重头戏是部署网站。第一步是在本地磁盘上准备一个目录，用来存放网站文件。我习惯放在D:\Websites\下，比如建一个名为mysite的文件夹。为什么不放在C:\inetpub\wwwroot？倒不是说不行，而是项目文件如果和系统盘混在一起，重装系统容易丢，所以我个人更推荐放到独立目录。
目录建好后，在里面创建首页文件。最简单的测试页面就是一个index.html：
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>我的测试站点</title> </head> <body> <h1>IIS本地站点测试成功</h1> <p>如果你看到这个页面，说明IIS已经能正常承载你的网站了。</p> </body> </html>文件编码记得用UTF-8，否则中文会乱码。这一步的经验之谈：IIS对静态文件的编码处理比较“耿直”，文件是什么编码，浏览器就按什么编码解析，写错编码会出现“锟斤拷”式的乱码。
2.2 在IIS管理器中添加网站
打开IIS管理器，在左侧“连接”面板里右键“网站”，选择“添加网站”，会弹出配置窗口。需要填四项内容：
- 网站名称：比如填mysite，这个名字只是内部标识，可以随意。
- 应用程序池：默认会自动新建一个同名池，先不用动。
- 物理路径：浏览选择你刚才创建的D:\Websites\mysite。
- 绑定类型：默认为http，IP地址选“全部未分配”，端口写80，主机名留空。
这里解释一下“全部未分配”是什么意思。IIS的绑定规则是：如果指定了具体IP，则只有通过该IP访问时才会命中这个站点；如果选“全部未分配”，则表示服务器上所有IP的80端口请求都归这个站点处理。本地测试选“全部未分配”最省事。
点击确定后，站点就创建成功了。此时在浏览器输入http://localhost或http://127.0.0.1，理论上应该能看到刚才写的测试页面。
如果此时报403.3或403.5错误，先别慌，很可能不是文件问题，而是静态内容类型或MIME映射没配好。403.5通常是URL授权问题，403.3则和静态文件处理程序缺失有关。前者需要检查应用程序池标识对目录的权限，后者需要确认万维网服务里的“静态内容”功能是否勾选。
2.3 防火墙放行与局域网访问
本地访问成功后，很多人马上会遇到第二个需求：让局域网内的其他电脑也能访问。这时候就要处理Windows防火墙。
默认情况下，Windows防火墙会拦截外部对80端口的访问。两种放行方式：
方法一：图形界面。“控制面板”→“Windows Defender防火墙”→“高级设置”→“入站规则”→“新建规则”，选择“端口”，协议选TCP，特定本地端口填80，然后选“允许连接”，最后给规则随便起个名字。
方法二：命令行，管理员执行：
netsh advfirewall firewall add rule name="Allow IIS 80" dir=in action=allow protocol=TCP localport=80两条命令效果一样，我更喜欢第二种，因为可以复制到脚本里批量执行。
放行后，在另一台电脑上输入IIS服务器的IP地址，比如http://192.168.1.100，就能访问到站点。如果还是打不开，按下面三个方向排查：
- 确认两台机器在同一网段，能ping通。
- 确认IIS服务在监听0.0.0.0:80，而不是只监听127.0.0.1。
- 网络配置文件类型是“专用”还是“公用”，如果你的入站规则作用域只勾了“专用”，而实际网络是公用网络，同样会被拦截。
2.4 默认文档与目录浏览的配置
一个非常常见的现象：站点配置没问题，80端口也通了，但访问http://localhost时不是显示页面，而是出现目录列表或403.14错误。这个问题的核心就是默认文档没配置。
IIS处理请求的逻辑是这样的：当用户访问一个目录（比如http://localhost/）时，IIS会按照默认文档列表去查找该目录下是否存在对应文件，找到就返回文件内容，找不到就返回403.14（目录列表被禁用时）或显示目录结构（目录浏览被启用时）。
默认文档的默认内容一般是Default.htm、Default.asp、index.htm等，注意里面并没有index.html。所以你用index.html做首页时，必须手动把它加进默认文档列表。
操作方式：IIS管理器里选中你的站点，双击“默认文档”，点击右侧“添加”，输入index.html，然后把它移到列表最上方。这一步做完，刷新浏览器就能看到页面了。
这里我不建议在正式环境开启“目录浏览”，因为这会把你服务器上的文件结构暴露给访问者，存在信息泄露风险。本地调试用一两下可以，记得用完关掉。
3. 多站点部署与身份验证配置
3.1 同一台IIS上放多个网站的三种方式
本地调试经常要同时跑好几个项目，如果在同一台机器上部署多个网站，就要解决“服务器如何区分不同请求”的问题。IIS支持三种方式：端口区分、IP区分、主机头区分。
| 绑定方式 | 配置要点 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 不同端口 | 站点A绑80，站点B绑8080 | 配置简单，不依赖域名 | 访问时要写端口号，不够优雅 | 临时测试 |
| 不同IP | 站点A绑192.168.1.100，站点B绑192.168.1.101 | 互不干扰，可按IP访问 | 需要机器拥有多个IP，使用成本高 | 服务器多线接入 |
| 不同主机头 | 站点A绑www.a.com，站点B绑www.b.com | 共用80端口，最接近生产环境 | 客户端需要正确解析域名 | 正式多站点部署 |
主机头绑定是最推荐的方式，也最贴合真实生产环境。配置步骤：添加站点时在“主机名”一栏填上你的域名，比如site1.local和site2.local。由于本地没有DNS解析这些名称，你需要在C:\Windows\System32\drivers\etc\hosts文件里手动添加映射：
127.0.0.1 site1.local 127.0.0.1 site2.local保存hosts文件时注意：如果提示权限不足，用记事本以管理员身份打开再改。改完之后，浏览器访问http://site1.local时，请求会先被IIS收到，IIS根据Host头里的site1.local找到对应站点，把请求交给它处理。这就是主机头区分站点的原理。
3.2 Windows身份验证与角色服务缺失
如果你看过IIS的身份验证设置，会发现默认情况下列表里只有“匿名身份验证”是启用的。当你要部署公司内部的网站，需要让域用户自动登录时，就得启用Windows身份验证。
但很多人在这一步会遇到典型报错：安装角色时明明选了“Web服务器(IIS)”，却在“身份验证”功能列表里找不到“Windows身份验证”。原因很简单——Windows身份验证默认就不装，需要单独添加。
以Windows 10/11为例，重新打开“启用或关闭Windows功能”，找到“Internet Information Services”→“万维网服务”→“安全性”，勾选“Windows身份验证”。如果是Windows Server，则需要在服务器管理器里，Web Server(IIS)→Web服务器→安全性→勾选Windows身份验证。
安装完成后，回到IIS管理器，选中你的站点或具体目录，双击“身份验证”，启用“Windows身份验证”，同时禁用“匿名身份验证”。这样配置后，内网域用户在访问时就不需要输入账号密码，浏览器会用当前Windows登录身份自动完成认证。
顺带说一下三种HTTP身份验证的区别：基本身份验证会把密码以Base64编码传输，等于明文；摘要身份验证改进了这一点，但要求域环境配合；Windows身份验证用的是NTLM或Kerberos，最安全，但也就意味着离开Windows环境基本用不了。你要是做跨平台网站测试，就别指望Windows身份验证能通。
3.3 HTTPS绑定与自签名证书
现在的Web项目，哪怕只是本地调试，我也建议尽早把HTTPS配上。原因很简单：很多浏览器特性（比如Cookie的Secure属性、部分Web API）都要求必须是HTTPS环境才生效，你等到上线前才发现就直接抓瞎。
IIS里配置HTTPS的思路是：先有证书，再建绑定。本地没有公网证书，可以用IIS自带的“自签名证书”功能。操作路径：IIS管理器→服务器节点→“服务器证书”→“创建自签名证书”，名称随便填，比如mysite-cert。
证书创建好后，回到站点绑定界面：选中站点，点击右侧“绑定”→“添加”，类型选https，端口填443，SSL证书选刚创建的自签名证书，确定保存。
此时用https://localhost访问站点，浏览器会提示证书不受信任。这是自签名证书的正常现象，因为证书不是由受信任的CA签发的。本地开发时，可以点击“高级”→“继续前往”，强行访问。如果你实在受不了一直点跳过，可以把证书导入到“受信任的根证书颁发机构”存储区，但这样做只对当前这台机器有效，而且自己心里要清楚这是测试证书，不能拿去当线上证书用。
关于“iis with dns”这个热搜词，其实就是本地测试时域名解析的问题。如果你不想手动改hosts文件，可以在局域网内自建一套DNS服务器，或者用路由器自带的DNS解析功能，效果都一样，最终目的就是把域名解析到IIS服务器的IP上。
4. 应用程序池权限与高频错误排查
4.1 0x80005000错误：应用程序池权限设置失败
这个报错是我在热搜词里看到频率最高的一个，原话是：“IIS应用程序池权限设置失败，请手动为其设置localsystem权限未知错误(0x80005000)”。看到0x80005000这个错误码，可以从ADSI错误入手。0x80005000在Windows错误体系里通常对应E_ADS_UNKNOWN_ERROR，本质上是IIS无法正确读取配置或写入配置，常见原因有两个：配置文件的权限不对，或者应用程序池的标识账户已经失效。
我的解决办法分三步走。
第一步，检查配置文件的ACL权限。IIS的核心配置存放在C:\Windows\System32\inetsrv\config\applicationHost.config，确认这个文件能被SYSTEM和Administrators正常读取。如果权限被改过，右键文件→属性→安全，把这两个主体的读取权限补回来。
第二步，用appcmd重置应用程序池设置。管理员命令提示符执行：
%systemroot%\system32\inetsrv\appcmd.exe list apppool先看看是哪个应用程序池报错，然后执行：
%systemroot%\system32\inetsrv\appcmd.exe set apppool "你的池名称" /processModel.identityType:LocalSystem这样等于手动把池标识改为LocalSystem。
第三步，也是我要强调的：LocalSystem只是权宜之计。这个账户权限极高，整个系统都裸奔在它面前。如果你只是本地测试，那用LocalSystem无所谓；如果是给公司正式项目配置，我建议创建专用的域账户或使用ApplicationPoolIdentity，再给这个账户授予站点目录的最小权限（读取和执行）。
4.2 IIS启动时未能加载BouncyCastle.Crypto
另一个高频报错是“IIS启动提示未能加载BouncyCastle.Crypto”。这个问题不算IIS自身的故障，多半是.NET程序或证书相关组件引用了BouncyCastle（一个开源的加密库），而全局程序集缓存（GAC）里存在多个不兼容的版本，导致IIS在工作进程启动时无法正确加载加密模块。
排查思路：先确定报错信息里提到的版本号是什么，然后检查系统里的BouncyCastle.Crypto.dll有哪些副本。常见位置包括项目bin目录、GAC目录（C:\Windows\assembly\或C:\Windows\Microsoft.NET\assembly\GAC_MSIL\）以及NuGet缓存目录。使用PowerShell可以查：
Get-ChildItem -Path C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ -Filter BouncyCastle.Crypto.dll -Recurse如果发现多个版本同时存在，处理方案是统一版本：要么把项目里引用的DLL全部升级到与GAC中一致，要么把GAC里的旧版本卸载掉只保留一个。另外，如果你的站点运行在64位进程下，但某个依赖库是32位编译的，也会出现加载失败。这种情况下，把应用程序池的“启用32位应用程序”设为True，能绕过一部分问题。
这个错误的隐蔽性在于：它往往在IIS启动时出现，但你的代码可能根本没有直接调用BouncyCastle，而是某个第三方库在启动阶段做证书校验时间接用到了它。所以排查时要看事件查看器里的.NET Runtime日志，找到真正的调用栈来源，别瞎改IIS配置。
4.3 关闭详细错误信息的方式
“IIS关闭详细错误信息”也是热搜词之一。IIS有一个安全设计：如果把“错误页”功能设置为“详细错误”，本机访问（localhost）能看到完整的异常堆栈、模块名、处理程序名，但远程访问时IIS会强制返回通用错误页，避免向外部暴露内部信息。这一点是IIS故意为之，不是故障。
如果你确实需要在远程调试时看到详细错误，按下面的方法操作：在IIS管理器里选中站点，双击“错误页”，点击右侧“编辑功能设置”→错误响应方式选“详细错误”，确定。或者在web.config里配置：
<system.webServer> <httpErrors errorMode="Detailed" /> </system.webServer>如果你用的是ASP.NET，还要注意customErrors的设置：
<system.web> <customErrors mode="Off" /> </system.web>但要记住，上线前一定要把模式改回RemoteOnly或On，并关掉httpErrors的详细模式。我在工作中见过好几次因为调试完忘了关，上线后直接把C#堆栈信息暴露给外网的情况，配合SQL异常信息，等于给攻击者递了一把钥匙。
4.4 IIS日志分析与状态码速查
IIS的日志功能默认是开启的，日志文件默认存放在C:\inetpub\logs\LogFiles\W3SVC{站点编号}\，文件名类似u_ex240101.log，每天一个文件。分析这些日志，可以定位访问量异常、程序报错、被扫描攻击等问题。
日志里每行对应一次请求，字段包含客户端IP、用户名、请求时间、请求方法、请求URI、状态码、发送字节数、接收字节数、User-Agent等。最需要关注的字段是sc-status（状态码）和time-taken（耗时）。
很多人在分析日志时想用Excel直接打开，但字段中间有空格，中文环境下有时会出现错位。我推荐用微软官方的Log Parser工具，它可以像SQL一样查询日志，非常强大。一条常用的查询示例：
SELECT cs-uri-stem, COUNT(*) AS cnt FROM 'C:\inetpub\logs\LogFiles\W3SVC1\u_ex*.log' WHERE sc-status = 500 GROUP BY cs-uri-stem ORDER BY cnt DESC这条命令能快速找出哪个页面报500错误最多。如果你不想装Log Parser，也可以用Excel的“数据→自文本导入”功能，按空格分隔导入，也能凑合用。
最后总结一份高频状态码速查表，方便大家排查时对照：
| 状态码 | 含义 | 常见原因与排查方向 |
|---|---|---|
| 200 | 成功 | 正常返回 |
| 301/302 | 重定向 | 检查重定向配置和URL改写规则 |
| 401.1 | 登录失败 | Windows身份验证配置、账户密码过期 |
| 401.2 | 登录配置错误 | 身份验证方式冲突 |
| 401.3 | ACL拒绝访问 | 站点目录权限不足 |
| 403.14 | 目录列表被禁止 | 默认文档缺失 |
| 404 | 文件不存在 | 物理路径错误、URL路由配置失效 |
| 500 | 服务器内部错误 | ASP.NET异常、代码崩溃、权限不足 |
| 502.3 | 进程网关错误 | 应用程序池崩溃、FastCGI超时 |
| 503 | 服务不可用 | 应用程序池停止、线程池耗尽 |
5. 几个特定场景的高频问题
5.1 Unity发布Web后部署到IIS
Unity导出的WebGL项目，部署到IIS后的典型问题是页面白屏，控制台报错说无法加载.wasm文件。原因很简单：IIS不认识.wasm这个MIME类型，直接拒绝对该文件的访问。
解决办法是在IIS管理器的“MIME类型”功能里添加必要的扩展名映射：
| 扩展名 | MIME类型 |
|---|---|
| .wasm | application/wasm |
| .data | application/octet-stream |
| .mem | application/octet-stream |
| .bundle | application/octet-stream |
添加完成后先回收一次应用程序池，再刷新页面就能正常加载。顺便提醒，Unity WebGL对gzip压缩文本资源很依赖，但IIS默认不会对扩展名发送Content-Encoding: gzip头，如果你发现加载速度极慢，可以开启IIS的“动态内容压缩”和“静态内容压缩”功能，效果立竿见影。
5.2 PageAdmin在IIS部署时要注意的配置
PageAdmin是一套比较常见的建站系统，本身是ASP.NET程序，部署到IIS时的坑主要在应用程序池配置上。不少人在本机装完发现能打开后台，但前台页面报500错误，大概率是应用程序池设置不对。
我的建议是：把站点的应用程序池设置为“无托管代码”，或者根据PageAdmin的版本要求选择.NET CLR版本v4.0（老版本可能需要v2.0）。另外，开启应用程序池的“32位应用程序”为True，因为很多建站系统附带的数据库驱动是32位编译的。如果这两点做了还报数据库连接错误，检查web.config里的数据库连接字符串，确认SQL Server实例名、账号、密码都正确。
5.3 RabbitMQ镜像自带管理界面无法连接与IIS的关联
“rabbitmq rabbitmqctl能创建用户，但用镜像自带的web管理界面显示不能连到服务器”这个场景也经常和IIS出现在一起。本质原因通常是RabbitMQ的管理插件没启动，而不是IIS的问题。执行一下：
rabbitmq-plugins enable rabbitmq_management然后重启RabbitMQ服务，浏览器访问http://服务器IP:15672，用rabbitmqctl创建的用户登录即可。
如果插件启动了还是无法访问，再检查15672端口是否被防火墙拦截，以及是否和IIS站点绑定的端口产生冲突。IIS默认用80端口，RabbitMQ管理界面用15672端口，理论上井水不犯河水，但如果有人在IIS里把某个站点绑到了15672端口，就会造成冲突。排查时用netstat -ano | findstr 15672看看端口归属，是IIS的进程（w3wp.exe）还是RabbitMQ的进程（erl.exe），就一目了然了。
5.4 Win11配置IIS ASP时的常见麻烦
Windows 11上装好IIS后跑ASP（经典ASP）程序，最常见的报错是“Active Server Pages 错误 'ASP 0131'”或者直接500。根子还是在于ASP功能没装全。在“启用或关闭Windows功能”里，展开Internet Information Services→万维网服务→应用程序开发功能，勾选“ASP”，如果是64位系统且要跑32位组件，还要把应用程序池的“启用32位应用程序”设为True。
还有一个经典坑是ASP页面里访问数据库用的是Access（.mdb文件），IIS默认不会给Access驱动放行“Microsoft.Jet.OLEDB.4.0”，需要在应用程序池里把“加载用户配置文件”设为True，同时给数据库文件所在的目录添加IIS_IUSRS的读写权限。很多Win11用户卡在这一步怎么调都不行，就是因为这个权限没放开。
写在最后的实操习惯
几次踩坑之后，我给自己定了一套IIS本地部署的固定流程：先确认功能装全，再建目录写页面，然后配默认文档，接着检查防火墙，最后才刷新浏览器。所有配置改动后，记得先“回收应用程序池”再测试，因为IIS对配置文件的修改不总是即时生效。遇到报错先看事件查看器里的Windows日志和IIS日志，比在网上盲搜错误码高效得多。这个顺序看着基础，却能过滤掉90%的入门问题。
