配好IIS网站却发现浏览器访问不了这大概是Windows服务器上最经典、也最容易让人抓狂的问题之一。你去IIS管理器里看站点明明是已启动应用程序池也在运行绑定也填了IP和端口可浏览器输入地址就是转圈、超时或者直接甩给你一个503、403、404。更麻烦的是这类配置着没问题、访问就是不通的现象背后原因五花八门——端口被占、防火墙拦截、应用程序池权限不对、功能组件没装全、默认文档丢了甚至云安全组没放行每一环都可能踩坑。这篇文章专治这种配置看着没问题、访问就是不通的情况。我会按自己这些年实际排查的顺序来写先分清楚谁在访问、报什么错、服务活没活再去看端口、绑定、防火墙接着查权限、功能组件最后把日志和失败请求跟踪这套终极取证手段交代清楚。适合刚接触IIS的新手也适合被同类问题反复折磨的老运维。照着这个顺序走一遍大概率能把问题兜住。1. 排查前先做三问别让无法访问这四个字把你带偏很多人一上来就怀疑IIS配置但我做排查的第一件事永远是先问自己三个问题谁能访问、报什么错、服务状态如何这三个问题看起来基础却能直接决定后面半小时你是白忙活还是精准定位。跳过这一步直接改配置往往越改越乱。1.1 谁访问不到本机、局域网还是外网同样一句无法访问至少有三层完全不同的含义对应的排查方向也截然不同。本机可以访问局域网其它电脑不行这种情形下IIS站点和绑定基本没毛病问题大概率出在Windows防火墙的入站规则极少数情况是杀毒软件拦截了IIS工作进程的监听。本机访问也不行问题可能出在绑定、端口、应用程序池、站点物理路径、功能组件等任意一环需要继续往下查这个场景也是本文重点覆盖的范围。内网可以外网不行先确认路由器端口映射或云服务器安全组是否放行了对应端口。如果是云服务器我见过太多把云安全组没放行当成IIS配置错误反复折腾一整天的案例这种问题跟IIS本身没关系但排查起来最消磨耐心。还有一个更隐蔽的情况手机用内网IP访问不了电脑却可以。这种多半是手机连接的Wi-Fi和服务器不在同一个子网网络隔离导致请求根本没到服务器。1.2 具体报错是什么403、404、500、503各指向什么方向浏览器报错码是IIS给你的第一句话这句话指向的方向差别很大看懂了就能少走一半弯路。状态码含义优先排查方向403没有权限访问NTFS权限、IP地址限制、身份验证方式、请求筛选404找不到文件或路径物理路径配置、默认文档、URL重写规则、绑定主机名500服务器内部错误应用程序池崩溃、代码异常、Web.config配置、模块加载失败503服务不可用应用程序池停止、请求队列满、回收设置、模块初始化失败有一个细节经常被忽略404不一定是文件真的不存在。托管在IIS上的ASP.NET站点如果URL重写规则把请求转向一个不存在的内部路径或者默认文档列表里没有首页文件同样会返回404。这类假404光看浏览器看不出区别必须结合日志和配置一起判断。1.3 服务与站点状态快速确认在查浏览器报错之前先把底层的活没活确认清楚再动手。我建议按这个顺序来运行services.msc打开服务管理器确认World Wide Web Publishing Service (W3SVC)状态是正在运行。打开IIS管理器确认目标站点状态为已启动。确认对应应用程序池状态为已启动没有被自动停止或回收。如果W3SVC没起来站点状态一定是停止的这时候去改站点配置纯属白费力气应该先解决服务依赖问题。顺带说一句W3SVC停掉之后浏览器访问看到的是无法连接或连接被重置而不是任何HTTP状态码。这个区别很有用——能帮你快速判断问题到底发生在HTTP层还是在更底层的网络层。2. 端口、绑定与防火墙三者配合才能让请求找得到门站点状态正常却进不来下一步就得看门有没有开对。IIS的请求入口由三件事共同决定绑定规则、端口占用、防火墙放行。任何一环掉了链子请求都会在外面打转进不了站点。2.1 站点绑定中的IP、端口、主机名到底匹配的是什么经常有人问我明明绑定了IP为什么用域名访问不了因为绑定配置里的IP、端口、主机名三者是且的关系请求必须同时满足这三个条件才会被交给这个站点处理。IP可以选择全部未分配、回环地址127.0.0.1、本机局域网IP或公网IP。端口可以是80、8080、443或任意未被占用的端口。主机名输入域名访问时这里填写的内容必须与请求头里的Host字段完全一致。我举个例子你就明白了。网站绑定了192.168.1.10:80:www.example.com那你直接在浏览器里输入http://192.168.1.10是访问不到这个站点的因为请求头里Host字段不匹配IIS会把这个请求交给默认站点处理或者直接按绑定不匹配拒绝掉。同一台IIS服务器上放多个Web网站核心就是靠主机名端口这组组合来区分请求多个站点端口相同就必须用不同的主机名端口不同则IP和主机名可以灵活组合。很多人配第二个站点时忘了填主机名结果两个站点抢同一个端口访问起来一会儿对一会儿错就是绑定规则没理清。2.2 端口占用80端口被别的进程截胡端口被占是特别常见的隐形杀手。你用http://localhost访问结果页面跳出来的不是你的IIS站点而是另一个软件——比如某些开发工具、虚拟机管理服务甚至被恶意程序占用。这种时候你以为是IIS配置错了实际是请求压根没到IIS手里。排查方法很简单在命令行执行netstat -ano | findstr :80看到80端口被某个PID占用后再用下面的命令确认是哪个进程tasklist | findstr 进程PID如果确实想用80端口需要先停掉占用它的程序如果不想折腾就直接在IIS绑定里换一个端口。但这里有个隐患要提醒一旦端口不是标准80或443外网访问时URL里就必须带端口号比如http://www.example.com:8080用户很容易忘记写端口导致访问失败。我一般建议能解决80端口冲突就尽量解决而不是一味换端口。2.3 Windows防火墙入站规则与端口放行的正确姿势本机能访问、局域网访问不了十有八九是防火墙入站规则的问题。放行IIS端口的推荐做法不是把Windows防火墙整体关掉而是为具体端口添加一条入站规则。用管理员权限执行netsh advfirewall firewall add rule nameIIS Port 80 dirin actionallow protocolTCP localport80如果服务器上部署了多个站点、用了多个端口建议把常用端口一次性放进同一条规则里维护别一个个添加否则后面管理规则列表会越来越混乱。另外云服务器场景下除了Windows防火墙云平台控制台的安全组也必须同步放行对应端口。我排查外网访问不通时会先用telnet IP 端口做一次裸连接测试能通说明网络层没问题不通直接去看防火墙和安全组不用在IIS里瞎转。这个习惯帮我省了大量时间。2.4 主机名解析DNS配置与hosts文件的临时判断还有一个经常和绑定混在一起的问题是DNS解析。你在IIS里绑定了www.example.com但外网访问时解析不到这台服务器那请求根本到不了IIS。查这个问题的思路是先确认目标域名能不能解析到正确的IP再确认IIS绑定里有没有这个主机名。临时想验证绑定是否正确可以在访问的电脑上改hosts文件把域名直接指向服务器IP然后浏览器访问。如果hosts指向后能正常打开说明IIS绑定没问题问题出在DNS解析如果指向后还是打不开那问题就在服务器本机的端口、防火墙或IIS配置上。这个hosts对照法是我每次区分DNS问题和服务器配置问题的首选手段。3. 权限链条从应用程序池身份到文件系统NTFS权限网络通了、端口也通浏览器却报403或500那大概率是权限环节出问题了。IIS里的权限是一整条链子应用程序池的进程身份、IIS_IUSRS组、IUSR匿名账户、文件系统上的NTFS权限环环相扣任何一环断了就会出问题。3.1 应用程序池默认身份与权限设置失败的经典坑IIS的应用程序池默认身份是ApplicationPoolIdentity这个身份决定了运行站点代码的进程能访问哪些系统资源。如果站点物理目录的NTFS权限没有把对应的应用程序池身份加进去工作进程读不到文件结果要么是403.14目录浏览被拒绝要么是500内部服务器错误。网上有个搜索热度很高的问题iis应用程序池权限设置失败,请手动为其设置localsystem权限未知错误(0x80005000)。我之前也在实际环境里撞到过一次这个错误通常是你在IIS管理器里修改应用程序池身份或做权限相关操作时IIS配置存储的访问出了问题。看到这个错误先做三件事以管理员身份重新打开IIS管理器很多时候是UAC权限不够导致配置写入失败。检查IIS配置目录C:\Windows\System32\inetsrv\config的读写权限是否正常确认没有被安全软件锁住。如果界面操作一直失败就用命令行绕过去用管理员身份执行appcmd set apppool 你的应用池名称 /processModel.identityType:LocalSystem需要提醒的是把应用程序池身份设为LocalSystem确实能解决权限问题但这是高权限高风险操作线上环境只建议临时验证用。稳妥的做法是保持ApplicationPoolIdentity然后对站点文件夹做最小化、精确的授权。3.2 NTFS权限到底该给谁授权如果站点允许匿名访问IIS会通过IUSR账户或应用程序池对应的虚拟账户来读取文件。给站点目录授权的标准操作是在站点物理路径文件夹上右键 → 属性 → 安全 → 编辑 → 添加。输入IIS_IUSRS授予读取和执行、列出文件夹目录、读取权限。如果站点需要写文件比如上传目录、日志目录单独给对应子目录授予修改权限不要给整个站点开放写权限。这里有个常见的误区很多老教程会让你把Everyone加进权限列表。临时环境里这一招确实能瞬间解决权限报错但生产环境千万别这么干。给Everyone授权等于把服务器上所有能登录系统的账户都变成站点的访问者风险极大我只能说慎重。3.3 用进程身份去反推权限缺失当权限问题很隐蔽、一眼看不出来时我有个小技巧先确认应用程序池配置的是哪个身份然后手动用这个身份去尝试访问站点目录。如果身份是ApplicationPoolIdentity它对应的实际账户名通常是IIS APPPOOL\你的应用池名给目录授权时就按这个精确账户名添加如果身份改成了LocalSystem那这个进程对本机SYSTEM有权限的路径都不会有权限问题。用这个思路去对比权限缺失的位置其实很快就能框定出来。另外别忘了检查身份验证功能本身。IIS管理器的站点层级下有身份验证功能匿名访问需要匿名身份验证处于启用状态。如果这个功能被禁用IIS会要求用户提供凭据浏览器端表现可能是弹登录框也可能直接403。4. 功能组件与处理程序映射缺失IIS装上≠功能全开文件都在、权限也开了怎么还是500——这种时候该怀疑IIS功能组件了。Windows Server上装IIS时默认安装的只是最小功能集很多能力需要手动勾选。忘了装各种稀奇古怪的报错就来了。4.1 常见的功能组件缺失报错站点是ASP.NET应用但只装了静态内容支持访问时大概率报500.19或500.21。站点是PHP程序但没在IIS里配置FastCGI处理映射访问.php文件会出现404.2或500.0。需要WebSocket支持、HTTP重定向、URL授权、目录浏览这些都要在服务器管理器 → 添加角色和功能里单独勾选。具体来说Windows Server上检查功能组件是否装全的步骤是打开服务器管理器 → 添加角色和功能 → 下一步到服务器角色。展开Web服务器(IIS) → Web服务器 → 应用程序开发。确认ASP.NET 4.x、CGI、ISAPI扩展、WebSocket协议等需要的选项是否已勾选。如果漏装了勾选后点下一步安装IIS会自动重启相关服务。4.2 处理程序映射与请求筛选为什么静态页能开、动态页报错IIS把不同后缀的请求交给不同的处理程序靠的是处理程序映射。在IIS管理器的站点层级双击处理程序映射你应该能看到*.aspx对应PageHandlerFactory*.php对应FastCGI模块等。如果某个映射缺失或被禁用对应后缀的请求就会找不到处理程序直接报错。请求筛选是另一个容易被忽略的点。IIS默认会对文件扩展名、URL长度、请求内容大小做限制如果发布了带特殊后缀的文件或超大文件即使权限没问题也可能被拦。排查时可以临时把请求筛选里的对应限制调高再访问试试如果通了基本能判断是筛选规则卡的。4.3 默认文档、静态内容与MIME类型访问http://站点IP/而不指定具体文件名时IIS会按默认文档列表的顺序找文件。IIS默认的顺序大约是Default.htm、Default.asp、index.htm、index.html、iisstart.htm。如果你的站点首页是index.php而默认文档列表里没有它访问根路径就会404。解决方式很简单在默认文档功能里添加index.php即可。MIME类型则是一个特别容易迷惑人的点。放了个.apk或.svg文件访问却返回404.3很多新手的第一个反应是文件丢了其实是因为IIS不认识这个扩展名拒绝返回给浏览器。在IIS管理器的MIME类型里手动添加对应扩展名就能解决。5. 一次完整的现场排查从浏览器报错到根因落点讲完原理我用三个日常环境里最容易遇到的场景把上面的知识点串成一条完整的排查链路。你照着走多数问题都能定位到根因。5.1 场景一503 服务不可用浏览器显示503 Service Unavailable第一反应去看应用程序池是否被停了。操作路径打开IIS管理器 → 应用程序池 → 找到站点对应的池右键回收一次看能不能恢复。如果能恢复说明这个池大概率是因为持续报错触发了自动停止。接着打开Windows事件查看器 → Windows日志 → 应用程序找到最近几条来源为IIS-W3SVC-WP或WAS的错误记录里面会带异常模块和异常代码。常见的根源有应用程序池位数32位/64位与站点代码不匹配、托管管道模式经典/集成选错、站点引用的某个模块初始化失败。我遇到过一个很典型的案例应用程序池默认64位但网站引用了一个32位的COM组件一运行就崩池反复停止。解决方案很简单在应用程序池的高级设置里把启用32位应用程序改为True。5.2 场景二403.14 禁止目录浏览403.14的报错信息本身会提醒你Web服务器配置为不列出此目录的内容。常见排查顺序确认物理路径指向的文件夹里确实有首页文件比如index.html。如果首页文件名不在默认文档列表里在IIS管理器中添加默认文档。确认目录NTFS权限里包含IIS应用程序池身份或IIS_IUSRS的读取权限。确认目录浏览功能是否需要开启。请注意开启目录浏览本身是一个临时的做法如果站点没有首页文件开启后页面会列出目录里的所有文件内容这让别人很容易看到你的目录结构生产环境不建议长期开启。5.3 场景三500 内部服务器错误500是万能错误根因多到数不过来。我的第一步永远是打开详细错误信息。浏览器端默认会隐藏详细错误可以在IIS管理器的错误页功能中先把详细错误模式开启重新访问页面就能看到具体错误码比如500.19配置错误、500.21模块错误、500.22托管管道模式错误。如果无法开启就去IIS日志里找对应请求的sc-status和sc-substatus。比如500.19会指向Web.config的配置问题很多情况下是Web.config里的某个配置节在当前IIS功能没有启用时触发的最常见的就是写入了URL重写规则但IIS里根本没装URL Rewrite模块。5.4 用失败请求跟踪做终极取证当上面所有手段都试过还是找不到原因时启用失败请求跟踪Failed Request Tracing往往能一击命中。步骤是在IIS管理器的站点上打开失败请求跟踪功能启用并设置跟踪条件比如状态码500。重新访问一次触发错误的URL。到默认目录C:\inetpub\logs\FailedReqLogFiles下找到生成的XML跟踪文件。用浏览器打开后可以看到请求处理的每个环节状态——模块加载、身份验证、授权、处理程序执行——哪个环节状态码变了就是哪个环节出了问题。这个工具我第一次用的时候觉得有点复杂但真用顺手之后它比在事件查看器里翻半天高效得多。尤其是那些被代码异常处理吞掉的错误日志里看不到失败请求跟踪的请求链路里却全都有。6. IIS日志最后一道说真话的证据链排查到接近尾声还悬而未决时IIS日志是唯一不撒谎的证据链。它记录了每一个HTTP请求的原始结果比任何口头描述和屏幕截图都靠谱。6.1 日志文件位置与字段解读IIS日志默认位于C:\inetpub\logs\LogFiles\W3SVC[站点ID]目录下按天生成.log文件。打开后每行对应一次请求重点看这几个字段cs-uri-stem请求的路径。sc-statusHTTP状态码。sc-substatus子状态码。sc-win32-statusWindows底层返回码这个很关键比如值为5代表访问被拒绝也就是权限问题。time-taken请求耗时单位是毫秒。举个例子sc-status是404但sc-win32-status是0代表IIS确实在处理请求但文件本身找不到如果sc-status是403.5且sc-win32-status是5那就指向NTFS权限拒绝不是IIS业务逻辑的问题。这个判断方法我用了很多年可以快速区分IIS没问题是Windows层拒绝和文件丢了或路由错了。6.2 用日志反向验证请求到底有没有到达IIS如果你拿不准问题在网络层还是应用层最好的验证方式就是看IIS有没有记录到这条请求。如果浏览器访问后日志里压根没有这个请求记录说明请求根本还没进到IIS问题在网络层——防火墙、安全组、端口转发、DNS解析。如果日志里有请求就按状态码继续往下查。这么一区分能省掉大把时间。6.3 IIS关闭详细错误信息的正确时机很多安全加固文档让你在IIS里关闭详细错误信息防止内部信息泄露。这个方向本身是对的生产环境确实不建议对外暴露完整堆栈。但我要提醒的是排查阶段千万别关。你先开着详细错误定位到根因、修完问题后再在错误页功能里切回自定义错误页或详细错误关闭状态。否则屏幕上永远一句Runtime Error日志里也看不到有效线索排查会进入非常被动的境地。还有一个细节容易被忽略自定义错误页面在某些配置下会把子状态码吞掉。也就是说你配置了统一的错误页结果用户访问时不管遇到404还是500看到的都是同一个通用页面这会导致你无法从用户侧的截图判断真实错误。所以我在线上错误页设计里会把错误码或子状态码做成响应头带出去或者通过日志记录保留下来而不是一刀切全隐藏。我做了这么多年IIS排障最大的体会是绝大多数配置好网站却无法访问的问题都不是什么高深莫测的疑难杂症而是绑定、端口、防火墙、权限、组件这五件事里某一件没做对。只要你愿意按照分场景定边界 → 看端口绑定和防火墙 → 查权限 → 验组件 → 上日志这个顺序走一遍基本都能在半小时内锁定根因。反倒是那种看到问题就急着改配置、改完又试、试了又改的节奏最容易把简单问题折腾成复杂问题。希望这篇记录能帮你少走一段弯路。