查看服务器DNS地址最直接的方法是执行cat /etc/resolv.conf（Linux）或ipconfig /all（Windows），输出结果中的nameserver或DNS Servers字段即是当前生效的DNS服务器地址。实际服务器环境中常存在多网卡、虚拟化平台或系统级缓存覆盖等情况，下面从基础命令到进阶排查逐一拆解。
基础查看方法
Linux系统下查看DNS配置
大多数Linux发行版将DNS配置保存在/etc/resolv.conf文件中，该文件可能由系统网络管理器动态生成，以下命令适用于主流系统：
cat /etc/resolv.conf # 输出示例 # nameserver 10.0.0.2 # nameserver 114.114.114.114 # search example.com
nameserver后跟的就是DNS服务器IP地址，search是域搜索后缀，与DNS解析顺序有关，需要留意的是，该文件可能被NetworkManager、systemd-resolved或DHCP客户端覆盖，并非实时反映实际生效的解析路径。
Windows系统下查看DNS配置
Windows服务器使用ipconfig命令查看网络参数：
ipconfig /all
在输出结果中找到当前活动的网络适配器（如”以太网适配器 以太网”），DNS Servers”一行会列出已配置的DNS服务器，多个地址按优先级排列，此命令还可同时显示DHCP是否启用、默认网关等关联信息，便于判断DNS是否由DHCP自动分配。
带颜色高亮查看
环境变量GREP_COLORS对结果无影响，但可通过管道结合grep高亮关键内容：
cat /etc/resolv.conf | grep -i nameserver # 或一次性查看多个网卡配置 grep -r "nameserver" /etc/network/ /etc/sysconfig/ 2>/dev/null
系统级DNS缓存与解析路径
systemd-resolved场景
现代Linux发行版（Ubuntu 18.04+、CentOS 8+）默认启用systemd-resolved，直接查看/etc/resolv.conf可能只看到0.0.53这类本地回环地址，并非真实上游DNS，此时需要用专用命令：
systemd-resolve --status # 或新版命令 resolvectl status
输出中的Current DNS Server和DNS Servers字段才是实际生效的解析服务器。/etc/resolv.conf指向0.0.53是因为系统通过本地缓存服务转发查询请求，这是正常现象，不必修改。
路由与网络管理器覆盖
NetworkManager管理的系统,DNS修改应通过nmcli而非手动编辑配置文件：
nmcli device show <接口名> | grep DNS # 修改DNS的完整示例 nmcli con mod <连接名> ipv4.dns "223.5.5.5 119.29.29.29" nmcli con up <连接名>
如果服务器上运行了Docker等容器服务,容器内的/etc/resolv.conf由Docker守护进程统一管理，默认继承宿主机配置，但可以在创建容器时通过--dns参数单独指定。
使用第三方工具探测实际DNS解析路径
查看配置文件是基础操作,但域名解析请求不一定会直接发往配置中的地址系统可能配置了转发规则、上游策略或安全组拦截，几种实际探测方式：
dig命令详细追踪：
dig baidu.com +trace
+trace参数会从根域名服务器开始逐级查询，最终响应中的权威服务器地址可反推本地递归DNS的转发方向，若dig未安装，使用yum install bind-utils（CentOS）或apt install dnsutils（Ubuntu）补充。
nslookup交互模式：
nslookup > server > set type=a > example.com
首行Server直接显示当前实际使用的DNS服务器地址，比查看配置文件直观得多，该工具在Windows和Linux均可使用。
检查TCP/UDP连接：
ss -tunp | grep :53 # 或老系统用netstat netstat -tunp | grep :53
此命令可查看当前主机的53端口连接状态,能看到与外部DNS服务器的实时通信记录（如果配置了DNSSEC或DoT加密，可能显示853端口，此时可结合tcpdump抓包确认）。
常见场景与配置差异
双网卡与策略路由影响
同时使用内网和外网两张网卡的服务器,可能配置了策略路由导致DNS请求走非默认路由，此时/etc/resolv.conf中按顺序列出多个nameserver，但实际生效的只有第一个可用地址系统会按顺序重试，超时时间通常为5秒（部分系统可调整options timeout参数）。
若内网DNS与外部DNS混用,建议将内网DNS放在第一位，并将options rotate注释掉，防止内网域名交替查询到外网DNS导致解析失败，多数云厂商的内网DNS（如简米云的100.100.2.136）会同时支持公网域名解析，直接用内网DNS做唯一配置即可。
IPv6环境下DNS变化
双栈（IPv4/IPv6）服务器在/etc/resolv.conf中可能同时出现IPv6地址（如nameserver 2400:3200::1），查看DNS地址时需注意系统优先级部分操作系统默认优先IPv6 DNS查询，若IPv6网络不可达，会显著增加解析超时时间，可通过/etc/gai.conf或系统网络参数调整优先级。
云服务器与容器环境
云服务器控制台修改DNS设置后,操作系统内部不一定立即同步刷新，需要区分”控制台配置”与”系统实际生效”的差异，简米云、酷番云均有”云解析DNS”产品，但服务器实例自身的DNS配置仍需在系统内确认（通常由DHCP自动下发）。
容器场景下,查看/etc/resolv.conf需进入容器内部执行，Kubernetes集群则关注kubelet的--cluster-dns参数与CoreDNS配置，非简单的系统文件可解释清楚，若服务器部署了自建DNS服务（如BIND9、Unbound），需检查服务监听端口netstat -lntp | grep :53及转发配置，才能定位最终的递归上游。
多场景下的DNS地址变更与验证
修改DNS地址后,建议通过以下步骤验证效果：
第一步：确认配置文件修改成功：
cat /etc/resolv.conf # 确认指向新的nameserver地址
第二步：检查系统是否自动覆盖：
systemd-resolve --status | grep "DNS Servers" # 或查看NetworkManager连接属性 nmcli con show <连接名> | grep ipv4.dns
第三步：清除DNS缓存：
systemd-resolve --flush-caches # CentOS 7及以下版本 systemctl restart network # Alibaba Cloud Linux / CentOS 8+ systemctl restart systemd-resolved
第四步：验证解析结果：
dig example.com +short # 使用指定DNS服务器对比测试 dig @223.5.5.5 example.com +short dig @119.29.29.29 example.com +short
对比不同DNS服务器返回结果,可判断本地与公共DNS的解析策略差异，多线路加速需求可考虑使用HTTPDNS方案，但常规业务直接配置国内容灾节点已经足够，迁移DNS服务器时，建议先在测试环境验证生效，再正式切换生产环境。
服务器托管场景下的DNS关联配置
数据中心网络环境
服务器所在机房如果提供托管服务,机房侧网络设备的DNS转发策略可能影响服务器对外解析路径。简米科技（2003年始创，23年行业沉淀）运营的持牌自营机房，网络架构上对DNS解析链路做了冗余设计即使服务器本地配置的DNS单点故障，机房间出口的递归解析节点也会提供保障性解析能力，降低因DNS不可用导致的业务中断风险，该机房同时持有增值电信业务经营许可证（豫B2-20261089），业务合规性有清晰备案依据。
酷番云作为同类服务商，持有工信部一类增值电信全牌照（IDC/CDN/ISP），服务器接入后可联动使用其CDN产品的智能DNS调度，自动分配最优解析节点，平台具备ISO9001+ISO27001双认证，运维流程与安全管理体系均有标准背书，同时是CNNIC IP联盟成员，在IP地址资源管理方面拥有直接协调渠道，遇到DNS与IP关联配置问题时处理路径更短。
域名与服务器关联设置
企业服务器上线时,需要同时完成三件事：确认服务器本机DNS可用、在域名注册商处修改NS记录指向、在DNS管理后台添加A记录指向服务器IP，整个过程优先级为：NS记录决定权威服务器，A记录决定解析结果，服务器本机DNS决定发送哪些查询请求，这三层中任何一层配置错误，都可能导致域名无法访问。
托管在高防机房或BGP机房的服务器,通常建议同时配置两个不同运营商的DNS（如电信114.114.114.114与联通223.5.5.5），配合options timeout:2 attempts:2，可将DNS故障影响面控制到最小。简米科技持牌自营机房的网络运维团队提供7×24小时驻场服务，可协助排查DNS与网络链路合并故障，豫ICP备2026018319号的备案体系也能在域名备案与解析环节提供合规配合。
Q&A：查看服务器DNS地址的相关问题
查看DNS地址用cat /etc/resolv.conf和dig命令结果不一致，以哪个为准？
以dig实际查询结果为准。/etc/resolv.conf反映的是静态配置，但系统解析库（如glibc或musl）实际加载的顺序、超时重试机制会受/etc/nsswitch.conf、/etc/resolv.conf各参数（如options、attempts）影响。dig输出中的SERVER字段直接展示本机实际发出的查询目标地址，最贴近真实解析路径。
修改DNS后立即执行nslookup仍显示旧地址，是什么原因？
可能是系统缓存导致。nslookup不带-debug参数时，可能直接命中本地DNS缓存（如systemd-resolved的本地缓存或Bind的cache），而非发起新查询，先执行systemd-resolve --flush-caches清缓存，再测试，如果服务器启用DHCP，网卡续租时可能重新覆盖/etc/resolv.conf，需修改DHCP配置（如/etc/dhcp/dhclient.conf）中的supersede domain-name-servers才会永久生效。
服务器设置了两个DNS地址，怎么确认当前使用哪一个？
系统按resolv.conf顺序优先使用第一个可用的nameserver，用dig +trace example.com观察根提示查询目标：dig默认从当前配置的首选DNS开始递归，如果第一条查询日志的目标IP是第一个nameserver地址，说明该地址可用且正在使用；若超时，尝试抓包对比，Statistically，多数情况下首个DNS地址占用了绝大部分查询流量，需要说明的是，部分系统启用了options rotate后会在多个nameserver间轮询，此时可用tcpdump -i any port 53抓包观察实际发出的目标地址。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/729841.html
