Azure托管ASP.NET Core网站慢网下载中断问题排查求助

我结合你的场景、代码和Azure共享基础设施的特性，整理了几个最可能导致问题的原因，附对应的解决思路：

1. Azure App Service 请求超时限制 #

Azure App Service的共享/基础计划默认有**230秒（约3.8分钟）**的请求超时阈值。当慢速Wi-Fi下载较大ZIP包时，传输时间很容易超过这个限制，Azure会主动终止连接——这直接导致ZIP文件因为未完成收尾写入而损坏；而LAN连接速度快，能在超时前完成传输，所以不会出问题。

验证与解决：

• 登录Azure门户，进入你的App Service，在配置 > 常规设置里查看「请求超时」的数值；
• 共享计划最大只能设置到230秒，若你的文件确实需要更长传输时间，建议升级到Basic及以上计划（支持更长超时）；
• 代码里建议监听RequestAborted令牌，当连接中断时及时停止写入，避免无效操作：

return new FileCallbackResult(
    new MediaTypeHeaderValue("application/octet-stream"), 
    async (outputStream, context) => 
    {
        using (var zipArchive = new ZipArchive(new WriteOnlyStreamWrapper(outputStream), ZipArchiveMode.Create))
        {
            foreach (var kvp in filesToZip)
            {
                // 检查连接是否已中断
                if (context.HttpContext.RequestAborted.IsCancellationRequested)
                    break;

                var zipEntry = zipArchive.CreateEntry(kvp.PathInZip, CompressionLevel.NoCompression);
                using (var zipStream = zipEntry.Open())
                using (var fileStream = new FileStream(kvp.PathAtServer, FileMode.Open))
                {
                    // 传递取消令牌，中断时停止拷贝
                    await fileStream.CopyToAsync(zipStream, context.HttpContext.RequestAborted);
                }
            }
        }
    })
{
    FileDownloadName = string.Format("Archive_{0}.zip", order.Id)
};

2. 未启用分块传输编码 #

你的代码用FileCallbackResult直接写入输出流，但如果没启用分块传输编码，服务器会先尝试计算整个ZIP包的总大小，再一次性发送数据。对于大文件，慢速网络下这个等待过程会持续很久，容易触发连接中断；而LAN速度快，能快速完成传输。

解决办法：在Action中手动启用分块传输：

// 在返回FileCallbackResult之前添加
Response.Headers.Append("Transfer-Encoding", "chunked");

分块传输会把数据拆成小块逐个发送，不需要预先计算总大小，更适配慢速网络下的大文件传输。

3. 共享计划的资源配额限制 #

共享基础设施（比如Free/Shared计划）有严格的CPU、内存和并发连接限制。当你的应用长时间保持下载连接时，可能会因为占用资源过久，被Azure的资源管理器强制终止连接——毕竟共享计划的资源是和其他租户共享的，Azure会优先回收长时间占用资源的会话。

验证与解决：

• 查看Azure门户中App Service的监控 > 指标，检查CPU、内存和网络带宽的使用情况，看是否有触及配额的情况；
• 如果资源确实紧张，建议升级到Basic或Standard计划，这类计划有独立的资源配额，不会轻易被强制中断连接。

4. ZIP文件写入未处理中断场景 #

ZIP文件的结构比较特殊，它的目录索引信息是在文件末尾写入的。如果连接中断时，ZipArchive还没完成所有条目写入和收尾操作，最终下载的文件就会因为缺少关键的目录信息而损坏。

除了前面提到的监听RequestAborted令牌外，你还可以考虑实现断点续传功能，让客户端在连接中断后能从断点处继续下载（需要结合HTTP的Range头处理，实现相对复杂）。

5. 客户端侧的连接中断 #

有时候看起来是服务器中断连接，但实际是客户端（浏览器、下载工具）在长时间等待后主动断开了连接。比如部分浏览器对下载请求有默认超时时间，或者Wi-Fi信号不稳定导致客户端侧的连接丢失，最终导致ZIP文件未完成下载而损坏。

验证方法：用不同的下载工具（比如curl、Postman）测试下载，排除客户端的问题；同时建议用户下载时确保Wi-Fi信号稳定。

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