先看 /etc/resolv.conf 是否为真实文件：现代 Linux 中它通常是软链接，指向 /run/systemd/resolve/stub-resolv.conf（由 systemd-resolved 管理）或 /run/NetworkManager/resolv.conf（由 NetworkManager 管理），直接 cat 易获假配置；应优先用 ls -l /etc/resolv.conf 判断归属，再通过 resolvectl status 或 nmcli dev show 查真实生效的 DNS。
先看 /etc/resolv.conf 是不是“真文件”
直接 cat /etc/resolv.conf 很可能看到的是假配置。现代 Linux（Ubuntu 20.04+、RHEL 8+/CentOS 8+、Fedora 33+）普遍用 systemd-resolved 或 NetworkManager 动态管理 DNS，/etc/resolv.conf 常是软链接：
- 运行
ls -l /etc/resolv.conf，如果输出含->，说明它指向别处 - 若指向
/run/systemd/resolve/stub-resolv.conf：真实 DNS 由systemd-resolved控制 - 若指向
/run/NetworkManager/resolv.conf：DNS 来自NetworkManager - 若报错
No such file or directory：可能systemd-resolved没启用，或服务异常
用 resolvectl status 查 systemd-resolved 管理的 DNS
这是当前 systemd 生态下最可靠的手段，能同时看到全局和接口级 DNS 配置：
- 执行
resolvectl status，重点看Global下的DNS Servers:—— 这是系统默认用的上游 DNS - 再找具体网卡（如
ens33）下的DNS Servers:—— 表示该接口实际通告的 DNS - 注意
Current Scopes:是否包含dns，不 active 就没生效 -
resolvectl在 CentOS 7 等老系统中不可用，因为systemd-resolved当时尚未成为标配
用 nmcli dev show 查 NetworkManager 管理的 DNS
桌面环境或启用了 NetworkManager 的服务器上，DNS 通常由它统一控制：
- 运行
nmcli dev show，搜索DNS字段，会列出当前生效的 DNS 地址 - 也可指定接口查：
nmcli dev show ens33 | grep DNS - 如果
/etc/resolv.conf开头有# Generated by NetworkManager，就确认是它在管 - 注意：
nmcli dev show显示的是当前连接的 DNS，但若 DHCP 自动下发了 DNS，而你又没禁用自动覆盖（ipv4.ignore-auto-dns yes），手动设的 DNS 可能被悄悄替换
用 dig 或 nslookup 验证真实解析路径
这两个命令不读系统配置，而是直接发查询，能交叉验证实际走的是哪个 DNS：
-
dig google.com +short后看输出里SERVER:行，例如;; SERVER: 192.168.1.1#53(192.168.1.1)—— 这才是此刻真正干活的 DNS -
nslookup google.com输出第一行的Server:字段也同理 - 注意：
nslookup默认直连/etc/resolv.conf第一个nameserver；dig默认走系统 resolver（即 glibc 路径），行为更贴近 curl/wget - 如果
nslookup成功但curl google.com失败，大概率是 glibc 解析路径（比如systemd-resolvedstub）和你预期不一致
最易被忽略的点是：哪怕你改了 /etc/resolv.conf，只要底层服务（systemd-resolved 或 NetworkManager）还在运行，它就会定时覆盖这个文件。查配置必须先定位管理方，再用对应工具查，而不是只信文件内容。
