DNS 能 ping 通 IP 却解析不了域名：一次线上排查的完整思路

问题现象

某台测试服务器突然无法访问任何外部 HTTPS 服务，浏览器报 DNS_PROBE_FINISHED_NO_INTERNET，curl 报 Could not resolve host。但 ping 223.5.5.5 完全正常，延迟 20ms 左右，丢包率为 0——网络本身是通的，问题只出在域名解析。

为什么 IP 通、域名不通

这说明数据链路（路由、网关、出口）没有问题，故障点在 DNS 这一层。常见成因有三类：

1. DNS 服务器不可达：配置的 nameserver UDP 53 端口被中间设备丢弃。很多机房会限制或干扰出站 53 端口，尤其是跨境或跨运营商链路。
2. systemd-resolved 缓存污染：上游返回过一次错误结果后被缓存，后续请求直接命中坏缓存。
3. 全局代理劫持了 DNS：客户端把域名交给代理侧解析，代理侧解析失败时本地看起来「全都解析不了」。

三步定位

第一步：分辨是 DNS 失败还是连接失败

ping 223.5.5.5          # 通 = 链路正常，问题在 DNS
nslookup example.com    # 报 no servers could be reached = DNS 层失败
getent hosts example.com

第二步：绕过 UDP 53 验证解析能力

如果 UDP 53 被限，用 DoH（HTTPS 承载的 DNS）验证同一个域名能否解析出来：

curl -s 'https://223.5.5.5/resolve?name=example.com&type=A'

能返回 JSON 就说明解析服务本身活着，只是本地到它的 UDP 53 被挡了。此时可以换 DNS 服务器，或直接为关键域名固定 hosts 解析。

第三步：排除代理干扰

关于代理还有一个容易踩的坑：环境变量里的 http_proxy 会让 curl 走代理，而代理可能反过来 reset 连接，看起来像目标站点挂了。验证时显式绕过代理：

curl -s --noproxy '*' -o /dev/null -w '%{http_code}' https://example.com

如果这样能通，就说明是代理在捣乱，而不是 DNS。

恢复顺序建议

• 先 resolvectl flush-caches 清缓存，再测一次——排除缓存污染。
• 仍不通就换 DNS 或写 hosts，保证业务先恢复。
• 最后再排查代理与防火墙策略，避免只修一个客户端（比如只给浏览器加 NO_PROXY，服务器上的脚本照样挂）。

小结

「能 ping 通 IP」只能证明链路可用，不能证明解析可用。遇到这类故障时，先用 ping 与 nslookup 把问题分层，再用 DoH 与 --noproxy 把 DNS 层和代理层分开验证，通常三步内就能定位到具体那一环。把结论写进运维手册，下次同类故障可以五分钟处理完。