记一次前端提交文件请求超时问题

最新推荐文章于 2025-06-10 21:15:10 发布
原创 最新推荐文章于 2025-06-10 21:15:10 发布 · 1.2w 阅读 · 17 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

探讨了在华为云环境中，前端使用Axios发送包含大文件的请求时遇到的超时问题，分析了请求各阶段耗时，指出前端传输耗时（RequestSent）主要受浏览器至ELB外网传输速度影响。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

问题环境：

华为云

问题现象：

前端浏览器提交请求（请求中包含表单参数、文件，且文件大小超过1.5M左右），浏览器在发出请求10秒后提示网络异常，并在console控制台中打印如下日志：

 

同时在后端服务日志中看到整个请求进入到具体服务的处理时长为3秒左右，远小于浏览器的10秒超时；

同时单独的上传附件（异步、el-upload控件），并没有出现以上超时问题；

 

问题原因：

前端Axios中统一设置了10秒超时，导致前端浏览器在后端请求返回时间超过10秒后自动超时断开；

 

问题分析：

前端浏览器显示了10秒超时，而后端服务的处理时间远小于10秒，所以问题没有出在后端服务的处理速度上，起初认为是各种环境（Isito、K8s）引发了超时问题，但是其实我们普遍都忽略了一个问题，就是具体服务日志的处理时间不代表整个Http请求的处理时间，尤其在包含文件上传的请求中尤为明显；

通过Chrome浏览器控制台可以查看一个请求的具体Timing，如下图为具体的一次Timing统计：

大家注意到这次请求的总共耗时15.34s，而其中Request Sent耗时9.87s，Waiting耗时5.46s，Content Download耗时6.20ms，

Request Sent可以简单理解为浏览器端将所有请求数据（表单参数、文件）传输到服务器的时间，

Wating为服务器收到前端浏览器提交的数据后进行处理的时间，

Content Download为服务器返回响应到浏览器的传输时间，

也就是说在提交请求时，花费了将近10秒左右的时间才把浏览器端的请求（参数、>1.5Mb文件）提交到服务器，尽管后端具体服务的处理时间可能才2~3s的时间，但总共的请求时间早已超过10s，最终引发了前端浏览器报出10s超时；

以上Timing是在调大了前端超时时间（60s）后获得，引发超时的请求无法获得Timing统计；

具体Timing说明可参考如下图片：

 

其实，最开始这个问题的排查是从后端Nginx入手并发现问题的，在后端Nginx日志中发现如下异常：

100.125.68.209 - - [12/Sep/2019:17:06:08 +0800] xxx.xxx.com "POST /mx_dspt_service/web/500105/13/98427144886030336/formDispatcher/11/257/0/dGJveC9yZWYvc2F2ZUZvdGFUYm94VXBncmFkZVJlZg== HTTP/1.1" xxx.xxx.com 499 0 "http://xxx.xxx.com/" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.25 Safari/537.36 Core/1.70.3730.400 QQBrowser/10.5.3805.400" "-" 9.954 - /mx_dspt_service/web/500105/13/98427144886030336/formDispatcher/11/257/0/dGJveC9yZWYvc2F2ZUZvdGFUYm94VXBncmFkZVJlZg== -

Http返回码为499，且文件>1Mb，dspt、ota服务都处理完成，且日志均已打印成功，

通过查看Nginx相关文档，发现499含义如下：

 

即客户端主动关闭了连接，导致服务端无法返回响应；

加之在反复提交请求的过程中出现了一次成功请求，并注意到了Timing统计，才最终确定问题根源出现在前端的10s超时设置；

 

扩展：

之前在测试环境都好好的，怎么一切到云环境上就出现超时呢？

测试环境都走的内网，而云环境都需要通过外网后再进入到ELB，

外网的传输速度相比于内网速度会相应慢一些，所以外网才会会出现超时；

如下为目前华为云服务架构：

 

我们在浏览器发出的请求过程如下：

（1）浏览器发出请求，

（2）首先会进入到华为云的ELB（弹性负载均衡，可以简单理解为云上的Nginx，做请求负载、请求转发的，云环境的入口），

（3）之后由ELB转发请求到Nginx（之所以添加了Nginx层，是由于Https证书、私钥绑定在Nginx上）,

（4）Nginx将请求转发到Istio的网关Gateway（Istio集群的外部域名调用入口，在k8s中为Ingress）,

（5）Istio Gateway将请求最终转发到我们的具体服务（其实在Istio中请求首先转发到每个服务对应的边车Sidecar Envoy上，之后由边车再将请求转发到我们的服务）

