如何查看服务器走哪个dns

服务器走哪个DNS，最直接的办法是查看/etc/resolv.conf文件，但更严谨的判断需要结合dig命令和系统实际连接状态综合确认。

很多人在排查服务器域名解析慢、网站打不开时，第一反应就是“是不是DNS配置错了”，但很多时候，你看到的配置和系统实际使用的并不是同一个，这篇文章把常用的查看方法、底层原理和判断逻辑一次说清楚。

基础查看方法：三分钟定位DNS配置

用命令行工具查看是最快的方式,不同操作系统略有差异，但核心思路一致：先看配置文件，再看实际解析记录，最后确认生效状态。

Linux服务器走哪个DNS：优先检查resolv.conf

绝大多数Linux发行版,DNS客户端配置都写在/etc/resolv.conf里。

cat /etc/resolv.conf

输出结果通常是这样的：

nameserver 192.168.1.1
nameserver 223.5.5.5
search localdomain

• nameserver后面跟的IP就是当前系统配置的DNS服务器地址，从上到下，系统会优先向第一个发起查询请求。
• search是域名搜索后缀，内网环境常见，不影响“走哪个DNS”的判断。

需要注意,如果服务器使用了systemd-resolved服务（常见于Ubuntu 18.04+、CentOS 8+），/etc/resolv.conf里可能只有一个0.0.53这样的本地回环地址，这不是系统真正使用的DNS，而是systemd-resolved的本地缓存代理，想看到上游真实DNS，需要运行：

systemd-resolve --status

或在新版本系统（如Ubuntu 22.04+）上使用：

resolvectl status

这个命令会列出每个网卡（如eth0、ens33）实际生效的DNS服务器，如果这个命令也看不到明确地址，还可以检查/run/systemd/resolve/resolv.conf这个文件，里面通常保存了真正的上游DNS。

Windows服务器查看DNS配置

Windows Server系统通过PowerShell或命令行查看：

ipconfig /all

在输出中找到“DNS服务器”一行，能看到主备DNS地址，注意，这里查看的是静态配置或DHCP下发的地址，如果系统启用了“DNS客户端”服务缓存，实际查询链路可能经过本地缓存，但最终出口仍然是这里显示的地址。

进阶验证：确认服务器实际走哪个DNS解析域名

配置文件里的内容不一定代表真实查询路径,在某些云环境中，云平台会通过DHCP强制下发DNS，或者安全软件会劫持53端口流量，要多层验证。

用dig直接查询：锁定解析服务器

dig是排查DNS最得力的工具，想知道服务器对某个域名“实际走了哪个DNS”，可以指定服务器地址做对比测试。

先测试默认配置下的解析结果：

dig www.baidu.com

输出末尾的SERVER: 192.168.1.1#53(192.168.1.1)，就是系统实际使用的DNS服务器地址和端口，这一步看到的服务器IP才是真相。

如果这个SERVER显示为0.0.53#53，说明请求交给了本地systemd-resolved，接着用下面命令绕开本地缓存，直接请求公共DNS对比：

dig @223.5.5.5 www.baidu.com
dig @8.8.8.8 www.baidu.com

对比两次返回的解析结果和耗时,如果@223.5.5.5能正常返回IP，而系统默认配置解析失败，基本可以判断是原DNS服务器问题。

业内专家指出,超过七成的服务器DNS故障来自配置文件和实际生效服务不一致，手动指定公共DNS（如223.5.5.5、119.29.29.29）是最常用的隔离手段。

查看53端口连接记录：确认查询已发出

服务器发起DNS查询时,会与DNS服务器的53端口建立UDP或TCP连接，用ss命令可以看到实时连接状态：

ss -unp | grep :53

如果服务器刚执行过域名解析,这里能看到发往DNS服务器IP的UDP数据包，TCP连接同样可以观察：

ss -tnp | grep :53

这个方法的优势在于,它能发现那些即使修改了配置文件也依然生效的“隐藏DNS”，比如某些云服务器厂商的虚拟化平台会在宿主机层面劫持DNS请求，你看到配置文件是8.8.8.8，但53端口实际连接却是云厂商内网IP，这种情况在物理服务器托管和云服务器中都不少见。

