直接查看 /etc/resolv.conf 最快但不可靠，因其常为指向 systemd-resolved 或 networkmanager 的软链；真实 dns 需用 resolvectl status 查看，或用 nslookup/dig 验证实际解析服务器。
直接看 /etc/resolv.conf 是最快方式，但得知道它可能不真实
大多数时候，cat /etc/resolv.conf 显示的就是当前生效的 DNS 服务器，比如：
nameserver 114.114.114.114<br>nameserver 8.8.8.8
但现代 Linux（如 Ubuntu 22.04+、CentOS 8+、Fedora）中，这个文件常是符号链接，指向 /run/systemd/resolve/stub-resolv.conf 或 /var/run/NetworkManager/resolv.conf，内容由 systemd-resolved 或 NetworkManager 动态生成——你手动改了，下次 DHCP 更新或服务重启就丢。
- 先用
ls -l /etc/resolv.conf看是不是软链；如果是，顺着链去看真实来源 - 若看到
nameserver 127.0.0.53，说明系统正走systemd-resolved的 stub 模式，真实上游 DNS 要查resolvectl status - 若看到
nameserver 127.0.0.1，可能是本地运行了dnsmasq或unbound，得进一步查其配置
用 resolvectl 查 systemd-resolved 管理的真实 DNS
如果你的系统启用了 systemd-resolved（默认在多数新发行版中启用），/etc/resolv.conf 只是代理入口，真正配置藏在 resolvectl 里。
-
resolvectl status显示所有接口的 DNS 设置，重点看 “DNS Servers” 下的 IP，尤其是标记为 “active” 的那行 -
resolvectl dns eth0查指定网卡（如eth0）当前使用的 DNS -
resolvectl query example.com不仅解析域名，还明确告诉你“Using DNS server X.X.X.X for interface eth0”
注意：resolvectl 在旧系统（如 CentOS 7）里没有，那是 systemd 239+ 才引入的命令。
nslookup 和 dig 看的是“实际发往哪台服务器”，不是“配置写了啥”
这两个命令不读配置文件，而是直接发起 DNS 查询请求，返回头里带的 SERVER 字段，才是你此刻真正对话的 DNS 服务器——这对排障特别关键。
-
nslookup google.com输出第一行 “Server: X.X.X.X” 就是真实解析服务器，哪怕/etc/resolv.conf里写的是 127.0.0.53，这里也可能显示 114.114.114.114（因为 resolved 转发过去了） -
dig +short google.com快速获取结果；dig google.com | grep "SERVER:"提取真实服务器地址 - 如果
nslookup报 “connection timed out”，说明你配的 DNS 根本没响应，或者被防火墙拦了——比看配置文件更早暴露问题
别只改 /etc/resolv.conf，持久化配置要看网络管理方式
临时改 /etc/resolv.conf 很快，但机器一重启或网络重连就失效。真要改，得按系统实际用的网络管理器来：
- 用
NetworkManager（桌面环境、Ubuntu Server 默认）：改连接配置，比如nmcli connection modify "System eth0" ipv4.dns "114.114.114.114 8.8.8.8"，再nmcli connection reload && nmcli connection up "System eth0" - 用
systemd-networkd（某些云镜像、CoreOS）：在/etc/systemd/network/*.network文件里加[Network]段，写DNS=114.114.114.114 - 纯静态网络（无 NM / networkd）：确保
/etc/resolv.conf不是软链，且chattr +i /etc/resolv.conf锁住（慎用，可能影响 DHCP）
最易被忽略的一点：DNS 解析顺序是 /etc/hosts → 本地 resolver（如 resolved）→ 上游 DNS。即使你配对了 DNS，/etc/hosts 里有对应条目，照样不会走网络查询。
