IIS 网站无法访问、500 错误的排查
网站突然返回 500 内部服务器错误，或根本无法连接；事件查看器出现 ASP.NET 异常、模块加载失败。500 类错误属于服务器端，需从应用池、文件权限、.NET 版本与配置四方面入手，定位真实异常是关键，盲目重启往往治标不治本，因此第一步应是拿到详细错误而非急着重启站点。
原理与判断
IIS 的 500 错误是服务器端异常的统称，它掩盖了从配置、权限到代码运行时的各类根因。很多管理员遇到 500 直接重启站点，结果问题复现。正确的做法是由详细错误页与事件日志拿到真实异常，再沿着应用池、文件系统权限、.NET 版本这条主线逐层排查。先确认是连不上（网络/端口）还是能连但报错（应用层），能把排查范围瞬间缩小一半，避免在不相关的层面浪费时间。同时留意应用池回收日志里的退出码，它能提示是内存超限还是进程崩溃，比凭感觉调参数可靠得多。把常见 500 子码（如 500.19、500.21、500.23）对应到具体成因，排查会更直接。
一、确认错误类型
- 在服务器端用浏览器访问 localhost，区分是网络层（连接失败、端口未监听）还是应用层（500）问题。
- 临时开启详细错误：在 web.config 中设 customErrors mode=Off 或将 httpErrors errorMode=Detailed，定位真实异常信息与堆栈。
- 查看『Windows 日志——应用程序』中来源为 ASP.NET、IIS-W3SVC 或 .NET Runtime 的事件，记录异常类型。
- 用 curl http://localhost -v 或浏览器开发者工具查看响应头中的 X-AspNet-Version，辅助判断版本与管线。
二、检查应用池与身份
- 应用池是否停止或被回收：Get-WebAppPoolState；若频繁回收检查内存限制、固定间隔回收与空闲超时设置。
- 身份权限：应用池账户（如 ApplicationPoolIdentity）需对站点目录有读取与执行权限，用 icacls 站点目录 核对并补授。
- .NET 版本不匹配会导致 500.19、500.21，确认应用池 CLR 版本与站点一致，托管管道模式（经典、集成）匹配。
- 确认临时目录 C:/Windows/Microsoft.NET/Framework64/…/Temporary ASP.NET Files 对应用池账户可写，否则编译失败报 500。
三、排查配置与依赖
- 运行 %windir%/system32/inetsrv/appcmd list config 检查非法配置节或重复节，常见为手写 web.config 标签错位。
- 检查缺失的模块或处理程序映射，必要时重新注册：%windir%/Microsoft.NET/Framework64/v4.0.30319/aspnet_regiis -ir。
- 确认站点绑定的端口、主机头与 SSL 证书有效且未过期，证书绑定的私钥可被 IIS 访问（否则 HTTPS 站点起不来）。
- 用 Get-WebConfiguration 比对生产与本地的配置差异，定位漂移项并修正。
四、依赖与运行时
- 检查站点依赖的数据库连接串、外部 API 是否可达，后端超时也会以 500 暴露给用户。
- 确认 vcredist、.NET Core 运行时等本机依赖已安装，缺失会导致模块加载失败与启动异常。
技术总结：IIS 的 500 错误大多源于应用池停止、文件权限不足、.NET 版本不匹配、配置非法或后端依赖异常。先看详细错误与事件日志，再核对应用池状态、身份权限、临时目录可写性与配置，逐项排除即可恢复。把详细错误当作路标，排查就有章法。