早上九点，网问客户电话打进来，站无语气急得像着火——官网打不开了。法访我远程一看，网问IIS管理器里站点明明在跑，站无进程也活着。法访可浏览器就是网问转圈圈，最后甩出一句“无法访问此网站”。站无

这种问题我遇过不下二十次。法访多数人第一反应是网问查防火墙，或者怀疑服务器宕了。站无但真正的法访原因往往藏得更深，也更蠢。网问

先看端口。站无站点绑定的法访80端口被占用了？用netstat -ano | findstr :80看一眼，如果是SYSTEM进程（PID 4）占着，十有八九是HTTP.sys在作怪。之前有个客户装了SQL Server Reporting Services，它偷偷把80端口抢走了，IIS只能干瞪眼。解决办法也简单——停掉那个服务，或者给IIS换个端口。

端口没问题的话，检查应用程序池。IIS的坑就在这儿，池子停了，站点照样显示“已启动”，但访问就是不通。右键查看池状态，如果显示“已停止”，直接启动。但启动失败的话——比如提示“工作进程无法终止”——八成是权限问题。站点文件夹的NTFS权限没给IIS_IUSRS组，或者应用程序池标识对应的用户没读权限。我之前遇到过一例，开发人员把站点文件夹放在C盘根目录下，结果IIS进程根本没权限进去。

还有一种情况，访问返回500错误，而不是“无法访问”。那基本是代码或配置问题——web.config里写了不存在的MIME类型，或者.NET版本不匹配。但你说“无法访问”，连错误码都没有，那大概率是连接层的问题。

再往下挖，检查绑定。站点绑定的主机名对不对？你访问http://localhost能通，但访问域名不通，那就是主机名没绑或者DNS解析出错了。有个客户死活打不开站点，我一看，他绑定了www.example.com，但浏览器输入的是example.com——没加www。这种低级错误，真能把人气笑。

最后查一下HTTP响应头。用curl或者Postman发个请求，看返回什么状态码。如果返回503，那是服务不可用，多半是应用程序池的回收设置太激进，或者启用了重叠回收但新进程没起来。如果返回401或403，那是认证或授权问题——IIS默认允许匿名访问，但如果你改了身份验证方式，又没配置对应的Windows账户，就会卡在登录环节。

说真的，IIS这玩意儿，配置项多，文档少，全靠踩坑攒经验。最烦的是那种“间歇性无法访问”——有时通有时不通。这种多半是应用程序池内存溢出导致频繁回收，或者站点绑定了多个IP，其中某个IP失效了。

检查的时候别慌，按顺序来：端口→池状态→文件权限→绑定→认证方式。每查完一项，用浏览器刷新一次，看有没有变化。别一次改好几个地方，否则出了问题都不知道是哪步搞的。

要是全查完了还是不行，干脆重启一下W3SVC服务。别笑，这个土办法治好过不少疑难杂症。IIS的服务状态有时候会“假死”，进程在跑但响应机制卡死了，重启服务能强制清理掉那些僵死的连接。

最后提醒一句——看看系统事件日志。IIS的错误信息不一定显示在界面上，但会写进Windows日志里。打开事件查看器，筛选“IIS-W3SVC”来源，经常能看到具体报错原因，比瞎猜强百倍。

实在不行，就把站点导出配置，删掉重建。虽然粗暴，但比跟配置项死磕快得多。反正站点的物理文件又没丢，重新指一下路径就行。