DNS解析原理、配置与排障实战：从缓存到公共DNS的完整指南-代码聚汇网

DNS解析原理、配置与排障实战：从缓存到公共DNS的完整指南

王杰岸·2026-09-06·阅读 21 GEO检测（免费）

DNS域名解析DNS缓存

|难度：普通|阅读约 39 分钟

不知道你有没有遇到过这种怪现象：电脑连着WiFi，微信消息刷得飞起，但浏览器就是打不开网页，提示“找不到服务器IP地址”；或者手机明明显示已连接网络，抖音刷不动，支付宝转账一直在转圈。这种时候，十有八九又是DNS在捣乱。我做了这么多年运维，几乎每个月都能接到几起类似的报障，问题本身并不复杂，难的是很多人对DNS的理解停留在“它就是用来上网的”这个层面，一旦出了故障，完全不知道从哪里下手。

这篇文章我想把DNS这件事讲透，不整虚的。从解析原理、DNS选型、跨平台配置，到实际排障、企业级自建DNS，把我在一线积累的经验和踩过的坑一次说清楚。不管你是普通用户、刚入行的网管，还是负责企业IT的运维，应该都能从中找到可以直接照着操作的内容。

1. 先弄明白DNS解析到底干了什么——从浏览器输入到IP返回的完整链路

1.1 DNS不是“一个服务器”，而是一整套分级查询体系

很多人把DNS理解成“一个电话簿”，这方向没错，但真实情况远比一本电话簿复杂。全球的DNS是一个分级、分布式的查询体系，不是靠一两台超级服务器扛着。它大致分为三层：

根服务器：全球只有13个逻辑根（实际背后有大量镜像节点），它们不存具体域名，只负责告诉你去哪里找顶级域服务器。
顶级域服务器：负责管理后缀，比如.com、.cn、.org各自有一批服务器，它们知道“某个域名归哪个权威服务器管”。
权威服务器：每个域名所有者（比如example.com的运营者）会在NS记录里指定自己的权威DNS服务器，这里面存着真正的A记录、AAAA记录、CNAME等。

当你在浏览器输入www.example.com时，完整的查找链路是这样的：浏览器先查自己的DNS缓存，没找到再去查操作系统里的hosts文件和系统DNS缓存，还是没有，才会把请求交给网络配置里设置的“本地DNS服务器”。这台DNS服务器帮你跑腿，一步步去问根服务器、顶级域服务器，最后从example.com的权威服务器拿到IP，再原路返回给浏览器。

你可以把整个体系想象成一个“快递中转网络”：信息不是一次性直达的，而是每一层告诉你下一站该找谁，直到最终拿到真实地址。理解这一点，后面很多配置和排障的难题就都顺了。

1.2 递归查询与迭代查询：到底谁在替我们跑腿

这里有两个词特别容易混淆：递归查询和迭代查询。

简单说，递归查询是“客户端只管提问，等待最终答案”。你的电脑向本地DNS服务器发请求时，就是递归查询——你只要答案，不用管过程。

迭代查询则是DNS服务器之间的“接力式问答”。你的本地DNS服务器（也就是递归解析器）收到你的请求后，先问根服务器：“.com归谁管？”根服务器回答：“去问a.gtld-servers.net。”它再去问这个顶级域服务器：“example.com的权威DNS是哪台？”顶级域服务器回答：“去问ns1.example.com。”最后它找到权威服务器，拿到真正的IP，再返回给你。

用大白话说，递归是“我只管下单，快递会送到我家”，迭代是“快递到一个中转站，下一个地址是哪里，问了才知道”。整个过程中，用户感知不到中间这些步骤，但每一跳都直接影响解析速度和成功率。

我在排查问题时，经常用dig +trace来观察这些中间过程，如果哪一跳超时或返回异常，就能快速定位是根服务器、顶级域还是权威解析出了问题。这个工具下文会细讲。

