Chrome出现请求停滞时EC2服务器重复接收请求问题排查求助

1. 前端侧诱因 #

• Axios超时重试触发：如果Axios配置了timeout参数且未显式关闭retry相关逻辑，当请求耗时超过设定阈值时，Axios会自动发起二次请求，此时第一次请求仍处于pending状态，前端观测到的总耗时为「超时等待时长+第二次请求处理时长」，就会出现3-95秒的停滞，同时后端会收到两次相同请求。
• 请求触发逻辑异常：React组件重渲染时未正确做请求依赖校验，导致重复触发接口调用；或是用户交互类请求（如按钮提交）未加防抖控制，用户短时间多次点击也会触发重复请求。

2. 浏览器&网络侧诱因 #

• 跨域预检请求异常：如果是跨域POST请求，Chrome会先发送OPTIONS预检请求，若Zuul/ELB未正确处理OPTIONS请求、响应超时，Chrome会等待超时后自动重发原始业务请求，既会拉长前端总耗时，也会导致后端收到两次请求。
• TCP连接复用故障：Chrome对同域名的TCP并发连接数有限制，请求量较高时后续请求会进入排队队列；如果ELB/Zuul主动切断了空闲TCP连接但浏览器未感知，浏览器会复用失效连接发送请求，等待超时后才会重建连接重发请求，也会出现长停滞。

3. 网关&负载均衡侧诱因 #

• Zuul超时配置不合理：当Zuul的connect-timeout（连接超时）、socket-timeout（读取超时）参数配置值小于接口实际最大耗时，Zuul会主动断开与前端的连接，但已经转发到后端的请求会继续执行，此时Axios检测到连接断开后自动重试，就会出现重复请求和长耗时。
• Zuul重试逻辑开启：如果Zuul配置了请求重试规则，第一次请求转发到EC2实例出现超时/错误时，Zuul会自动将请求转发到其他正常实例，导致后端收到两次相同请求，前端总耗时为两次请求处理时长之和。
• ELB空闲连接超时配置不匹配：ELB默认的空闲连接超时时间如果短于Zuul/后端服务的超时时间，ELB会主动断开空闲连接且未通知上下游，前端复用失效连接发请求时会等待超时后重发，触发重复请求。

4. 后端服务侧诱因 #

• 部分EC2实例异常：部分EC2实例CPU、内存、IO负载过高，或是实例网络出现抖动，请求打到异常实例时响应超时，触发上层重试逻辑转发到正常实例，就会出现前端停滞、后端收到两次请求的现象。

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