Azure App Service 230秒超时存疑：日志与实际不符原因咨询

Azure App Service的230秒超时是前端负载均衡器（ARR）的默认限制，但实际场景中确实会出现你观察到的两种差异情况，原因如下：

为什么部分超230秒的请求返回200 #

ARR的230秒超时并非在所有场景下都会强制执行，以下情况会让请求突破限制并正常完成：

• 异步流式响应：如果你的.NET API使用了IAsyncEnumerable实现流式输出，或者禁用了响应缓冲（比如设置ResponseBufferingFeature.Disable()），ARR会持续检测到响应数据流，不会触发超时中断，应用可以完整执行完400-500秒的逻辑并返回200，App Insights记录的是真实的处理时长。
• 内部/私有网络请求：请求来自同一App Service计划内的其他应用、通过VNet访问的内部端点，或使用私有端点时，不走公共负载均衡器的超时逻辑，230秒限制不生效。
• 持久连接场景：如果客户端与服务端建立了持久连接（比如WebSocket、长轮询），ARR的超时规则也会放宽。

为什么部分超230秒的请求返回500 #

当请求触发ARR的230秒超时后，负载均衡器会直接中断客户端与服务端的连接：

• 此时用户端会立即收到5xx错误（通常是502/503，部分场景下会显示500）。
• 服务端的.NET应用可能还在后台处理请求，若连接中断后抛出未捕获的异常（比如TaskCanceledException），且应用的异常处理逻辑将其转换成500状态码，App Insights就会记录下这个500的结果。

关于你的两种推测 #

1. 230秒超时限制并非始终被强制执行——这个推测成立，上述的流式响应、内部请求等场景都会绕过该限制。
2. App Insights记录的是应用返回信息而非用户实际体验——这个推测部分正确。当ARR中断连接后，用户已经收到超时错误，但应用若未检测到连接中断仍继续处理并返回200，App Insights会记录这个200，但用户实际并未收到该响应。这种日志与实际体验的差异，本质是应用未处理连接中断的信号导致的。

排查建议 #

• 查看App Insights的Dependencies表，确认长请求是否依赖了慢响应的外部服务或数据库。
• 检查API的响应配置，确认是否启用了流式处理或禁用了响应缓冲。
• 对返回500的超时请求，查看Exceptions表，确认是否是连接中断引发的异常被转换成了500状态码。

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