1.3 缓存与TTL：为什么改了DNS有时候“不生效”

DNS解析结果是有生命周期的，这在技术术语里叫TTL（Time To Live，生存时间）。每条DNS记录都会带一个TTL值，比如300秒，意思是“这条结果可以被缓存300秒”。

缓存是DNS高效运行的核心机制，但也带来一个经典问题：你改了域名解析记录，或者换了本地DNS服务器，却感觉“没生效”。原因通常有三个：

浏览器层缓存没清：Chrome等浏览器会缓存DNS结果，需要重启浏览器或到chrome://net-internals/#dns里手动清空。
系统层缓存没清：Windows的DNS Client服务会缓存解析结果，需要执行ipconfig /flushdns。
上级DNS服务器缓存没到期：就算你本机清了，你用的本地DNS服务器可能还在缓存旧结果，只能等TTL过期。

我在很多次改域名记录后都被“怎么还没生效”坑过，后来养成习惯：改记录之前，先看原TTL，如果太长，提前把它调低（比如300秒），等正式切换生效后再把TTL调回去。这是运维里非常实用的小技巧。

另外补充一点：现在很多网络工具新版本里，会把独立的DNS缓存参数标记为不推荐使用（deprecated），比如sing-box 1.14.0就把independent_cache这类选项标记为弃用。这个趋势的本质是：客户端层面的独立DNS缓存越来越没有意义，交给系统和递归解析器统一管理反而更高效、更不容易出幺蛾子。对普通用户来说，不用纠结这类参数，跟着系统方案走就对了。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 该用谁的DNS？运营商、大厂公共DNS与8.8.8.8的实测对比

2.1 三类DNS的真实差异与选型逻辑

经常有人问我：“DNS到底用本地运营商的还是大厂的？”这个问题没有标准答案，取决于你在乎什么。我先给一张对比表，再逐条解释。

DNS类型	延迟	CDN调度精准度	隐私/劫持风险	稳定性	代表性地址
运营商默认DNS	最低（就近）	最准（出口IP识别）	可能有解析劫持、广告注入	跟随宽带线路，一般稳定	各省市不同
阿里公共DNS	较低	较准	低，支持DoH/DoT	高	223.5.5.5、2400:3200::1
腾讯公共DNS	较低	较准	低，支持DoH/DoT	高	119.29.29.29
114 DNS	较低	一般	中	高	114.114.114.114
Google 8.8.8.8	高（跨境）	差（国内网站）	传输加密但日志策略争议	高	8.8.8.8、2001:4860:4860::8888

先说运营商默认DNS。它的最大优势是离你近、延迟低，而且运营商基于自己的IP地址库做CDN调度，能把你导向最近的节点。比如电信用户访问视频网站，用电信DNS往往能拿到本地缓存节点的IP，速度极快。缺点是一些地区存在“解析劫持”——你访问一个不存在的域名，它不报错，而是返回一个广告页面，这种体验很糟。

大厂公共DNS是“防劫持”的典型选择。阿里和腾讯都建立了自己的调度系统，虽然不如运营商对本地网络那么“门儿清”，但大厂在全国有大量节点和专线互联，解析速度和调度精度都相当不错。更重要的是，它们支持DNS over HTTPS（DoH），从根本上防止了中间人篡改解析结果。

2.2 8.8.8.8在国内到底能不能用

“DNS改成8.8.8.8有危险吗”这个问题也经常出现在搜索框里。先说结论：不危险，但也不一定更快，很多时候反而更慢。

8.8.8.8是Google的公共DNS，全球知名。但它在国内使用时有三道坎：

第一，物理距离远。数据包要跨海跑到境外服务器再回来，延迟天然比国内DNS高出几十毫秒。几十毫秒对网页浏览来说体感不明显，但对游戏、量化交易这类低延迟场景就很有影响了。

