首先直接给结论：是的，这确实是IIS 8.5在空闲连接超时场景下的标准行为。

我之前处理过不少负载均衡搭配IIS架构的连接问题，对这个机制挺熟悉的。IIS触发空闲连接超时（默认120秒）时选择发送RST而非FIN，核心是为了高效回收服务器资源：

• 正常的FIN关闭需要双向握手确认，这个过程会额外占用资源，尤其在大量空闲连接需要释放的场景下，效率很低。
• 用RST直接重置连接，能快速终止空闲会话，立即释放对应的套接字和连接池资源，避免资源被长期闲置占用。

针对你提到的「供应商应用→Netscalar负载均衡器→IIS」架构出现的问题，这里给几个实用的调整方向：

• 对齐超时配置：把Netscalar的后端连接超时时间设得比IIS的空闲超时短一点（比如110秒），让负载均衡器先主动关闭空闲连接，走正常的FIN流程，避免IIS发送RST导致的通知断层。
• 调整IIS超时阈值：如果业务场景允许，可适当延长IIS的空闲连接超时（在站点「高级设置」→「连接超时」中修改），减少触发RST的频率。
• 配置Netscalar的RST处理：检查Netscalar的配置，开启后端RST的前端通知机制，让它在收到IIS的RST后，主动向前端供应商应用发送关闭信号，避免应用侧一直持有无效连接。
• 优化应用侧逻辑：建议供应商应用增加连接异常捕获逻辑，当检测到连接被重置时自动发起重连，提升架构的容错性。

内容的提问来源于stack exchange，提问作者Raj K