fetch调用ASP.NET Core 6 Web API请求被取消的原因与排查方法

开发者阿泽

2026-8-27

问题背景

通过JavaScript fetch API调用ASP.NET Core 6 Web API支付接口，VS调试时服务端逻辑可完整执行无报错，但正式调用时fetch直接返回已取消响应。
客户端调用代码如下：

let resultPaymentPage = [];
const settingsPaymentPage = {
    method: "POST",
    headers: {
        "Content-Type": "application/json"
    },
    body: JSON.stringify(requestPaymentObj)
};
try {
    debugger;
    const responsePaymentPage = await fetch(APP_SubmitPaymentForm, settingsPaymentPage);
    if (responsePaymentPage && !responsePaymentPage.ok) {
        resultDriverDetailPage = [];
    }
    else {           
        resultPaymentPage = await responsePaymentPage.json();
        debugger;     
        if (resultPaymentPage) {
            loadThankYouPage(requestPaymentObj);
        }
    }
} catch (e) {
    console.log(e);
}

报错触发位置为fetch调用行：

const responsePaymentPage = await fetch(APP_SubmitPaymentForm, settingsPaymentPage);

接口逻辑包含数据库持久化+邮件发送两个长耗时步骤。

问题根因分析

结合「调试正常、部署后异常、接口包含长耗时逻辑」的特征，问题诱因按概率从高到低排序如下：

部署宿主/反向代理的请求超时截断
VS调试时默认直连Kestrel，无额外代理层超时限制，但正式部署时如果挂在IIS、Nginx、云负载均衡/CDN后面，这些组件默认都有请求超时阈值（IIS默认2分钟、Nginx默认60秒）。如果接口同步串行执行数据库操作+发邮件，总耗时超过阈值，代理会直接断开TCP连接，前端fetch就会收到已取消/网络错误，而此时服务端逻辑因为已经启动执行，大概率会继续跑完流程，和描述的现象完全吻合。
前端逻辑主动触发请求取消
如果项目里做了重复提交拦截、路由跳转中断未完成请求、组件卸载自动取消请求的逻辑（通常通过AbortController实现），请求发出后如果触发上述逻辑，会主动abort掉fetch请求抛出错误。调试时因为停在断点、无页面交互/路由跳转，不会触发这类取消逻辑。
服务端异步方法未正确await导致请求提前释放
如果接口里发邮件等长耗时异步操作没有加await，采用fire-and-forget方式执行，框架会在主逻辑执行完后立刻释放请求上下文，后续后台任务执行时如果操作了请求相关对象，可能导致连接异常断开。

分步排查方案

按以下顺序排查可快速定位根因：

确认前端错误和网络详情
打开浏览器开发者工具：
- 在控制台catch块中打印完整错误信息：
```
catch (e) {
    console.log('错误类型:', e.name, '错误信息:', e.message);
    console.log(e.stack);
}
```
  如果错误name是AbortError，说明是主动触发的取消；如果是TypeError: Failed to fetch类的网络错误，基本是连接被代理/服务端断开。
- 切到「网络」面板找到对应请求，查看请求总耗时，如果耗时刚好是固定值（比如60s、120s），可直接判定为超时触发的截断；同时查看请求有没有收到响应头，判断是请求没发出去还是等待响应时被断开。
排查前端主动取消逻辑
全局搜索项目代码中的AbortController、abort()关键字，确认是否有全局请求拦截、路由守卫、重复点击拦截逻辑，在请求发出后触发了取消。测试时请求发出后不要做任何页面操作、不要切换路由，确认是否还会出现取消问题。
验证超时问题
临时注释掉接口里发邮件的长耗时逻辑，直接返回固定成功响应，如果请求能正常拿到结果，就可以确定是耗时过长触发了超时：
- 部署在IIS的话，检查web.config中aspNetCore节点的requestTimeout配置，默认值为00:02:00，按需调大；
- 部署在Nginx后的话，调整proxy_read_timeout、proxy_send_timeout配置到合理值；
- 直连Kestrel的话，在Program.cs中调整Kestrel请求超时限制。
检查服务端日志
开启服务端Trace级别的日志，记录请求进入、响应返回、所有异常的时间点和日志，确认正式部署时请求是否真的完整执行完所有逻辑、有没有未捕获的后台异常。

优化建议

支付类核心接口不要同步等待发邮件、推送通知这类非核心长耗时操作：

优先完成支付流水持久化、状态校验等核心逻辑后，立刻返回响应给前端；
发邮件等非核心逻辑丢到后台任务队列（可以用.NET内置BackgroundService、Hangfire等组件）异步执行，从根源上避免接口耗时过长触发超时，同时提升接口响应速度。

错误截图

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