第二，CDN调度失准。很多网站会基于DNS请求来源的IP地址判断用户地理位置，然后把用户引导到最近的CDN节点。你用8.8.8.8解析时，DNS出口在境外，很多国内网站的CDN会误判你的位置，把你调度到海外或边缘节点，结果是“解析通了，但网页加载更慢了”。

第三，解析结果可能被干扰。由于跨境链路的复杂性，8.8.8.8的解析请求偶尔会碰到超时、丢包，表现为“网页打不开，但重启网络后又好了”。

那它是不是一无是处？也不是。当你怀疑运营商DNS有劫持、或者某些域名在运营商DNS下解析结果异常时，临时换8.8.8.8做对照测试非常有效。我的建议是：日常主力用223.5.5.5或119.29.29.29，8.8.8.8只作为备选DNS，或者只在排查问题的时候用。

2.3 按场景给出的DNS配置清单

根据不同使用场景，我整理的选型建议如下：

家庭普通用户（看视频、刷网页、网购）：直接用运营商默认DNS，或者手动改成223.5.5.5主、119.29.29.29备。
游戏玩家：运营商DNS为主，因为延迟最低；不建议用跨境DNS，调度不准会导致游戏路由变差。
开发者/需要稳定海外访问的人群：主DNS用223.5.5.5，备用8.8.8.8。如果设备支持DoH，可以配置DoH，加密防污染。
企业环境：自建DNS解析内部域名，上游转发到公共DNS；有条件就上DoH转发。

关于DoH，简单提一下。DNS over HTTPS就是把原本明文的DNS查询封装进HTTPS请求，走443端口，中间人看不到也改不了。Windows 11、安卓、iOS都原生支持DoH配置，大家可以试试，效果比单纯改DNS地址更明显，尤其是在公共WiFi环境下。

3. 跨平台DNS配置实操：Windows、Linux、麒麟系统的正确改法

3.1 Windows客户端：网卡设置和命令行两条路

Windows改DNS是最常见的操作，图形界面路径是：设置 → 网络和Internet → 高级网络设置 → 更多网络适配器选项 → 右键以太网/WLAN → 属性 → 双击“Internet协议版本4 (TCP/IPv4)” → 选择“使用下面的DNS服务器地址” → 填入主备DNS → 确定。

但如果你是运维，肯定更常用命令行批量操作。以管理员身份打开CMD或PowerShell：

bash复制# 查看当前所有网卡的IP和DNS配置
ipconfig /all

# 设置主DNS（把“以太网”换成你的网卡名）
netsh interface ip set dns name="以太网" static 223.5.5.5

# 添加备用DNS
netsh interface ip add dns name="以太网" 223.6.6.6 index=2

# 恢复自动获取DNS（DHCP下发）
netsh interface ip set dns name="以太网" dhcp

# 刷新DNS缓存
ipconfig /flushdns

# 查看当前DNS缓存内容
ipconfig /displaydns

新版PowerShell里还可以用更语义化的命令：

powershell复制Set-DnsClientServerAddress -InterfaceAlias "以太网" -ServerAddresses ("223.5.5.5","223.6.6.6")

这里有个经验之谈：在办公环境里，DNS经常是内网域控或内网解析器，乱改DNS会导致无法访问内网资源、加域失败。所以改之前，务必先执行ipconfig /all，把你原来的DNS和网关记下来，出了问题可以秒还原。

3.2 Linux下的“改了没生效”：NetworkManager与systemd-resolved的坑

Linux改DNS是重灾区，几乎每个新手都栽过这个跟头。现象很典型：手动改了/etc/resolv.conf，当时生效了，一重启网络或者重启机器，配置就还原了。网上搜出来的答案都很零散，我在这里一次性说清楚。

先看一个命令：

bash复制ls -l /etc/resolv.conf

