这次故障的表象很容易让人误判：应用提示域名无法访问，但同一台机器上的部分服务仍然正常，其他系统访问同一域名时也出现了不同表现。有人先改 hosts，有人先重启网络，还有人直接怀疑防火墙。真正有效的排查方式，是沿着“名称解析—本机配置—主机过滤—路由转发—上游服务策略”的链路逐层验证，而不是反复尝试可能有效的操作。
先确认故障边界：是解析失败，还是解析后无法连接
排查开始时，先不要急着修改配置。需要确认三个问题：故障是否只影响一个域名，是否只影响一台机器，以及失败发生在解析阶段还是连接阶段。
在 Windows 或 Linux 上都可以先使用：
nslookup <目标域名>如果返回了地址，说明至少有一个 DNS 查询成功，问题不一定是“DNS 完全不可用”。此时还要观察返回的地址是否符合预期，以及不同系统使用的 DNS 服务器是否相同。
如果提示无法找到域名、查询超时或服务器没有响应，应先把问题限定为 DNS 链路，而不是立刻检查应用端口。可以在不同系统上重复执行同一查询，并记录每台机器实际使用的 DNS 服务器。跨系统故障中，一个常见误区是只比较“配置文件里写了什么”，却没有确认当前请求到底发给了哪台 DNS 服务器。
如果域名能够解析，但应用依然无法访问，就要把解析结果带入后续排查。此时问题可能出在本地防火墙、路由、目标地址不可达，或应用使用的地址与人工查询得到的地址并不一致。
第一步：确认本地 hosts 是否改变了解析结果
本地 hosts 的优先级通常高于普通 DNS 查询，因此它可能让一台机器表现正常，另一台机器表现异常。排查时应分别检查 Windows、Linux 以及其他系统上的 hosts 文件，确认目标域名是否存在手工映射。
检查的重点不是“文件是否存在”，而是以下几类内容：
- 是否有目标域名的旧地址；
- 是否有同一域名的多条映射；
- 是否同时写入了主域名和别名；
- 是否存在格式错误、不可见字符或被注释误解的内容；
- 修改 hosts 后，系统或应用是否仍在使用缓存结果。
如果 hosts 中存在记录，可以暂时移除或注释该条目，再重新执行 nslookup。如果查询结果发生变化，说明本地静态映射确实参与了故障。此时不要把“删掉 hosts 后能访问”直接当作最终修复，还要判断这条映射原本为什么存在，以及是否有脚本、配置管理工具或系统策略会再次写回。
如果 hosts 没有相关记录，或者移除后问题仍然存在，就继续检查 DNS 查询本身。不要在这一步反复清理缓存，因为清缓存只能排除旧结果，不能解释上游服务器为什么返回错误或拒绝查询。
第二步：确认 DNS 请求是否真的发出并得到响应
nslookup 能说明查询结果，但不一定能说明请求在网络上经历了什么。尤其是在 Linux 主机、虚拟机、容器或多网卡服务器上，DNS 请求可能从与预期不同的接口发出，也可能被本机规则拦截。
这时可以使用 tcpdump 观察 DNS 查询流量：
tcpdump实际使用时，应按照目标网卡、DNS 流量和目标服务器进行过滤。重点观察四件事：
- 是否有从本机发出的 DNS 查询；
- 查询发往哪一台 DNS 服务器；
- 上游是否返回响应；
- 响应是正常记录、错误信息，还是根本没有返回。
如果 nslookup 显示超时，而抓包中只有请求没有响应，问题可能位于本机到 DNS 服务器之间，也可能是 DNS 服务器没有处理该请求。如果抓包能看到正常响应，但 nslookup 仍然失败，则应检查本机解析库、缓存服务或应用自身的解析方式。
如果请求发往了错误的 DNS 服务器，优先修正网络配置，而不是继续检查防火墙。多网卡、VPN、虚拟化网络和 DHCP 下发配置都可能导致系统实际使用的 DNS 与人工预期不同。
第三步：检查本机防火墙规则，而不是只看服务状态
DNS 查询失败时，防火墙是常见原因，但不能仅凭“防火墙已启用”就下结论。需要确认规则是否影响了 DNS 请求和响应，以及规则作用于哪个接口、哪个方向。
在 Linux 上可以检查 iptables 规则：
iptables实际检查时，应关注输入、输出和转发方向中的相关规则，并结合接口、协议、目标地址和处理动作判断。对 DNS 查询来说，不能只看出站请求；请求发出后，返回流量是否被丢弃同样重要。
如果规则计数在执行 nslookup 前后发生变化，说明查询流量确实经过了相关规则。此时要进一步判断是请求被拒绝、响应被丢弃，还是规则只影响了转发流量。不要为了验证而直接清空全部防火墙规则，这会破坏现场，也可能造成更大范围的服务中断。
跨系统排查时，Windows 主机可能使用自己的防火墙策略，网络设备也可能有访问控制规则。Linux 上检查 iptables 只能说明该主机的规则情况，不能替代对 Windows、虚拟机宿主机或网络设备的检查。
如果暂时放宽某条规则后 DNS 恢复，应记录原规则、受影响的接口和流量方向，再按最小范围恢复配置。临时关闭防火墙只能用于短时间验证，不能作为最终方案。
第四步：区分“到不了 DNS”与“DNS 不愿意回答”
当本地 hosts、抓包和防火墙没有解释问题时，下一步是检查到 DNS 服务器的路由。
可以使用：
traceroute <DNS服务器地址>路由跟踪的目的不是要求每一跳都返回结果，而是确认路径是否在某个位置中断、是否走了错误出口，以及不同系统是否经过了不同的网关。某些设备会限制或不响应路由跟踪报文，所以中间出现不回应并不等于该设备一定故障。
这里要把两个现象分开：
- 如果路由本身无法到达 DNS 服务器，重点检查默认网关、静态路由、虚拟网络和中间设备的转发策略；
- 如果路由能够到达 DNS 服务器，但 DNS 查询得到拒绝、空结果或策略相关响应，问题更可能位于 DNS 服务端或其访问控制策略。
还要注意，能访问 DNS 服务器的地址，并不代表一定拥有查询权限。DNS 服务可能根据来源网段、请求类型、域名区域或客户端身份决定是否回答。路由跟踪只能验证路径，不能证明查询一定被允许。
第五步：比较不同 DNS 服务器的行为，定位上游策略变化
当一台机器使用的 DNS 服务器与另一台机器不同时，最有价值的对比不是直接修改所有客户端，而是记录不同 DNS 服务器对同一域名的响应。
可以在不同主机上分别执行：
nslookup <目标域名>对比时至少记录：
- 实际使用的 DNS 服务器；
- 查询是否超时；
- 是否返回地址；
- 返回结果是否一致；
- 同一台 DNS 服务器对不同来源网络的表现是否一致。
如果本地网络、hosts、iptables 和路由都没有异常，而某台上游 DNS 服务器对目标域名统一返回失败，另一个 DNS 服务器却能正常返回，那么故障范围就已经从“客户端网络问题”缩小到“上游 DNS 服务或其策略”。
这次故障最终落在上游 DNS 服务器的策略变更上。策略变化可能表现为某些来源网络不再被允许递归查询，某个域名区域的访问范围发生调整，或者对特定查询返回结果进行了限制。由于输入侧的主机配置没有变化，客户端通常不会留下明显的配置错误，只会表现为解析超时、拒绝或返回异常结果。
这里的关键判断是：不能因为更换 DNS 服务器后问题暂时恢复，就把替换 DNS 当作完整修复。更换服务器可以验证方向，但还需要确认该服务器是否符合网络管理要求，是否能够稳定解析内部域名，以及是否会带来新的访问范围或安全问题。
跨系统故障中的对比方法
跨系统排查最容易出现“每台机器都按自己的习惯检查，最后无法比较”的情况。更可靠的做法是固定测试对象和记录方式。
先选定同一个目标域名，再在 Windows、Linux 和相关网络设备上分别记录解析服务器、解析结果、查询是否超时，以及路由跟踪的起止位置。对 Linux 主机，还要结合 tcpdump 观察实际请求；对启用了本机过滤的系统，则要检查对应的防火墙策略。
如果只有一台机器异常，优先怀疑 hosts、本机 DNS 配置、本机防火墙和本机路由。如果多个系统同时异常，但它们使用相同的上游 DNS，则应把重点移向 DNS 服务端策略或共享网络设备。如果不同系统使用不同 DNS，而只有使用某一台 DNS 的主机失败，那么 DNS 服务器差异比操作系统差异更值得优先验证。
这种对比能避免把问题归因于“Linux 和 Windows 的解析机制不同”。系统差异确实会影响配置位置和命令，但只要查询对象、上游服务器和网络路径能够对应起来，排查结论仍然可以相互验证。
一套可复用的排查顺序
遇到域名访问故障时，可以按下面的顺序执行：
- 用
nslookup确认是解析失败还是解析后连接失败； - 检查 hosts，排除本地静态映射和旧地址；
- 用
tcpdump确认 DNS 请求是否发出、发往哪里、是否收到响应； - 检查
iptables或对应系统的防火墙规则，确认请求和响应是否被过滤； - 用
traceroute检查到 DNS 服务器的网络路径； - 在不同系统或不同 DNS 服务器之间做对照；
- 当客户端配置和链路均正常时，再联系或核对上游 DNS 的访问策略。
顺序的重要性在于，每一步都应该缩小故障范围，而不是单纯增加操作数量。只有看到证据后才进入下一层：没有请求，就查本机或应用；有请求没响应，就查链路或服务端；有正常 DNS 响应但应用仍失败，就回到解析结果、路由和目标服务本身。
排查完成后，还应保留变更前后的查询结果、抓包现象、规则检查结果和路由路径。这样即使上游策略再次调整，也能快速判断是客户端配置回退、网络路径变化，还是 DNS 服务端行为发生了改变。
