应先运行 ls -l /etc/resolv.conf 判断是否为软链接，若指向 /run/systemd/resolve/stub-resolv.conf 则由 systemd-resolved 管理，若指向 /run/networkmanager/resolv.conf 则由 networkmanager 管理，再分别用 resolvectl status 或 nmcli dev show | grep ip4.dns 查真实 dns 配置源。
直接看 /etc/resolv.conf 容易误判，因为现代 Linux 发行版（如 Ubuntu 22.04+、RHEL 8+/9、Fedora 35+）大多不直接使用该文件作为真实配置源，而是由 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或nmcli dev show
查 systemd-resolved 管理的真实 DNS
适用于桌面环境、云服务器、或明确启用了 systemd-resolved 的系统（默认在多数新发行版中启用）：
resolvectl status
重点关注以下字段：
-
Global DNS Servers：全局默认上游 DNS（如
1.1.1.1、8.8.8.8） - Link section（如 ens33）下的 DNS Servers：该网卡单独配置的 DNS（优先级高于 Global）
-
Current Scopes 中是否包含
dns且为active
注意：systemd-resolve --status 是旧命令别名，已弃用；请统一用 resolvectl status。
查 NetworkManager 管理的 DNS 源头
适用于 GNOME/KDE 桌面、笔记本、或手动启用了 NetworkManager 的服务器：
nmcli dev show | grep IP4.DNS
或指定接口更清晰：
nmcli dev show eth0 | grep IP4.DNS
输出示例：
IP4.DNS[1]: 192.168.1.1<br>IP4.DNS[2]: 8.8.8.8
这些地址才是 NetworkManager 从连接配置（如 nmcli connection modify "Wired connection 1" ipv4.dns）读取并下发给解析器的原始 DNS 来源。
交叉验证：用 dig 看实际查询走的服务器
无论后端是 systemd-resolved 还是 NetworkManager，最终解析请求都会落到某个 DNS 地址上。执行：
dig google.com +short
再看完整响应中的 SERVER 行：
dig google.com | grep "SERVER:"
输出类似：
;; SERVER: 127.0.0.53#53(127.0.0.53)
这说明当前走的是本地 stub resolver（即 systemd-resolved 的监听地址），此时必须配合 resolvectl status 查它背后真正的上游 DNS；如果显示的是 192.168.1.1 或 8.8.8.8，则说明未经过 stub，DNS 直连上游 —— 多见于 NetworkManager 关闭了 systemd-resolved 或配置为 direct 模式。