如果输出显示它是一个软链接，那恭喜你，问题根源找到了。现在主流Linux发行版的/etc/resolv.conf往往不是普通文件，而是指向systemd-resolved或NetworkManager生成的动态文件。你直接编辑它，系统一刷新就会被覆盖。这个坑在Ubuntu 18.04+、RHEL/CentOS 8+、openEuler等系统上都很常见。

正确的改法要分三种情况：

情况一：使用NetworkManager管理网络（桌面版、麒麟桌面、RHEL/CentOS默认）

bash复制# 查看连接名称
nmcli con show

# 设置DNS并忽略DHCP自动下发的DNS
nmcli con mod "Wired connection 1" ipv4.dns "223.5.5.5 223.6.6.6" ipv4.ignore-auto-dns yes

# 重启连接使配置生效
nmcli con up "Wired connection 1"

情况二：使用systemd-resolved（Ubuntu Desktop等）

bash复制# 临时设置网卡DNS（重启失效）
sudo resolvectl dns eth0 223.5.5.5

# 永久设置：编辑 /etc/systemd/resolved.conf
sudo vi /etc/systemd/resolved.conf

在resolved.conf的[Resolve]段下添加：

ini复制[Resolve]
DNS=223.5.5.5 223.6.6.6
FallbackDNS=119.29.29.29

然后重启服务：

bash复制sudo systemctl restart systemd-resolved

情况三：纯静态配置场景（服务器无桌面、无NetworkManager）

看发行版而定。Debian/Ubuntu新版用netplan：

bash复制# 编辑 /etc/netplan/00-installer-config.yaml
network:
  version: 2
  ethernets:
    eth0:
      nameservers:
        addresses: [223.5.5.5, 223.6.6.6]

RHEL/CentOS/欧拉传统方式：

bash复制# 编辑 /etc/sysconfig/network-scripts/ifcfg-eth0
DNS1=223.5.5.5
DNS2=223.6.6.6

# 重启网络
nmcli con reload && systemctl restart network

欧拉（openEuler）这个系统，我特意多说一句。它整体延续了RHEL的体系，默认NetworkManager接管网络配置，很多网上教程让直接改/etc/resolv.conf，在欧拉上大概率会被还原。所以用nmcli命令才是正解。

改完之后，验证一下：

bash复制cat /etc/resolv.conf
nslookup www.baidu.com

如果解析成功，说明配置生效；如果还是旧的DNS，再检查一下是不是忽略了某个NetworkManager连接配置文件里的DNS项。

3.3 银河麒麟系统的DNS配置与重置

银河麒麟作为国产操作系统，这几年在企业里部署越来越多了。它也是Linux内核，所以配置逻辑和上面讲的Linux方法一脉相承，只是图形界面更接近Windows习惯。

桌面版路径：设置 → 网络 → 有线/无线 → IPv4 → 手动DNS。图形界面的好处是所见即所得，但我遇到更多的问题反而是“Hmm，我DNS配置错了，想重置怎么办”。

重置DNS最干净的命令还是用nmcli：

bash复制# 查看连接名
nmcli con show

# 清空手动DNS，恢复DHCP自动获取
nmcli con mod "有线连接 1" ipv4.dns "" ipv4.ignore-auto-dns no

# 重启连接
nmcli con up "有线连接 1"

如果你之前手动改过/etc/resolv.conf，把它恢复成系统动态生成的软链接，避免下次开机出问题：

bash复制sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

至于IPv6 DNS，现在企业网络里IPv6越来越常见，配置的时候注意别漏了。阿里IPv6 DNS是2400:3200::1，Google是2001:4860:4860::8888。在图形界面里一般有独立的IPv6 DNS输入框，和IPv4分开填。很多同事只改了IPv4，结果IPv6环境下一半域名解析不了，这种问题定位起来特别费时间，我一般建议如果网络不需要IPv6，直接在网卡设置里禁用IPv6，省得它捣乱。

4. 典型DNS故障排查实录：1014事件、DNS Probe和“能上微信打不开网页”

