条件没固定下来，几次结果之间就没有可比性
先解析，再端口，后路径，最后做一次应用层验证
把域名解析结果与预期对照。解析到就近节点属正常，但如果结果本身落在内部区间，先处理解析配置，后面的检查都不用做。
对目标端口发起一次连接。能建立说明路径与服务进程都在工作；被明确拒绝说明路径通但没人监听；一直无响应则连路径是否通都无法确定。
逐跳查看响应时间与丢包情况。只在某一跳之后持续变差，问题多半在那段链路；从第一跳就差，更可能是本地出口或接入设备。
发一个只取响应头的请求，看状态码与耗时。状态码正常而内容异常，说明是应用侧的问题，与链路无关，方向可以立刻转过来。
域名先解析出地址，客户端再拿这个地址去连接，是两个独立的环节。解析出错时，无论怎么探测目标端口都不会有结果，因为连接的对象从一开始就是错的。
一个域名可以同时挂着多条解析记录，分别指向不同地址。解析服务会根据发起查询的线路返回其中一条，这就是同一个域名在不同网络下解析到不同机房的原因。
缓存是另一个变量。系统、浏览器与中间的解析服务都可能把上次的结果留一段时间，记录改了而本地还按旧地址连接，表现就是时好时坏。先清一次本地缓存再查，通常就能看出分界。
还有一种常见情形：解析出来的地址归属地显示在某个机房，而那只是内容分发节点的位置，不是数据真正存放的地方。节点只负责就近响应，源数据可能远在别处。
五条，都是排查时最常见的弯路
多数和结论的可靠程度有关
不一定。很多主机与中间设备会主动忽略这类请求，而同一目标的网页访问完全正常。换端口探测或应用层请求再确认一次。
被拒绝意味着对方回了消息，说明路径通、主机在线，只是那个端口没有服务在听；一直等到超时则连主机是否在线都无法确定。
取决于各处的缓存保留时长，短则几分钟，长则按小时计。先找一台没查过的机器验证，能排除本机缓存的干扰。
按顺序各测一次，或直接测域名本身让程序自己挑。只测其中一个地址，得到的结论无法代表全部节点。
正常。部分设备不返回超时消息，只要后面的跳数还能继续显示，路径就是通的，中间的空缺不影响判断。