真实生效的DNS需综合判断：先用ls -l /etc/resolv.conf确认是否为软链接，再根据指向分别执行resolvectl status或nmcli dev show；最后用dig google.com查看SERVER行交叉验证。
/etc/resolv.conf 文件不一定反映真实生效的 DNS 服务器，尤其在使用 systemd-resolved 或 NetworkManager 的现代发行版中。直接读它可能看到的是过时、被覆盖或仅作备份的配置。
看 /etc/resolv.conf 前先确认它是不是“真文件”
很多系统（如 Ubuntu 20.04+、CentOS 8+/RHEL 8+）把 /etc/resolv.conf 设为指向 /run/systemd/resolve/stub-resolv.conf 或 /run/NetworkManager/resolv.conf 的软链接：
ls -l /etc/resolv.conf
如果输出里带 ->，说明它是符号链接 —— 此时 cat 它看到的只是 stub 或 NM 的中间层配置，不是最终解析用的上游 DNS。
- 若指向
/run/systemd/resolve/stub-resolv.conf：实际 DNS 由systemd-resolved管理，需用resolvectl status - 若指向
/run/NetworkManager/resolv.conf：DNS 来自 NetworkManager，应查nmcli dev show - 若显示 “No such file or directory”：说明
systemd-resolved可能没启用，或服务异常
用 resolvectl status 查 systemd-resolved 真实配置
这是当前 systemd 生态下最权威的方式，能同时看到全局 DNS、接口级 DNS 和当前活动的解析器：
resolvectl status
重点关注以下几块：
-
Global 下的
DNS Servers:—— 全局默认 DNS（如1.1.1.1） - 某个接口（如
ens33）下的LLMNR setting:和DNS Servers:—— 该网卡实际通告的 DNS -
Current Scopes: 显示当前哪些 scope（如
dns）是 active 的
注意：resolvectl 在较老系统（如 CentOS 7）中不可用，那是 systemd-resolved 尚未成为标配。
用 nmcli dev show 查 NetworkManager 管理的 DNS
桌面环境或启用了 NetworkManager 的服务器上，DNS 往往由它统一控制，/etc/resolv.conf 只是它的输出副本：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
nmcli dev show | grep DNS
或者指定接口更清晰：
nmcli dev show ens33 | grep IP4.DNS
输出类似：
IP4.DNS[1]: 192.168.1.1<br>IP4.DNS[2]: 8.8.8.8
- 这些地址才是 NetworkManager 实际下发给
systemd-resolved或直接写入/etc/resolv.conf的源头 - 如果
nmcli报错 “Not running”，说明 NetworkManager 服务没启动，此时应转向resolvectl或cat /etc/resolv.conf - 修改 DNS 应优先用
nmcli connection modify xxx ipv4.dns "1.1.1.1 8.8.8.8"，而非直接改文件
用 dig +short 或 nslookup 验证实际解析路径
命令行工具不依赖配置文件，而是走系统 libc 的 resolver 逻辑，结果最贴近真实行为：
dig google.com +short
再看响应头里的 SERVER 行：
dig google.com | grep "SERVER:"
输出类似：
;; SERVER: 127.0.0.53#53(127.0.0.53)
- 如果 SERVER 是
127.0.0.53：说明本地有systemd-resolvedstub listener，真实上游得查resolvectl status - 如果 SERVER 是
192.168.1.1这类内网地址：说明绕过了本地 stub，直连上游 DNS -
nslookup google.com效果类似，但输出格式稍乱；nslookup需要dnsutils（Debian/Ubuntu）或bind-utils（RHEL/CentOS）包支持
/etc/resolv.conf 就万事大吉，却忽略了 systemd-resolved 的接管、NetworkManager 的覆盖，或者 libc resolver 对 127.0.0.53 的透明转发。验证时务必结合 resolvectl status 和 dig 的 SERVER 输出交叉比对。 
