问题背景

用户通过类似nginx代理TCP协议的方案来暴露业务服务，但是发现请求多次有偶发不通的情况，严重影响他们使用。

排查信息收集

问题排查

1 拿到这个问题后，首先抓包确认下，这个请求是被拦截了，还是服务端自身返回的，同时在slb以及客户端侧做了抓包

2 通过对比slb和客户端的数据包发现是服务端直接做了拒绝，ttl值也可以做辅助佐证，但是健康检查全部是正常的，这个地方其实当时我有点疑惑，从抓包来看基本可以确认可能是某个rs有问题，导致请求转发给对应的rs后，不通引发了异常

3 进一步登录服务器里面做问题排查，首先客户端50000是转发到ecs上的30295端口，集群用的ipvs的转发策略，使用ipvsadm -L |grep 30295 看了下转发的rs，发现转发给了nginx-ingress-controller的50000端口做处理，信息如下：

4 经过slb的抓包，我怀疑可能是转发给这 10.122.15.220 or 10.122.16.101 这两个IP其中一个不通，然后在ecs上 telnet做测试，果然发现请求10.122.15.220 50000不通，这也就想通了，为什么会偶发的不通（其实健康检查能通过是符合预期的， 因为三次里面才会有一次不通，所以健康检查的错误阈值没到，认为是OK的）

解决方案

在集群里面找的10.122.15.220 IP对应的pod后，进入pod里面看，发现果然没有50000的端口监听，也就导致了ipvs通过rr轮训的机制，把请求转发给这个pod后，因为没有50000的端口监听引发了异常，让用户把这个异常的重建下，重新reload加载了下配置后解决。