以上 浏览器->ELB，ELB->Nginx，Nginx-> Gateway，Gateway->Sidecar，Sidecar->app均有传输耗时，但是只有 浏览器->ELB需要通过外网传输，而其他传输都发生在内网耗时较少，

所以一开始提到的前端传输超时（Request Sent）可以理解为主要是受到 浏览器->ELB 传输耗时的影响；

关于Nginx，即可以将Https相关设置放到Istio Gateway中，如此只需依赖Istio即可（将Https与ELB、Nginx进行解耦），

日后亦可对华为云架构调整如下:

 

解决方案：

（1）针对个别请求（带有文件提交、导入文件的请求）调整前端请求超时时间（例如由10s调整为60s）；

（2）优化网络传输速度（外网速度、华为云ELB传输速度）；

补充：

目前大多数服务都是通过后端将文件上传到云存储（浏览器 -> 服务网关Dspt-> 具体服务 -> 云存储），

即大致存在3次文件上传：

（1）浏览器->服务网关Dspt的文件上传（耗时最长，通过外网进入到ELB或网关，后再进入dspt，此处存在多次文件上传，为了便于理解统一归为1次），

（2）服务网关dspt->具体服务的文件上传（内网传输，耗时相对较短），

（3）具体服务->云存储的文件上传（耗时较长，视具体云存储服务性能和网络情况）

若文件可以进行异步上传（附件上传），则均可通过前端浏览器直接上传（前端请求后端获取相应token后直接在前端进行云存储的上传操作），并将上传成功后的文件URL提交给后端服务，以上方式即可省掉前2次的文件上传（节省服务器资源、减少网络传输耗时），而仅通过浏览器直接进行1次文件上传即可，以减少文件上传耗时；

