Windows升级后IIS 10上Web应用无响应问题排查求助

阿华AIGC实验室

2026-4-21

看起来你升级到Windows Server 2022和IIS 10后碰到了挺棘手的问题——高流量时段两个应用直接无响应，只能靠回收应用池救场，关键是Event Viewer里还没留下有用线索，这确实头疼。结合你提到的应用栈（Angular 6前端、.NET Framework 4.5.1/4.6.1后端，还有调用Solr的应用2），我给你列几个实用的排查方向，你可以一步步试：

1. 先抓性能数据，从指标找突破口

既然日志没线索，性能计数器就是最直接的抓手，你可以用系统自带的性能监视器（perfmon），重点监控这些指标：

应用池的Request Queue Length（请求队列长度）：如果高流量时这个数值持续飙升，说明请求堆在队列里没人处理，大概率是线程池耗尽或者请求被阻塞了
.NET CLR的Threads Count（总线程数）、Blocked Threads（阻塞线程数）：要是阻塞线程数一直居高不下，那肯定是某个环节卡线程了——比如应用2调用Solr时没做异步处理，或者Solr响应慢导致线程挂起
针对调用Solr的应用2，额外加TCP Connections（TCP连接数）和Average Request Time（平均请求时间）：看看是不是和Solr的连接没释放，或者Solr那边拖慢了整个链路

另外，也可以在IIS管理器里找到对应应用池的Worker Processes，右键选择“View Current Requests”，直接看有没有挂了好几分钟的请求，能快速定位到是哪个URL或者模块出问题。

2. 启用更详细的日志和跟踪，抓慢请求细节

默认的IIS日志信息太浅，你得开更详细的跟踪：

给站点加日志字段：在IIS站点的“Logging”设置里，把Time-Taken、Win32-Status、Http-SubStatus这几个字段加上，这样能看到每个请求的实际耗时和隐性错误码
开启失败请求跟踪规则：哪怕请求没返回5xx错误，只要耗时超过阈值（比如10秒）就跟踪。你可以在IIS管理器里直接配置，也可以在应用的web.config里加这段配置（针对.NET Framework应用）：

<system.webServer>
  <tracing>
    <traceFailedRequests>
      <add path="*">
        <traceAreas>
          <add provider="ASP.NET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
          <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module" verbosity="Verbose" />
        </traceAreas>
        <failureDefinitions timeTaken="00:00:10" />
      </add>
    </traceFailedRequests>
  </tracing>
</system.webServer>

跟踪日志会存在IIS的trace目录里，打开能看到请求从进入IIS到处理完成的每个环节耗时，很容易找到卡壳的地方。

3. 排查.NET Framework兼容性和配置问题

你用的是.NET 4.5.1和4.6.1，而Windows Server 2022自带的是.NET 4.8，虽然向下兼容，但有些旧配置或API可能在新环境出问题：

检查应用池的高级设置：比如“Enable 32-Bit Applications”，如果之前Windows 2016上是开着的，现在IIS 10里也要保持一致，不然32位的依赖可能跑不起来
调整web.config和machine.config的线程池/请求限制：比如httpRuntime里的executionTimeout、maxRequestLength，还有machine.config里的maxWorkerThreads、maxIoThreads——新环境的默认值可能和2016不同，高流量下不够用的话就会堵请求
给.NET应用开启详细错误日志：在web.config里把customErrors设为Off，compilation debug暂时设为true（排查完再改回去），这样能看到更具体的.NET内部错误

4. 针对Angular前端的静态资源优化

别忽略前端，高流量下静态资源加载也可能拖垮整个站点：

检查IIS的Static File模块配置：开启客户端缓存和服务器端缓存，避免每个请求都读磁盘；同时确认gzip压缩已经启用（在IIS的“Compression”功能里勾选静态和动态压缩），减少带宽占用
看看Angular打包后的资源有没有设置正确的缓存头：比如给js、css、图片这类文件加长期缓存，只在版本更新时改变文件名，这样浏览器不用重复请求

5. 先加临时缓解方案，再彻底排查

现在手动回收能恢复，你可以先配置自动保护措施，减少业务影响：

在应用池高级设置里，开启自动回收：设置触发条件，比如工作进程内存超过2GB、请求队列长度超过50就自动回收
启用Ping检测：把“Ping Enabled”设为True，“Ping Maximum Response Time”设为30秒，这样IIS会自动重启无响应的工作进程，不用手动操作

如果排查到某个点有异常，比如发现是Solr请求慢，那就要去查Solr的性能，或者应用2里的Solr客户端有没有连接池配置错误（比如没设置最大连接数，导致连接耗尽）。

备注：内容来源于stack exchange，提问作者Anees