4.1 DNS Client Events 1014：事件日志里的断网元凶

“DNS client events 1014 出现后便断网了”这个描述准确戳中了很多Windows用户的痛点。1014事件在事件查看器里的来源是DNS-Client，完整意思是：在没有配置的DNS服务器响应之后，客户端无法解析名称，系统判定为“没有DNS服务器可用”。

这个事件一出现，最直接的后果就是你发现网页打不开了，但奇怪的是微信还在线——因为微信这类应用走的是IP直连，不依赖域名解析。这正好印证了“能上微信不一定代表网络正常”这个经典现象。

遇到1014事件，我一般按这个顺序排查：

先确认链路通不通：ping网关地址，通则说明局域网没问题；ping 223.5.5.5这个公网IP，通则说明外网链路也没问题。
再用DNS做测试：nslookup www.baidu.com，如果提示超时或找不到服务器，问题基本锁定在DNS上。
用系统设置查DNS：ipconfig /all，看当前网卡拿到的DNS是不是异常，比如变成了奇怪的IP，或者一个不存在的地址。
换DNS试试：把DNS临时改成223.5.5.5，刷新缓存，看问题是否消失。
如果换了还不行，检查安全软件和防火墙有没有拦截UDP 53端口，以及有没有残留的网络代理类软件改写了Winsock配置。这时执行：

bash复制netsh winsock reset
ipconfig /flushdns

然后重启网卡。这两个命令组合解决了很多“玄学”网络问题。

另外，路由器/光猫上的DNS转发故障也可能导致局域网内所有设备集体报1014。如果换电脑、换手机都一样断网，去把光猫和路由器都重启一遍，很多故障就是这么治好的。

4.2 DNS_PROBE_STARTED与浏览器报错的排查链路

如果你用的是Chrome或Edge，打不开网页时地址栏会显示“DNS_PROBE_STARTED”或“DNS_PROBE_FINISHED_NXDOMAIN”。这两个报错的意思不太一样：

DNS_PROBE_STARTED：浏览器准备发起DNS探测，但后续没有收到正常的解析结果，说明解析过程被卡住了。
DNS_PROBE_FINISHED_NXDOMAIN：浏览器已经收到DNS响应，但结果是不存在这个域名，也就是解析“成功但不匹配”。

排查链路可以这样走：

先判断影响范围。只有你这台设备出问题，还是整个局域网都出问题？如果只有一台设备，优先查这台的DNS配置、hosts文件、代理设置和网卡驱动。浏览器里如果有代理插件或系统代理残留，也可能导致“域名解析看上去是DNS问题，实际上是流量被代理劫持到无效地址”。

如果所有设备都打不开网页，重点查路由器。登录路由器后台，看WAN口状态里的DNS是不是空了或者变成了奇怪的值，DHCP设置里下发的DNS是否正常。常见场景是路由器开了“自动获取DNS”，但上游（光猫）没下发，导致局域网设备“没DNS可用”。把路由器的DNS手动改成223.5.5.5和119.29.29.29，基本能解决。

还有一个高频词：“有WiFi但找不到DNS”。这个通常是手机连上了WiFi，但路由器没有正确下发DNS参数，手机的DNS字段是空的。在手机WiFi设置里手动填DNS可以应急，但根治还是要修路由器。

“无法找到DNS地址”本质上就是：你的设备发出DNS查询请求后，在超时时间内没有任何服务器响应。网络层是通的，但“翻译层”断了。理解这一点，你排查方向就不会跑偏。

4.3 我用得最多的五条排查命令组合

排障靠的是工具链，我每次都用的核心命令就这么几条，熟练掌握就能覆盖八成以上的DNS问题：

bash复制# 1. 查看本机IP、网关、DNS全貌（Windows）
ipconfig /all

# 2. 用公网IP测链路，不依赖DNS
ping 223.5.5.5

