十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

IIS网站部署实战:从安装配置到高频错误排查

IIS网站部署实战:从安装配置到高频错误排查 搞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管理器能正常打开。按WinR输入inetmgr回车能弹出IIS管理器窗口就说明管理组件没问题。这一步还能顺带确认应用程序池列表是否正常加载。第三确认C:\inetpub\wwwroot目录已生成。这是默认站点对应的物理路径如果目录不存在默认网站打不开通常是因为安装过程异常中断需要卸载重装。安装这一步看着简单却是后面所有问题的根源。我在帮别人排查IIS问题时第一句话永远是“你先确认一下功能装全了没”因为缺角色服务导致的报错占了很大比例。2. 创建你的第一个本地网站2.1 准备站点目录与测试首页IIS安装完成只是起点真正的重头戏是部署网站。第一步是在本地磁盘上准备一个目录用来存放网站文件。我习惯放在D:\Websites\下比如建一个名为mysite的文件夹。为什么不放在C:\inetpub\wwwroot倒不是说不行而是项目文件如果和系统盘混在一起重装系统容易丢所以我个人更推荐放到独立目录。目录建好后在里面创建首页文件。最简单的测试页面就是一个index.html!DOCTYPE html html langzh-CN head meta charsetUTF-8 title我的测试站点/title /head body h1IIS本地站点测试成功/h1 p如果你看到这个页面说明IIS已经能正常承载你的网站了。/p /body /html文件编码记得用UTF-8否则中文会乱码。这一步的经验之谈IIS对静态文件的编码处理比较“耿直”文件是什么编码浏览器就按什么编码解析写错编码会出现“锟斤拷”式的乱码。2.2 在IIS管理器中添加网站打开IIS管理器在左侧“连接”面板里右键“网站”选择“添加网站”会弹出配置窗口。需要填四项内容网站名称比如填mysite这个名字只是内部标识可以随意。应用程序池默认会自动新建一个同名池先不用动。物理路径浏览选择你刚才创建的D:\Websites\mysite。绑定类型默认为httpIP地址选“全部未分配”端口写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 nameAllow IIS 80 dirin actionallow protocolTCP localport80两条命令效果一样我更喜欢第二种因为可以复制到脚本里批量执行。放行后在另一台电脑上输入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端口填443SSL证书选刚创建的自签名证书确定保存。此时用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 errorModeDetailed / /system.webServer如果你用的是ASP.NET还要注意customErrors的设置system.web customErrors modeOff / /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.3ACL拒绝访问站点目录权限不足403.14目录列表被禁止默认文档缺失404文件不存在物理路径错误、URL路由配置失效500服务器内部错误ASP.NET异常、代码崩溃、权限不足502.3进程网关错误应用程序池崩溃、FastCGI超时503服务不可用应用程序池停止、线程池耗尽5. 几个特定场景的高频问题5.1 Unity发布Web后部署到IISUnity导出的WebGL项目部署到IIS后的典型问题是页面白屏控制台报错说无法加载.wasm文件。原因很简单IIS不认识.wasm这个MIME类型直接拒绝对该文件的访问。解决办法是在IIS管理器的“MIME类型”功能里添加必要的扩展名映射扩展名MIME类型.wasmapplication/wasm.dataapplication/octet-stream.memapplication/octet-stream.bundleapplication/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%的入门问题。
返回列表