最近我们内网的 k8s 集群做了一次升级，发现经过 APISIX 网关服务都 503 异常了，于是做了一次分析。我们在内网和线上都采用了 APISIX 来做流量网关，对 APISIX 也贡献了 6 个 PR，所以对它的源码还算比较了解。下面排查过程比较曲折，情感上多次起伏，各位看官耐心看完。

现象

经由 APISIX 接管的所有接口请求都 503 了，如下所示。

网络的拓扑结构也非常的简单，就是 APISIX 将流量转发到后端的 java 服务。

APISIX 错误日志如下。

发现是因为域名解析失败，但是非常奇怪的是，在容器内我们通过 curl 请求直接是可以请求成功的

cat /etc/resolv.conf 
nameserver 169.254.20.10
search imdach-dev-dev.svc.kubernetes.local svc.kubernetes.local kubernetes.local gz.cvte.cn

域名到底要不要以点号结尾

其实标准的 DNS 域名就是需要以点号结尾的，但是大家在用域名的过程中往往省略了最后的点，. 是根域名，访问所有域名本质都是要从根域名开始解析，比如 care.seewo.com. 理论要先问根域名服务器 .com 在哪。

这里专门有一篇文章讲这个问题，感兴趣的同学可以深入研究

http://www.dns-sd.org/trailingdotsindomainnames.html

小结

因为内网 K8S 的升级，导致 /etc/resolv.conf 中的 search 末尾多了一个点号，导致低版本的 APISIX（APISIX 2.12 版本以下）的域名解析会失败，与 IPV6 返回 NXDOMAIN 无关。

后记

分析问题一定得静下心，仔细去探究问题的根源，不要急于求成。

今天看到一句话，觉得挺好的，分享给大家，「经验用来对待特殊场景，方法论用来处理通用场景，没有经验可能会慢一些，没有方法论可能寸步难行」

如果上面的分析过程能给你带来一些启发，那就很好了。