# 3. 测试当前DNS能否解析
nslookup www.baidu.com

# 4. 跳过当前DNS，直接指定公共DNS测试
nslookup www.baidu.com 223.5.5.5

# 5. 在Linux/macOS上看完整解析链路
dig www.baidu.com +trace

Windows没有dig命令，PowerShell里可以用Resolve-DnsName www.baidu.com -Server 223.5.5.5，功能类似。

第4条命令的价值我特别想强调：当你怀疑“当前DNS可能有问题”时，指定一个已知的公共DNS去解析，如果瞬间能通，问题就出在当前DNS上；如果还是不通，那问题可能在网络链路更底层。这一步能帮你省下大量猜测时间。

另外tracert -d 223.5.5.5（Linux/macOS用traceroute）测路由时，那个-d参数的意思是“不反解域名”，否则每经过一个节点都要尝试DNS解析，速度会很慢。这也是我踩过的小坑。

5. 自建DNS服务器的场景：域控、Windows Server和vCenter那些事

5.1 域环境下的DNS：为什么AD域控离不开DNS

Windows域环境里，DNS不是“可选项”，而是“地基”。域控要正常被发现，依赖的是DNS里的SRV记录。客户端加域或登录域时，会去DNS查询_ldap._tcp.dc._msdcs.你的域名这条SRV记录，找到当前可用的域控地址，然后才建立连接。

这就带来一个铁律：域内客户端的DNS必须指向域控或内网DNS服务器，不能指向公网DNS。 我遇到过的加域失败案例，十有八九是客户机把DNS改成了8.8.8.8或223.5.5.5，域控根本找不到。排查的时候可以先问一句：你DNS指向哪了？一半以上问题当场就能解决。

检查域内DNS的SRV记录是否正常，命令如下：

bash复制nslookup -type=SRV _ldap._tcp.dc._msdcs.contoso.com

返回结果里要有域控服务器的主机名和IP才算正常。如果查不到，要么DNS区域损坏，要么域控没有正确注册记录，可以到域控上重启Netlogon服务，让它重新注册SRV记录。

生产环境里，我建议把DNS区域与Active Directory集成，开启安全动态更新。这样域控重启、IP变更后能自动更新DNS记录，不用手动去改，能少很多半夜被叫起来的麻烦。

5.2 Windows Server上的DNS：添加外部域名与转发配置

企业内部网络一般都有内外网域名共存的需求：内网域名如server.company.com走自建DNS解析，外部域名如baidu.com要走公共DNS解析。Windows Server的DNS服务器提供了两种方案。

第一种叫转发器。当本机DNS区域里查不到某个域名时，统一转发到指定的上游DNS，比如223.5.5.5或运营商DNS。配置路径：DNS管理器 → 右键服务器 → 属性 → 转发器 → 编辑列表添加IP。

第二种叫条件转发器。只针对特定域名转发到特定DNS服务器，其他域名不受影响。比如公司要和某个合作伙伴做系统对接，对方要求用他们的DNS解析partner.com，就可以添加一个条件转发器，只把partner.com转发到对方的DNS，其他域名还是走老路。

Windows Server 2022的DNS管理器里，还能配置DNS策略（DNS Policies），实现基于客户端子网、时间的差异化解析，也可以配置Split DNS——内网用户解析到内网IP，外网用户解析到公网IP。这些功能在实际场景里很实用，比如内网Web应用需要内外访问不同结果时，不用再手动去改hosts。

配置外部域名这块最容易犯的错是把“转发器”和“根提示”搞混。默认情况下，DNS服务器无法解析区域外域名时，会先走“根提示”去问根服务器，但内网环境通常出不去，解析就会失败。正确做法是配置转发器，很多管理员不知道这一点，加上根提示查询超时，外部域名解析就卡死了。

5.3 vCenter 7.0无DNS安装的hosts方案

