1、首先了解情况：客户的SSL/TLS证书要过期了，所以进行了证书替换工作，但是替换之后，有一部分客户端还是提示证书已过期，如图所示：

2、看这个报错是非常的清晰的，就是证书过期的问题，但是为什么同事没找到过期证书配置在哪里？是不是存在WAF或者CDN之类的中间层？

我们通过DNS可以看到确实是解析到阿里云对应是SLB上面，跟小伙伴的说法也是对得上的。我们已经详细的排查了SLB以及对应的NGINX-ingress后端服务，发现证书确实已经替换为新证书了。

3、这个时候阿里云的售后工程师反馈说：可能是ingress的一个bug，因为我们替换证书的时候，不是新建一个新的secret，而是在老的secret上面进行修改，有可能触发了NGINX的bug，导致有部分站点的证书并没有被替换掉

4、我们新建了一个secret，并全部执行了替换操作，但是结果移动端还是一样的报错信息。这就说明不是这个问题

5、客户怀疑我们之前升级k8s的时候，由于阿里云ACK的限制，我们把SLB由7层监听改为4层监听，证书也由SLB层下放到了ingress层，是不是ingress层存在某种限制？我们测试了7层监听，发现确实没有证书报错了。但这只是简单的测试，我们也不能确定，并且现在系统只是部分用户不能正常使用，我们无法无损的情况下把4层监听切换到7层监听

6、我们通过浏览器控制台上面看到: 所有页面里面存在部分是使用http协议，是不是这里存在https/http协议混用的问题？

7、把情况反馈给客户之后，客户进行了排查，最终反馈是：PC端的页面就是这样的，移动端不存在此问题。到此问题没有太多的思路，由于大部分用户还是正常访问的，我们跟客户商定在业务低谷尝试SLB 4层监听切换为7层监听。

8、在不影响业务的情况下，我们还是想再进行一次确认操作。我们通过kubectl krew ns 和 kubectl krew mtail 插件，对NGINX ingress 所有pod进行log跟踪，结果如图所示:

我的公网ip是 36.28.223.82，通过vim进行搜索，结果非常意外：我们通过日志确定请求没有落到NGINX ingress上面。由此我们得出两个可能: 1、请求没有到nginx-ingress；2、TLS或者TCP握手失败。

9、通过上面的日志，我们得出两个可能。但是我们还要再次确认，到底是怎么回事。我们通过tcpdump进行抓包分析，结果如图所示

我们通过wireshark分析了我们抓取到的数据包，跟我们在第8步跟踪日志得出的结论是相对应的。不过这里更近一步，连TCP的连接都没有建立。

10、客户跟我们反馈过：他们前段时间开通了对ipv6协议栈的支持，并且我们步骤1通过nslookup也查询到了相关的解析，那么是不是用户通过ipv6协议进行的访问，我们没有配置ipv6相关的证书。之前我一直无法复现问题，客户告知我，通过移动端4G/5G 可以稳定触发。我通过4G确实触发了此问题，我建议客户关闭ipv6的DNS解析，我们再进行尝试。结果如图：

我们停止了ipv6的DNS解析，但是访问还是异常。这时候确实不确定问题的根源，但是肯定不是 SLB 7层监听跟4层监听的问题。我们在手机上面抓包又非常的麻烦。

11、最终客户反馈：确实是ipv6证书的问题，他们的ipv6是通过电信做的。他们把证书交给电信之后，访问就恢复正常了。我们之所以暂停ipv6解析之后，还是存在问题，估计是 LDNS缓存导致的。我们通过电信云官网了解

确实是支持https加密传输，说明问题确实是在ipv6这里。

12、我们通过抓包可以看到电信适配ipv6到底是怎么做到的，如图所示:

其中240e:390:e78:ce0:cbb9:49e:fa14:faa7 这个ipv6的地址是我家的ipv6地址，101.226.7.210这个Ipv4的地址是上海电信的IP地址，由此可见电信实现ipv6支持是使用反向代理的方式来做的。这说明我们确实需要在电信云上面配置SSL证书。

总结：经历了这么多波折，最终才定位到是ipv6的问题，主要原因是我自己无法复现问题。在国家大力推广ipv6的大环境下，ipv6可能会越来越普及。大家需要尽快熟悉ipv6，我自己是连夜调整了自己的网络适配了ipv6。

引用1: https://en.wikipedia.org/wiki/IPv6

引用2: https://www.ctyun.cn/document/10018847/10018856