ASP.NET Core 2部署于IIS 10遇长请求502错误求助

我之前维护ASP.NET Core应用时也碰到过一模一样的场景——IIS作为反向代理转发请求给Kestrel，长耗时操作触发502错误。本质原因是IIS和Kestrel的超时配置不匹配，导致IIS在Kestrel还没处理完请求时就断开了连接。下面是我亲测有效的解决步骤：

1. 调整IIS反向代理的请求超时 #

IIS的ASP.NET Core模块默认有请求超时限制，超过这个时间就会返回502。你有两种配置方式：

• 图形界面操作：打开IIS管理器，找到你的目标站点，双击「ASP.NET Core Module」，在右侧的「Actions」面板点击「Edit Configuration」，把「Request Timeout」改成适合你业务的时长（比如00:10:00代表10分钟）。
• web.config配置：直接在站点根目录的web.config里的<aspNetCore>节点添加requestTimeout属性，这样更方便版本控制：

  <aspNetCore processPath="dotnet" arguments=".\YourApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" requestTimeout="00:10:00" />
  

2. 同步Kestrel的超时设置 #

光调整IIS还不够，得确保Kestrel的超时时间不短于IIS的配置，避免Kestrel先断开连接。在ASP.NET Core 2的Program.cs里配置Kestrel的超时参数：

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .UseKestrel(options =>
        {
            // 保持连接超时时间
            options.Limits.KeepAliveTimeout = TimeSpan.FromMinutes(10);
            // 请求处理超时时间
            options.Limits.RequestTimeout = TimeSpan.FromMinutes(10);
        })
        .Build();

3. 检查IIS应用池的相关超时 #

应用池的两个设置也可能间接导致502：

• Idle Time-out：如果应用池长时间空闲会自动回收，但如果你的长请求刚好赶上回收，也会出错。可以把这个值设为0（永不超时），或者延长到足够长的时间。
• Ping Maximum Response Time：IIS会定期Ping应用池进程，如果响应时间超过设置值就会重启进程。建议把这个值调整为300秒（5分钟）以上，匹配你的长请求耗时。

4. 日志排查精准定位 #

如果调整完超时还是有问题，建议开启日志进一步排查：

• 启用IIS的失败请求跟踪（Failed Request Tracing），可以捕获502错误的详细流程，看是IIS超时还是Kestrel那边抛出了异常。
• 在ASP.NET Core里开启详细日志，记录长操作的开始、结束时间，确认实际耗时，这样能更精准地设置超时值，避免过度配置浪费资源。

额外优化建议 #

如果你的操作耗时特别长（比如超过15分钟），其实不太适合用同步HTTP请求处理。可以考虑：

• 把长操作改成后台任务，比如用Hangfire之类的库，前端发起请求后先返回一个任务ID，然后轮询获取结果。
• 尽量用async/await异步处理请求，这样Kestrel能更高效地利用线程，避免线程被长时间占用导致其他请求阻塞。

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