Azure应用服务上传1GB以上大文件时ASP.NET Core 5 API返回502错误咨询

• 你遇到的30秒触发502的问题，核心原因不是负载均衡的230秒空闲超时，是Azure应用服务前置ARR反向代理的默认请求超时阈值，这个配置不受Always On开关影响，默认值就是30秒。调整时可以通过应用服务的web.config配置节点，在system.webServer/proxy配置项中设置requestTimeout为匹配业务实际上传时长的阈值（比如按1GB文件的公网传输时长设置为600秒），这个配置对Windows/Linux托管的应用服务都生效，不需要手动进容器修改文件。
• 核对流读取环节的实现逻辑，确认哪里抵消了流式上传的效果：
  • 排查整个请求链路的中间件，确认没有对请求体做全量缓冲——比如默认的异常处理、身份认证组件如果显式把整个请求体加载到内存，会直接让流式机制失效，长时间没有有效数据传输，被前置代理直接掐断连接
  • 确认ProcessStreamedFile方法的实现是逐块把流写入存储介质，没有把上传的文件全量读到内存，避免内存占用过高导致工作进程崩溃重启，触发502
• 检查各层级的请求大小限制：除了代码里配置的MultipartBodyLengthLimit、MaxRequestBodySize，还要同步确认应用服务托管层的内容大小限制是否匹配1GB以上的文件要求，未放开的配置会直接造成连接中断。
• 验证实例的实际网络吞吐：Premium P1v3的公网入向带宽是固定值，1GB文件全量经过应用服务中转时，很容易因为带宽打满导致TCP连接超时，被前置代理终止，这种场景下哪怕把超时调到再大，也会频繁出现连接重置。

这个方案是大文件上传的标准生产实现，完全绕开应用服务当中转节点的性能瓶颈，从根源解决超时问题：

• 后端API只负责生成带权限限制的Blob SAS访问令牌，配置好令牌的写入权限、目标存储容器、有效时长、允许的最大文件大小，完全不参与文件流的实际传输
• 前端拿到令牌后直接对Blob发起分块上传，单块大小可以根据实际网络情况调整（一般4MB-100MB），天然支持断点续传、实时上传进度统计
• 你已经做好的轮询状态接口可以直接复用：前端每传完一个分块就回调后端更新上传进度记录，后端只存元数据，完全不需要承担大文件的流中转IO，根本不会出现长时间持有大请求连接的问题
• 如果短期不想大改前端上传逻辑，可以在后端接口里生成SAS后，用302重定向把请求跳到Blob的上传地址，应用服务只处理一次轻量的重定向请求，不持有大文件的传输连接，自然不会触发502。

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