共计 735 个字符，预计需要花费 2 分钟才能阅读完成。
问题形容
最近上了一版需要，其中有一个接口因为后端的计算量超级微小，导致接口工夫要达到七八秒能力返回对应后果。
上了生产环境当前，申请总是失败。
测试环境是好好的 …
查看控制台申请发送的报文相干信息如下：
笔者看一下报文，发现申请的状态从开始的 pending 期待到最初的 canceled 勾销。
点开申请的 Timing 面板查看，发现申请卡在 Connection Star 的Initial connection中央不往下走了。
Initial connection是建设 TCP 连贯的意思，笔者不禁考虑，为啥好好的申请，TCP 连贯连不上了啊，也是一脸懵。
于是，笔者去百度如何解决 Initial connection 过慢失败问题，发现网上的帖子七嘴八舌，如：可能是一个域名下挂着两个ip、如：可能是域名解析 DNS 问题之类的等 …
与此同时，后端共事也在看如何优化本人的接口，让接口返回疾速一些 …
前后端就这样各自钻研了一下午。
解决方案
其实一开始方向就错了，不应该看 Initial connection 超时 就认为是什么环境域名导致 TCP 连贯不上（公司测试环境是 ip 生产环境是 域名 ），导致TCP 连贯不上的起因有很多。
其中有一点就是前端限度了 超时工夫 ，导致了TCP 没工夫去进行连贯、去进行三次握手四次挥手，所以最终的解决方案是：
前端放开超时工夫 axios 中的 timeout 超时工夫限度
既然这个申请会达到七八秒，那么这个就将超时工夫设置为 16 秒，这样的话，工夫足够用了。
import axios from "axios";
const http = axios.create({timeout: 16000 // 给予接口足够的工夫})这样设置当前，发现，问题解决
第一张图是失败的超时勾销的申请，再附上一张胜利的不超时的申请