Aspnet网站浏览出现ServiceUnavailable原因

浏览器访问ASP.NET站点只显示Service Unavailable，F12看到503，这个错多半不是页面代码抛出来的，而是请求还没进到ASP.NET页面就被IIS或HTTP.sys挡回去了。500通常才是代码异常，503更像“后面没有可用的工作进程接活”。排查方向要先从应用池和承载环境入手，别急着翻业务代码。

最常见的是应用程序池停了。IIS管理器里看应用池状态，如果显示已停止，原因可能是手工停过、身份验证失败、配置改错，或者应用池连续崩溃触发快速失败保护。IIS默认在5分钟内崩溃5次就会停掉应用池，防止无限重启，这时候浏览器就是503。事件查看器里Windows日志的应用程序和系统日志经常能看到WAS或IIS-W3SVC-WP的记录，配合崩溃模块名能定位是哪个DLL或原生组件在捣乱。应用池身份账户密码过期也会让工作进程起不来，尤其是用域账号跑池子的老站点。

请求队列被打满也会返回503。IIS应用池的请求队列默认长度是1000，工作进程处理不过来，请求就在HTTP.sys里排队，队列一满，新请求直接503。HTTPERR日志里常见“503 1 QueueFull”，路径在C:\Windows\System32\LogFiles\HTTPERR。队列满的背后往往是线程池饥饿：代码里大量同步等待数据库、调用外部接口没设超时、锁竞争，ASP.NET线程池的工作线程被占完，新请求进不来。数据库连接池默认最大100，慢查询、死锁、连接没关会把连接池耗尽，页面线程跟着卡死，最后表现成整站503。

资源耗尽也绕不开。应用池内存涨到几GB、CPU长期打满、句柄数飙升，工作进程可能被IIS回收或直接崩掉。32位应用池的可用地址空间通常只有2GB左右，大对象堆一涨就容易出问题。IIS应用池默认回收间隔是1740分钟，闲置超时20分钟，这些配置本身不坏，但如果站点启动慢、预加载没配好，回收瞬间也可能短暂503。Web园开多个工作进程时，会话和缓存会分裂，某些进程崩了也会让部分请求503。

还有部署和网关层的原因。站点前面挂了ARR、Nginx或云负载均衡，后端节点健康检查失败，网关就会回503。IIS里最大连接数、请求筛选、IP限制配得过紧，也会把正常请求挡掉。ASP.NET的executionTimeout默认110秒，长请求被超时终止后，如果线程没释放干净，后续请求会越积越多。证书绑定错误、端口冲突、应用池位数和本机组件不匹配，也会让工作进程启动失败。

排查时我一般先看IIS里应用池是不是Running，再看事件查看器和HTTPERR日志，确认是队列满、崩溃还是启动失败。然后看性能计数器里的请求队列长度、线程池线程数、数据库连接池和CPU内存。如果应用池反复崩，抓dump比猜代码有用。数据库慢查询和外部接口超时也要一起看，很多503表面是IIS扛不住，根子是一个没设超时的同步调用把线程池拖垮了。把这些点串起来看，比盯着浏览器那句Service Unavailable有效得多。