ASP.Net MVC长时POST请求被服务器重复接收问题咨询

这种自动重复触发长时POST请求的问题真的挺闹心的，我之前帮朋友排查过类似的场景，结合你已经把问题隔离到最简测试项目的情况，咱们从几个常见的核心方向入手排查和解决：

1. IIS 连接/请求超时设置 #

这大概率是最常见的原因——IIS默认的连接超时是120秒（也就是2分钟），刚好和你说的时间点对上。当请求运行超过这个时间，IIS会主动断开连接，某些情况下会触发请求的重复调用；另外ASP.Net本身的executionTimeout默认是110秒，超时后也可能导致异常的请求重试。

• 先去IIS站点的「高级设置」里，找到「连接超时」，把它调到比你的请求运行时间更长（比如设为3600秒）；
• 打开测试项目的Web.config，找到httpRuntime节点，添加或修改executionTimeout属性，比如：

  <httpRuntime targetFramework="4.8" executionTimeout="3600" />
  

  注意：这个设置只在debug="false"的情况下生效，所以测试时要记得切换到发布模式。

2. 应用程序池的回收机制 #

如果你的应用程序池设置了闲置超时或者进程无响应检测，当请求运行时间过长，IIS可能会认为工作进程异常，重启进程后重新处理请求：

• 打开IIS的应用程序池高级设置，检查「进程模型」下的「闲置超时」（默认20分钟，但如果请求长时间占用连接，也可能触发），还有「pingingEnabled」是否开启，如果开启了，建议先临时关闭试试；
• 查看「回收」选项卡，确认有没有设置基于时间或请求数的回收规则，避免在请求运行中触发回收。

3. 前端代理/负载均衡的重试逻辑 #

如果你的服务器前面挂了反向代理（比如Nginx、Apache）或者负载均衡器，这些中间件通常会自带超时重试机制——当它们等待后端响应超过设定时间，就会自动重新发请求到服务器，而客户端完全没操作：

• 直接绕过代理，用本地IP访问测试项目，看是否还会出现重复请求；
• 如果是代理问题，调整代理的超时参数，比如Nginx的proxy_read_timeout，把它设得比请求运行时间长。

4. 异步请求的超时配置 #

如果你的控制器方法是异步实现的，检查有没有设置[AsyncTimeout]属性，这个属性如果配置的超时时间过短，也可能触发异常的重试：

• 移除控制器方法上的[AsyncTimeout]属性，或者把超时时间调大，再测试。

1. 先修改Web.config和IIS的超时设置，把时间拉到足够长，运行测试请求，看是否还会重复；
2. 打开服务器的「事件查看器」，查看「应用程序日志」和「IIS日志」，找有没有超时、进程回收相关的错误信息，这些日志能直接帮你定位根因；
3. 如果有代理，直接访问服务器IP测试，排除中间件干扰。

如果你的业务依赖大量长时POST请求，除了调整超时设置，更稳妥的方式是改用后台任务处理模式：

• 客户端发起请求后，服务器立即返回一个任务ID，然后用Hangfire、Quartz.NET或者ASP.Net Core的Hosted Service（如果是Core版本）在后台执行任务；
• 客户端通过轮询任务ID获取执行结果，这样既避免了长连接超时的问题，也能更好地控制任务的生命周期；
• 同时给请求加上幂等性处理（比如生成唯一请求ID，处理前先检查是否已经执行过），就算真的出现重复请求，也不会重复执行业务逻辑，避免数据混乱。

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