如何诊断IIS 10中HTTPERR日志的Request_Cancelled问题

可能的原因 #

• 客户端主动终止请求：用户关闭浏览器、前端框架（如Axios/Fetch）主动取消未完成请求、移动端网络切换后终止连接等场景下，客户端会主动断开TCP连接，IIS会记录Request_Cancelled。
• IIS自身超时配置过短：站点的连接超时或serverRuntime中的headerWaitTimeout设置过小，请求还未完成处理就被IIS主动断开。
• 上游代理/负载均衡超时：若应用前端部署了Nginx、F5等代理设备，它们的超时设置短于IIS，会主动断开连接，触发IIS记录该日志。
• TCP连接异常中断：防火墙、路由器等网络设备的TCP连接超时设置过短，或网络波动导致连接被重置（RST），IIS将这类情况标记为请求取消。
• 应用代码主动取消请求：代码中使用CancellationToken主动终止请求，或调用第三方服务时因超时触发取消逻辑，最终被IIS记录。

排查步骤 #

• 分析HTTPERR日志细节：查看日志中的ClientIP、TimeTaken、Reason字段，如果TimeTaken普遍较短且IP分散，大概率是客户端主动取消；若集中在特定IP段，可能是上游代理或特定客户端的问题。
• 检查IIS站点配置：
  • 打开IIS管理器，查看站点「高级设置」中的「连接超时」，默认120秒，确认是否被修改为过短的值。
  • 执行命令appcmd list config /section:system.webServer/serverRuntime，检查headerWaitTimeout（默认90秒），若设置过小会导致未接收完请求头就断开连接。
• 验证客户端/前端逻辑：排查前端代码是否有主动取消请求的逻辑（如路由跳转、防抖场景），或移动端应用的网络异常日志，确认是否存在客户端主动终止的情况。
• 检查上游代理配置：查看负载均衡或反向代理的超时参数（如Nginx的proxy_read_timeout），确保其超时时间长于IIS的连接超时。
• 网络抓包分析：使用Wireshark在服务器端抓包，判断是客户端发送FIN/RST包、服务器主动断开，还是中间网络设备触发的连接中断。
• 排查应用代码逻辑：检查代码中CancellationToken的使用场景，以及调用第三方服务时的超时设置，确认是否存在主动取消请求的情况。
• 确认网络设备配置：联系运维团队检查防火墙、路由器的TCP连接超时设置，确保其值不短于IIS的连接超时时间。

内容的提问来源于stack exchange，提问作者Albert Feng