Linux DNS解析不一致主因是多机制并存、配置优先级混乱及缓存干扰；需检查/etc/resolv.conf指向、systemd-resolved或NetworkManager实际配置、容器DNS设置，并区分host/dig/getent等命令解析路径差异。
Linux 系统中 DNS 解析结果不一致，通常不是 DNS 本身“出错”，而是多个解析机制并存、配置优先级混乱或缓存干扰导致的。核心问题在于：系统可能同时使用 /etc/resolv.conf、systemd-resolved、NetworkManager、dnsmasq、甚至容器或应用自定义的 DNS 设置，而不同工具查的是不同后端，返回自然可能不同。
检查当前实际生效的 DNS 配置源
别只看 /etc/resolv.conf——它可能是符号链接，内容未必真实生效：
- 运行
ls -l /etc/resolv.conf，常见指向/run/systemd/resolve/stub-resolv.conf（systemd-resolved）或/run/NetworkManager/resolv.conf - 查 systemd-resolved 状态：
systemctl is-active systemd-resolved，再用resolvectl status查当前上行 DNS 和启用的域 - 若用 NetworkManager：
nmcli dev show | grep DNS显示接口级 DNS；nmcli con show "连接名" | grep ipv4.dns查具体连接设置 - 容器内解析异常？检查是否覆盖了
--dns或继承了宿主机的/etc/resolv.conf，且未禁用 DNS 拦截（如 Docker 的--dns-opt=ndots:5影响搜索域行为）
验证解析路径差异：host vs. dig vs. 应用行为
不同命令走的解析栈不同，结果天然可能不一致：
-
host example.com和nslookup直接走 libc 的 resolver（受/etc/resolv.conf或 resolved stub 影响） -
dig example.com @8.8.8.8绕过本地 resolver，直连指定 DNS 服务器，用于排除本地配置干扰 -
getent hosts example.com走 NSS（Name Service Switch），会按/etc/nsswitch.conf中hosts:行顺序尝试 files、dns、mdns4 等，可能命中 /etc/hosts 或 mDNS - 浏览器或 curl 可能自带 DNS 缓存（尤其 Chromium 系）、启用 DoH（DNS over HTTPS），或受代理设置影响，和终端命令结果不一致属正常
排查缓存与搜索域干扰
看似“同一个域名”，因缓存或自动补全导致实际查询不同：
- systemd-resolved 默认启用缓存：
resolvectl statistics查缓存命中率；resolvectl flush-caches清除 - 检查
/etc/resolv.conf或 resolved 配置中的search域（如search local lan），执行ping foo实际可能查的是foo.local，而非foo - 用
dig +trace example.com看完整递归路径，确认是否在某一级被劫持、重定向或返回了不同 TTL 的旧记录 - 某些 ISP 或企业网络会在出口网关拦截 53 端口，强制转发到内部 DNS，导致公网解析结果与预期不符
统一解析行为的实用建议
避免多层抽象叠加，明确控制解析链路：
- 若不需要 systemd-resolved，可停用：
sudo systemctl disable --now systemd-resolved，再手动管理/etc/resolv.conf（确保不是 symlink） - NetworkManager 用户可在连接配置中设
ipv4.ignore-auto-dns=true，避免 DHCP 覆盖 DNS，并静态指定ipv4.dns="1.1.1.1,8.8.8.8" - 开发调试时，临时绕过所有本地配置：
DNS_SERVER=1.1.1.1 getent hosts example.com（部分环境支持）或直接用dig @1.1.1.1 example.com - 写脚本时避免依赖
ping或host判定域名可达性，改用dig +short example.com A | head -1获取明确的 A 记录，减少搜索域和别名干扰