判断服务器“该走哪个DNS”：环境决定选择

知道怎么查看之后,很多人会纠结“配置哪个DNS最好”，这没有统一答案，主要看使用场景。

新购服务器域名解析延迟高的排查思路

服务器访问外网域名慢,不要急着改DNS，先确认机房出口线路，再用ping或dig对比公共DNS和本地DNS的响应时间，比如服务器在华东地区，可以优先测试5.5.5（阿里DNS）和29.29.29（腾讯DNS）的时延，如果你的目标用户群也在华东，这两个DNS通常比8.8.8快，反之，如果服务器面向海外业务，走Google或Cloudflare的DNS（1.1.1）可能更合适。

内网域名解析走哪个DNS：区分内外网策略

企业服务器通常需要解析内部域名（如git.xxx.com），这类域名的解析只能靠内网DNS服务器完成，此时正确配置是：内网DNS服务器作为第一nameserver，公共DNS作为第二或第三nameserver。

nameserver 10.0.0.2
nameserver 223.5.5.5

这样,内网域名由内网DNS权威解答，外网域名在内网DNS无法解析时，可以由它在自己的上游配置中处理，或者系统自动切换到第二个公共DNS，不建议把公共DNS放在第一位，否则内网域名查询会因找不到记录而失败。

修改完成后用nscd或systemd-resolved刷新缓存

每次修改/etc/resolv.conf后，不需要重启网络服务就能生效（部分系统可能需要），但如果有DNS缓存，需要刷新一下：

systemctl restart systemd-resolved

或者清空nscd缓存：

systemctl restart nscd

不刷新缓存,你可能会看到“配置改了半天，解析结果还是老地址”的假象。

多网卡服务器的DNS优先级问题

服务器配置了多块网卡时,操作系统会根据路由表和网卡Metric值（跃点）决定优先走哪个网关，进而影响DNS选择，比如服务器有ens160和内网网卡ens192，ens160的网关是168.1.1，ens192的网关是0.0.1，系统默认路由优先级高的网卡会成为DNS查询的主要出口。

查看路由表确认：

ip route show

如果发现DNS查询走向不符合预期,可以通过调整网卡的metric值改变优先级，在/etc/sysconfig/network-scripts/ifcfg-ens160（CentOS）或/etc/netplan/01-netcfg.yaml（Ubuntu）中设置，修改后重启网络服务。

服务器走哪个DNS的常见误区与纠正

一个常见的误区是,直接修改/etc/resolv.conf就能永久生效，实际上在大部分云服务器和采用DHCP的网络环境中，只要网卡续租或服务重启，这个文件就可能被覆盖，永久修改需要改网卡配置文件里对应的DNS1=、DNS2=参数，或者在systemd-networkd中配置DNS=。

另一个误区是把8.8.8当作万能DNS，8.8.8.8在海外和部分国际BGP线路表现良好，但在国内服务器上经常被防火墙干扰，解析成功率不稳定，选择国内公共DNS还是国外DNS，取决于服务器的物理位置和目标访问群体。

实用答疑环节

查看服务器DNS配置的命令总记不住怎么办？

把cat /etc/resolv.conf和dig这两个命令记住就够了，前者看配置，后者看真实出口，如果服务器装的是Windows，就用ipconfig /all，这三个命令覆盖了90%的排查场景。

能不能在不重启服务的情况下测试新增的DNS是否可用？

可以,不修改/etc/resolv.conf，直接用dig @新DNS域名测试，不会影响当前系统配置，也不涉及重启，非常适合验证阶段。

为什么我改了/etc/resolv.conf还是显示旧DNS？

可能是systemd-resolved接管了DNS，运行systemd-resolve --status查看真实生效地址，如果显示的还是旧值，需要修改/etc/systemd/resolved.conf中的DNS=参数，然后重启systemd-resolved服务，另外确认是否有云平台的初始化脚本（如cloud-init）在开机时覆盖了配置文件。

判断服务器走哪个DNS,逻辑上就三步：看配置、查连接、做对比，配置文件告诉你“想用哪个”，ss命令告诉你“实际连了哪个”，dig对比测试告诉你“哪个能用、哪个快”，把这三步走完，任何隐藏的DNS问题都会现形。