前端大文件上传断点续传解决方案
weixin_52041354的博客
08-30 1996
前端：vue2,vue3,vue-cli,html5后端：asp.net,jsp,springboot,php,数据库：MySQL,Oracle,SQL Server,达梦,人大金仓,国产数据库功能：文件和文件夹批量上传，断点续传，加密上传技术：分块，断点续传，秒传，MD5验证，最近这块好像挻火的，今天早上又有一位网友加我微信，也是想了解这块的技术和方案，实际上我的微信之前就已经在网上公开了，但是论坛里面很多网友还是不知道。
前端接口防止重复请求实现方案
dfc_dfc的博客
04-30 1135
前端接口防止重复请求解决方案
el-upload组件，上传文件失败，:on-error方法失效
最新发布
qq_56610467的博客
06-10 832
el-upload组件方法失效问题及解决方案 问题现象：使用el-upload组件上传文件时，后端抛出异常（响应码500），但前端无法触发on-error回调，导致无法显示错误提示。 原因分析：项目后端封装处理响应，即使抛出异常也返回200的HTTP状态码，仅将响应体中的code字段设为500。el-upload组件无法识别这种异常情况。 解决方案： 在on-success回调中手动判断响应码 检查响应体中的code字段是否为非200状态 通过F12开发者工具确认实际响应结构 关键代码： if (respo
前端网络请求超时提示
qq_58883320的博客
07-14 1085
前端网络请求超时提示
前端请求时间超时
a nice day
07-05 1089
修改前端请求时间在request.js
大文件上传接口响应超时
huofuman960209的博客
04-20 4611
直接冲向了负责前端的同事，温柔地向他提出了疑问，我这个文件上传怎么一直在30s处就中断，你们是不是写死了30s！！！！！！！！！
最近遇到一个问题，前端请求超过5分钟后自动超时
weixin_42993847的博客
07-12 987
1. 前端 web 服务器超时2. Django 应用服务器超时3. 修改后仍然超时应用是基于uWsgi部署的Django架构python web应用；问题排查步骤如下：了解到在 Django 中，请求超时时间通常不是由框架本身直接控制的，而是由前端的 web 服务器（如 Nginx 或 Apache）或反向代理服务器（如 uWSGI、Gunicorn 等）控制的。不过，Django 本身也有一些与超时相关的设置和考虑因素。
解决vue请求接口第一次成功,第二次失败问题
10-14
总的来说，解决Vue请求接口第一次成功、第二次失败的问题需要从多个角度排查，包括但不限于数据的正确管理、请求的类型和跨域策略。通过仔细分析请求和响应的细节，通常可以找到问题的根源并采取相应的解决措施。
[项目构建] 二次封装统一Axios配置 JSTS两个版本实现取消重复请求,超时重发
weixin_63625059的博客
04-25 760
搭建项目时,每个项目都会axios来发请求,但是很多地方都需要发送请求,需要二次封装来解决可能需要处理一些通用的逻辑，比如统一的错误处理、请求拦截、响应拦截、设置请求头等。这个功能有很多应用== -1){return Promise.reject(new Error('不要急'))()=>{if(item!})
前端网络请求详细介绍
Cansiny0320的博客
06-24 2645
???? 前言 之前我们做的页面都是一些没有数据的静态页面(虽然你可能写了一些动画效果，可它却仍然是个静态页面)。那么，啥叫动态页面呢？这就是前端跟网络请求的关系了，如果一个网页在你使用的过程中，向服务器发出了某些网络请求，并接收到了从服务器返回来的数据（当然也可能请求失败），那么，这样的网页才叫做动态页面。也就是说，这里的动态指的是你的浏览器（客户端）和服务器（服务器端）的数据交换。 作为一个真正的前端，所做的事就是负责从客户端获取用户的数据（像是你填写的用户名和密码），然后，把这些数据组织起来，发给服务
vue3 + ts 封装 axios 方法（包含重复请求，接口超时，重复请求接口间隔）
weixin_43386734的博客
05-24 674
这是参考 https://blog.youkuaiyun.com/qq_35624605/article/details/121074339 这位大佬的写法。这个方法涉及到 重复请求只执行一次 重复请求时间间隔 接口请求超时 等功能。应该可以做到复制即用，该有的注释我都加上了。以上就是 axios 的整体封装了。本人ts暂时不算很熟练，献丑了。并在这个基础上进行优化和改造。简单粗暴，直接上代码。
上传文件时遇到的服务器报错：文件过大或上传超时的问题
weixin_43604220的博客
08-12 1868
因请求超时或文件过大，请求被服务器拦截抛出异常。如：IIS报错502.3---请求超时，nginx---413 请求体过大的解决方法；对于ASP.NET程序IIS的超时配置。
调用接口处理时间过长，前端访问超时解决方案
热门推荐
weixin_33830216的博客
10-14 5万+
2019独角兽企业重金招聘Python工程师标准>>> ...
前端Ajax请求超时处理
向着高亮的地方
07-09 1万+
1、步骤解析： 第一步：将网络请求事件赋值给变量ajaxTimeOut 第二步：通过设置timeout属性值，来定义超时时间 第三步：通过complete中的status是否等于timeout来判断是否超时，并设置超时提示处理 2、具体代码 let ajaxTimeOut = $.ajax({ //将网络请求事件赋值给变量ajaxTimeOut url: "/api_v1...
关于前端上传文件到后台，文件大小超出限制，导致上传失败的解决办法。
qq_45985929的博客
04-25 8460
文章出处：Jiangkuobo，微信：jkb_267460 文章目录前言一、使用elementPlus上传图片，出现的问题。二、验证猜想1.验证方式：2.测试结果：3.我的猜想与验证三、关于elementPlus组件上传文件限制大小的解决方法四、新的问题1.spring报错：2.解决方式：总结 前言 最近在做一个后台管理系统时，上传图片没有正常上传成功，总结一下其中遇到的问题，和解决方式。-------关于前端上传文件到后台，文件大小超出限制，导致上传失败的解决办法。 一、使用elementPlus上.
前端页面超时时间设置
真正的大师永远怀着一颗学徒的心
01-13 9530
前端页面超时时间设置
使用SpringBoot发送异步事件的方式解决前端接口调用超时问题
Heartsuit的博客
05-27 3109
一个内部使用的系统，要求实现功能：管理员后台一键操作，不定期（举办活动时）批量更新并导出所有普通用户的用户与密码信息为 Excel 表格文件。 目的是防止时间长了，如果密码不变的话，容易被别人冒用，所以每次不定期的活动开始前，要求重新生成密码。 但是整个过程导致了前端导出接口超时。最终采用 Spring 自带的 ApplicationEventPublisher 异步方案解决因用户量增大导致生成密码、加密、导出的超时问题。
关于前端请求发送时间时而长时而短问题(stalled a lot)
weixin_34007886的博客
01-15 1633
问题来源 问题出现的原因: 同一个页面当请求过多时, 浏览器只会同时处理6个请求, 请求完才会继续请求下一个.一起看看官方的解释吧: 介绍了netWork 请求的一些时间字段代表的含义; 原因找到了, 那现在有什么解决方案呢!, 笔者还在继续寻找答案, 也希望大神给出解答 ...
ElUpload 请求超时
04-02
### Element UI ElUpload 请求超时解决方案 在处理 `ElUpload` 组件上传大文件时，可能会因为网络延迟或服务器配置不当而引发请求超时问题。以下是针对该问题的分析与解决方案。 #### 1. 调整 Axios 的超时时间 默认情况下，Axios 的请求超时时间为 0（即无限制），但在某些场景下可能被设置为较短的时间。可以通过修改 Axios 配置来延长超时时间： ```javascript import axios from 'axios'; // 设置全局超时时间 axios.defaults.timeout = 60000; // 单位为毫秒 (此处设为60秒) // 或者单独调整某个实例的超时时间 const instance = axios.create({ baseURL: 'https://your-api-endpoint.com', timeout: 60000, }); ``` 此操作适用于前端层面，能够有效缓解因网络传输缓慢而导致的超时问题[^1]。 #### 2. 修改后端 API 的超时设置 对于 .NET Core 后端服务而言，默认也有一定的请求超时限制。可以在控制器或者中间件中增加超时时间支持： ```csharp public async Task<IActionResult> UploadLargeFile(IFormFile file, CancellationToken cancellationToken) { var options = new JsonSerializerOptions { WriteIndented = true }; using (var memoryStream = new MemoryStream()) { await file.CopyToAsync(memoryStream, cancellationToken); // 处理业务逻辑... } return Ok(new { Message = "Success!" }); } ``` 同时，在启动配置 (`Startup.cs`) 中也可以调整 Kestrel 的最大请求体大小以及读取数据的超时时间： ```csharp public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } app.UseRouting(); app.UseCors(builder => builder.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader()); app.UseEndpoints(endpoints => { endpoints.MapControllers() .WithMetadata(new AllowAnonymousAttribute()) // 可选：允许匿名访问 .RequireCors("DefaultPolicy"); // CORS策略名称 }); // 配置Kestrel选项 app.ApplicationServices.GetRequiredService<IHostApplicationLifetime>() .ApplicationStarted.Register(() => { var webHost = app.ApplicationServices.GetService<IWebHost>(); ((KestrelServer)webHost.Services.GetService<IServer>()) ?.Features?.Get< IKestrelControlFeature>()? .LimitRequestBodySize(long.MaxValue); Console.WriteLine("Max request body size set to unlimited."); }); } public static IServiceCollection AddCustomizedTimeouts(this IServiceCollection services) { services.Configure<KestrelServerOptions>(options => { options.Limits.MaxRequestBodySize = null; // 移除请求体大小限制 options.Limits.RequestHeadersTimeout = TimeSpan.FromMinutes(5); // 请求头超时时间 options.Limits.MinResponseDataRate = null; // 最小响应速率不限制 }); return services; } ``` 上述代码片段展示了如何通过扩展方法自定义 Kestrel 的行为以适应更大的文件上传需求[^3]。 #### 3. 使用分片上传技术优化体验 当单次上传的数据量过大时，建议采用分片上传的方式减少每次 HTTP 请求的压力。Element-UI 提供了相应的钩子函数支持这一特性实现： ```html <el-upload ref="upload" :action="'/api/upload'" :headers="{'Authorization': token}" :on-progress="handleProgress" :before-upload="handleBeforeUpload" multiple> </el-upload> <script> export default { data() { return { chunkSize: 1 * 1024 * 1024, // 每个分片大小为1MB currentChunkIndex: 0, totalChunks: 0, uploadedChunks: [], }; }, methods: { handleBeforeUpload(file) { const fileSize = file.size; this.totalChunks = Math.ceil(fileSize / this.chunkSize); let start = 0; while(start < fileSize){ const end = start + this.chunkSize >= fileSize ? fileSize:start + this.chunkSize; const blobSlice = File.prototype.slice || File.prototype.mozSlice || File.prototype.webkitSlice; const chunkBlob = blobSlice.call(file,start,end); fetch('/api/chunk',{ method:'POST', headers:{'Content-Type':'application/octet-stream'}, body:chunkBlob }).then(res=>res.json()).then(data=>{ console.log(`Uploaded Chunk ${start}-${end}`); if(++this.currentChunkIndex === this.totalChunks){ alert('All chunks have been successfully uploaded.'); } }) start += this.chunkSize; } return false; // 防止自动提交整个文件 }, handleProgress(event,file,fileList){ console.log(`${Math.round((event.loaded/event.total)*100)}%`); } } }; </script> ``` 以上脚本实现了基于浏览器原生接口手动切割并逐一发送各部分二进制流至服务器的功能[^2]。 --- ### 总结 综上所述，解决 `ElUpload` 请求超时可以从以下几个方面入手： - **前端**：适当增大 Axios 默认超时时长； - **后端**：提升 .NET Core 应用程序接收大型 POST 数据的能力； - **架构改进**：引入断点续传机制降低单一事务复杂度。 这些措施共同作用可显著改善用户体验，并增强系统的稳定性与可靠性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

罗小爬EX

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值