写这篇文章的初衷很简单，就是给有需要的人提供一个处理类似问题的思路，这个故障其实很简单，有经验的应该可以直接判断出来了，但是在没有经验且没有遇到过这种问题的情况下，可以稍加借鉴一下，我这里仅仅是写出一个思路，有问题可以提出来一块讨论。原谅我涂掉了一些东西，轻拍...
最近在上架新设备的时候，替换旧设备的解析，在下发系统对该设备进行探测时直接报出了探测失败的错误，涉及域名较多，首先我找到了下发系统负责人问他们错误原因，他们在下发系统设备上手动wget抓某个域名无法访问，telnet 80端口是通的。
接着我要来了下发系统ip，查看访问日志，发现根本没有访问日志，可是确实是访问到了这个设备，并且探测设备也没有收到状态码之类的信息，我在探测时候同时查看访问日志，也没发现该ip的访问记录，所以判断问题出在网络层，没有建联成功，也没有到应用层呢，于是决定抓包分析下原因。
一、
我固定某个域名的ip，打开浏览器访问测试，结果如下：
有经验的运维看到这个错误应该会大概猜出来问题出在哪里了。
二、
浏览器访问测试，链接被重置，直接无法访问，于是登陆到重庆的一台服务器，对该设备域名进行curl测试，并且两端抓包，结果如下：
202为客户端，240为server端
首先大概解释一下这个三次握手数据包流程。
1、client端给server端发送syn包（无问题）
2、server端给client端发送syn，ack包（无问题）
3、4、client端给server端发送ack确认包和开始get数据（正常）
5、server端给client端发送了一个FIN，ack结束包（不正常）
6、7、client端给server端发送了一个ack确认包和fin，ack结束包（相对上一个包来看正常）
8、9、server端给client端发送了rst，ack包（不正常）
结论：
从以上可以看出在第4个包get数据之后开始出现不正常，且第二个包时候可以看到server端到client端ttl为52
三、
这里数据包传输就不多说了，我们注意看第5个包，server端到client端的时候，发送了一个FIN,ACK包，我们知道正常情况下这是不应该的，我们在注意看下面，TTL变成了118，与 上面结论中提到的ttl为52不符合，且结合一中浏览器访问的现象可以得出结果，这个server的机房出口很可能是做了防火墙的限制来控制域名的白名单等情况。
我们在server端查看抓到的数据包为client端主动向server端发送了rst包，所以说机房出口或者某条路上有中间人在干扰正常访问。不过要注意的是，“中间人”干扰这种方式并不 一定可以只根据ttl判断出来，有的时候比较高明的干扰，ttl并不会太明显的看出来，也存在有时候客户端抓包中不会看到server端发送过来的FIN等异常数据包，因为server端根本就懒 得理你。当然我们判断异常的根本还是看三次握手的情况的。其实我们根据ttl有时候也可以大概的猜测出来这个“中间人”距离哪一端较近。
当然事无绝对，我写出来这个的目的只是提供一些平时处理故障的思路而已，有不对或者描述不准确的地方还请大家指正。