vCenter 7.0（VCSA）在部署和配置阶段对DNS有硬性检查，这算是很多虚拟化运维踩过的一个坑。它的逻辑是：vCenter要求主机FQDN既能正向解析（名称→IP），也能反向解析（IP→名称），否则部署向导会直接报错，证书和SSO也会有问题。

但测试环境里，尤其是小规模环境，往往没有专门搭建DNS服务器的条件。怎么办？我实践下来可行的一套方案：

部署VCSA时，先用纯IP方式完成初始部署。
部署完成后，通过VAMI（端口5480）登录管理界面，在网络设置里把主机名配成完整的FQDN。
更关键的一步：SSH登录VCSA（Photon OS），编辑/etc/hosts，把vCenter的IP和FQDN映射添加进去：

bash复制# /etc/hosts
192.168.1.100   vcsa.corp.local   vcsa

同时把ESXi主机的/etc/hosts也加上对应的IP和FQDN映射。这样ESXi和vCenter之间通过hosts就能互相识别，绕开DNS缺失的问题。

这里要强调：hosts方案只适合测试环境。 vCenter的证书、vSAN、vSphere HA等功能都深度依赖正常的DNS解析和反向解析，长期在无DNS环境下跑，迟早会出证书过期或主机互联异常的问题。生产环境老老实实搭一套DNS服务器，哪怕是最简单的Windows Server DNS或Linux上的BIND9都行。

5.4 虚拟机桥接模式下改DNS的三个步骤

VMware虚拟机里“桥接模式改DNS”也是搜索热词，属于VMware网络模式里最让人困惑的部分。桥接模式的核心逻辑是：虚拟机直接“插”到物理网络上，和宿主机平级，拥有独立IP，直接使用物理网络的网关和DNS。

配置分三步走：

第一步，在虚拟机设置里把网络适配器改成桥接模式。这里有个细节：VMware里可以选择具体桥接到哪块物理网卡。如果宿主机的上网链路走的是WiFi，就要桥接到无线网卡；如果走有线，桥接到以太网卡。我见过不少人桥接到了错误的网卡上，虚拟机怎么配都不通。

第二步，在客户机系统里配静态IP和DNS。IP要和物理网络同网段、网关一致，DNS填写物理网络使用的DNS（比如局域网网关地址或223.5.5.5）。如果你不确定局域网参数，可以先用“自动获取IP和DNS”的方式，等能上网了，再查看系统里实际获取到的DNS，复制过来改成静态。

第三步，验证。按顺序执行三条命令：

bash复制ping 网关地址
ping 223.5.5.5
nslookup www.baidu.com

分别验证局域网连通、公网连通、DNS解析三个层面，哪一步不通就排查哪一步。

如果是DHCP环境，其实直接用“自动获得DNS服务器地址”是最省心的，系统会自动拿到路由器下发的DNS。只有需要固定DNS时才手动指定。桥接模式下最常见的坑是WiFi的“AP隔离”功能——有些路由器默认开了AP隔离，桥接的虚拟机虽然能拿到IP，但无法和局域网内其他设备互通，这种问题排查起来很隐蔽，建议直接到路由器后台关掉AP隔离。

做运维这几年，DNS相关的问题我处理过太多，总结下来就一条心得：改任何DNS配置之前，先记录现状；改完之后，先清缓存再验证。 这两句话能省掉你一大半的回头路。

再分享一个小技巧：本机hosts文件是个好东西，但一定要克制着用。域名多了之后hosts会变得极难维护，而且一旦某个IP变更，忘记改hosts，排查问题能折腾你半天。我一般只会在测试环境里用hosts做临时的域名指向，生产环境一律走DNS服务器管理。

最后建议大家在配置DNS时保持简单。主备两个DNS足够了，最多三个，再多反而会因为某个DNS超时拖慢整体解析速度。选择适合自己的DNS地址，理解基本的解析流程，绝大多数DNS问题都能自己解决。