这个问题严格意义来说,不是前端的问题,应该是接口的可用性的问题!!!

并行发起三个请求，太浪费资源了。还是先请求一个吧，不行的话next，再不行的话再 next。

同时发起请求，谁最先回来正确结果就用谁的呗

不会简单的在前端对这个连个ip进行分别测试，选择最优的吧？

这个面试也是奇葩，接口经常访问失败不去后端想办法，来找前端。

前端的解决方案不会，
但是这类问题通常是在后端解决吧， 比如接入腾讯云的负载均衡。
操作如下:
1.为前端提供一个域名， 如 http://www.testvip.com/
2.将该域名绑定到一个虚拟IP上, 假设绑定到 201.201.201.201
3.为虚拟IP绑定提供服务的机器IP和端口， 比如绑定 10.0.0.1：10000， 10.0.0.2:10000, 10.0.0.3:10000

这样，客户端访问 http://www.testvip.com/ 时， 会按照负载均衡的策略，将请求转发到合适的服务器上，
如果某一台提供服务的机器挂掉了， 负载均衡会检测并剔除掉该机器， 后续请求不会落到该机器上。

DNS轮询的缺点是， DNS映射的IP变更时， 生效的时间比较长
使用反向代理，则需要为提供反向代理的机器提供容灾方案， 应对代理挂掉时的问题。

还是觉得这种问题，不应该给前端来解决。
提供稳定可靠的服务给外部本来就是后端的职责。

有种技术叫做dns轮巡，飘过⋯⋯

具体情况具体分析吧

同时发起请求，最先返回结果的是没跑的，至于是不是保存成功 ip，是要看那个ip是不是稳定的，万一那个ip也是不稳定的，还是需要重新发起请求。

上面只是一部分，看了几个答案都没有提到当切换host的时候，已经是跨域请求了，所以啊，这题还需要从跨域再分析一下。

我来猜猜，是不是发个异步请求 如果

 http://api.test.com/test.php?cf=

发生了错误 就把中间的host 替换成ip再去请求，重复替换host

我会这么做：

• 用一个数组保存三个请求地址，用一个变量保存实际可用地址，默认值为最常用的那个。

• 当发生第一次请求的时候，使用 Promise 并行发起三个请求，谁先返回用谁，并把成功的请求地址赋给上面说的变量。此后的请求就只需要使用一个地址便可

• 这个过程应该单独封装起来以备后续还需要检查。

• 原生的 Promise 需要改造来应对并行请求的 race condition，若条件允许，会直接使用第三方库如 bluebird 或 RSVP 等等。

重点是必须并行请求，然后利用竟态来阻断后发生的两个请求，也就是当数组中的一个 Promise 被 resolve 之后，剩下的就不再管它了。传统的回调方式你需要在回调内部判断可用地址变量是否已存在然后决定是否跳过后续逻辑，但请求本身都是完成的；又及你无法事先知道哪个接口会失败，所以你还得逐个处理 errors；所以我用带竟态控制的 Promise，原因就是以上。

但我还是觉得一定要在前端做吗？这个明显去弄个反向代理更合理。