前言

日常 Bug 排查系列都是一些简单 Bug 的排查。笔者将在这里介绍一些排查 Bug 的简单技巧，同时顺便积累素材。

问题现象

国际化的兄弟团队向笔者反映了一个问题。我们在访问一个非洲的服务商提供服务的时候，根据DNS解析却是一个美国的IP。但通过登陆非洲节点的机器来看，还确实找到了相应的请求日志，如下图所示:

我们的预期是直接访问非洲节点，那么问题就来了，访问这个DNS解析出来的IP是不是符合预期呢？如果符合预期，那么为什么访问的IP地址是美国的呢？

Traceroute

那么这个问题首先笔者想到的就是traceRoute，结果如下所示:

traceroute -I targetIp (这边-I是使用icmp消息)
1 ip1 
2 ip2
3 ip3
4 * * * 
5 * * *
6 * * * 
7 * * * 
......
16 targetIP

由于安全等原因，途中经过的很多跳路由器关闭了对ICMP TTL为0的超时响应功能。导致我们丢失了中间路径，只能看到前面几跳和最后的targetIp，所以无法得知路由器的沿途路径。那么依旧无法判断请求是不是符合我们的预期。

通过BGP找到相应IP的运营商

既然Traceroute无法判断，那么笔者就考虑其它的辅助决策手段，例如BGP。于是笔者通过bgp.tools输入相应的IP发现它属于某国外CDN提供商A。然后登陆它的官网，发现它有一个功能叫做API加速。类似一个高防服务器，主要功能就是抵挡一些ddos攻击。因为我们对于这个域名的操作是POST而不是GET接口，无法和页面一样使用CDN的缓存加速。所以笔者判定大概率就是使用了这个类似高防服务器的API加速功能。于是，笔者就可以推测出拓扑是下面这个样子:

询问相关参与方

和非洲的服务商交流了一下，发现他们确实是使用了CDN加速功能。于是将推测发给相应的CDN接口人，让他排查了一下。确实是配置错了。我们的请求会先去先跨越半个地球去美国节点，然后美国节点再跨越半个地球去非洲节点。相当于我们的请求绕了地球一圈！

后续优化

后续的优化就非常直接了，让他们在四川找一个加速节点，由于少了四川到美国的这一条横跨半个地球的链路，耗时大幅度减少。虽然这是个非常简单的问题，但是获得了非常大的收益。如下图所示:

总结

任何配置都有可能出错，这些错误可能非常隐蔽，它不会导致请求错误但是会影响耗时。虽然问题非常本身简单，但找到这个问题确需要我们对系统的每一处地方做仔细的Check。解决这些小问题往往会有非常大的收益！