IIS、Url Rewrite及ARR并发请求限制问题排查与解决咨询

架构老林

2026-7-26

IIS重构后并发请求超时（502.3 64）问题排查与解决

问题背景

原IIS环境中3个应用各对应独立应用池，重构后合并为单个应用N，通过Url Rewrite和ARR代理兼容O1、O2的旧URL。周一早高峰时段，1000+客户端发起合计超1万次API请求，旧配置无异常，但新配置出现系统中断：

推测O1/O2请求运行于对应应用池，代理转发至N的请求运行于NAP，与旧配置架构差异不大；怀疑应用池队列长度限制，但队列满应返回503而非502.3。

ARR后端连接限制：ARR默认后端服务器最大连接数通常为100，远低于高峰并发需求，会导致无法转发请求到NAP，触发502.3。需检查服务器管理器 > IIS > 服务器节点 > Application Request Routing Cache > 服务器代理设置中的连接数配置。
应用池最大工作进程数：NAP默认单进程模式，高峰时无法处理大量转发请求，导致进程阻塞，进而让O1AP/O2AP的代理请求超时。
Url Rewrite代理超时：虽然全局超时为120秒，但Rewrite规则中可能未显式设置超时或未开启响应缓冲，引发请求堆积。
Windows TCP/IP连接限制：默认的TCP半开连接数、TIME_WAIT队列长度不足，会导致新请求无法建立到NAP的连接。
ARR请求队列限制：ARR自身的请求队列被占满时，会返回502.3而非IIS应用池的503错误。
应用池快速失败保护：若NAP出现短暂进程崩溃，快速失败保护可能触发，拒绝新请求，匹配502.3状态码。

ARR详细日志：开启ARR日志（服务器节点 > Application Request Routing Cache > 日志），记录代理请求的转发状态、响应时间、后端服务器状态，定位是转发失败还是后端超时。
性能监视器（PerfMon）：添加以下关键计数器：
- IIS应用池：当前队列中的请求数、正在处理的请求数、工作进程数、失败的请求数
- ARR：当前代理请求数、后端服务器连接数、失败的代理请求数
- TCP/IP：TCP连接数、TIME_WAIT状态的连接数、半开连接数
Process Monitor：监控NAP、O1AP、O2AP对应的w3wp.exe进程的CPU、内存、磁盘IO、网络连接情况，排查资源耗尽或死锁。
IIS失败请求跟踪（FRT）：针对O1、O2应用开启FRT，捕获502.3请求的完整处理流程，确认问题出在Rewrite阶段还是代理转发阶段。
事件查看器：检查Windows日志 > 系统和应用程序中的IIS、ARR相关错误事件，重点关注w3wp.exe崩溃、端口占用、连接失败记录。

调整ARR后端连接配置：在ARR服务器代理设置中，将最大连接数调高至2000+（根据并发需求调整），同时开启连接池复用后端连接。
优化NAP应用池配置：
- 将最大工作进程数设为与CPU核心数匹配的值（如4核设为4-8），开启多进程处理并发请求；
- 暂时关闭快速失败保护或调高失败次数阈值，避免误触发；
- 调高应用池队列长度至2000，排除队列限制影响。
优化TCP/IP参数：通过注册表调整（需重启服务器）：
- HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay：设为30，缩短TIME_WAIT超时；
- HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort：设为65534，扩大可用端口范围；
- HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxHalfOpen：设为10000，增大半开连接数。
优化Url Rewrite规则：在O1、O2的web.config中，为Rewrite规则添加timeout="00:02:00"匹配全局超时，开启responseBuffer="true"减少请求堆积。
临时降级验证：紧急情况下，将O1、O2的请求直接指向NAP应用池，跳过ARR代理，验证是否为代理层问题，再逐步排查。

内容的提问来源于stack exchange，提问作者Andrea Pasianot