Linux配置DNS域名解析怎么做，linux设置dns服务器地址

Linux配置DNS域名解析，核心答案就一句话：先确认系统用的是哪个网络管理服务，再改对应的配置文件或执行对应命令，最后用resolvectl或nslookup验证，绝大多数问题都出在搞混了resolv.conf和systemd-resolved的管理权限。

很多人在Linux服务器上遇到能上外网但打不开网页、解析不了域名的情况，第一反应就是去编辑/etc/resolv.conf，结果一重启，配置全没了，原因很简单，你没搞明白当前系统到底是谁在管DNS，这篇文章就是要把这层窗户纸捅破，让你看完之后，不管遇到哪个发行版,都能用最短时间搞定DNS解析配置。

先搞清楚系统用哪个服务管DNS，再动手改

快速判断网络管理栈是systemd-resolved还是NetworkManager

登录服务器后，先别急着改文件,用两个命令探一下底。

执行ps -ef | grep -E "systemd-resolved|NetworkManager|dnsmasq"，如果看到systemd-resolved在跑，说明你用的是现代Linux发行版（比如Ubuntu 18.04+、CentOS 8+）的标准配置，如果看到NetworkManager，那你就得走它的配置通道，如果两个都有，恭喜你，这就是最常见的问题来源,两套系统在抢DNS控制权。

再看/etc/resolv.conf的第一个字符，这文件通常是个软链接，用ls -l /etc/resolv.conf看一下，如果指向/run/systemd/resolve/目录下的文件，那就是systemd-resolved在管理，如果指向/run/NetworkManager/，那就是NetworkManager说了算，如果是个普通文件（没有箭头指向），那你处于最老旧也最自由的状态,直接编辑即可。

不同配置文件的优先级和生效范围

行业共识认为，Linux下DNS配置的优先级是：网卡配置文件 > systemd-resolved的DNS记录 > /etc/hosts > /etc/resolv.conf，这个顺序很多人搞反了，实际排查时，getent hosts命令查询顺序由/etc/nsswitch.conf控制，默认是先查hosts再走DNS，所以你在hosts里写了条目,DNS怎么改都不生效。

修改/etc/resolv.conf的正确姿势，以及它为何会失效

永久修改的三种实操路径

如果你确定系统没跑systemd-resolved，或者你用的是CentOS 6/7、Ubuntu 16.04这类老系统，直接编辑/etc/resolv.conf确实可行。

步骤：

• 用vi /etc/resolv.conf打开文件。
• 在nameserver行写入DNS服务器IP，比如nameserver 114.114.114.114或nameserver 8.8.8.8。
• 每行只能写一个nameserver，最多支持三个,查询时会按顺序尝试。
• 写入search localdomain这行,可以让你在解析短主机名时自动补全域名。



• 保存退出后，立刻用nslookup测试是否生效。

但要注意，这种修改方式在重启网卡（systemctl restart network或systemctl restart networking）后大概率被重置，因为网卡配置文件里的DNS1=参数在重启时会重新生成resolv.conf。

解决重启失效的核心操作

想让配置在linux系统重启后依然保持，你得把DNS写进网卡配置文件，而不是resolv.conf里。

• CentOS/RHEL系统：编辑/etc/sysconfig/network-scripts/ifcfg-eth0（网卡名替换成你实际的，用ip addr查看），在文件里添加DNS1=223.5.5.5和DNS2=119.29.29.29，然后执行systemctl restart network。
• Debian/Ubuntu系统：编辑/etc/network/interfaces，在网卡配置段（比如auto eth0那个块）里加一行dns-nameservers 223.5.5.5，然后重启网络服务,或者直接重启机器验证。

记住一个原则：systemd管理的系统里，/etc/resolv.conf只是展示层，它展示的是底层服务计算出来的结果，你想改底层,就必须去服务真正读取的地方改。

systemd-resolved环境下，linux配置dns域名解析的正确指令

用resolvectl命令替代直接编辑文件

在Ubuntu 18.04+、Debian 10+、CentOS 8+（如果启用了systemd-resolved）上，直接编辑resolv.conf会被瞬间覆盖，正确做法是用resolvectl命令来设置,这才是2026年最标准的操作。

具体命令如下：

# 设置全局DNS，所有网卡默认使用该DNS
resolvectl dns set eth0 223.5.5.5 119.29.29.29
# 设置某个网卡的DNS
resolvectl dns eth0 8.8.8.8
# 设置DNS搜索域
resolvectl domain eth0 example.com
# 查看当前所有网卡的DNS配置
resolvectl status

设置完后，/etc/resolv.conf也会跟着变，但你不需要去动它。重点在于，执行完命令别忘了用systemctl daemon-reload刷新一下状态，然后看resolvectl status确认新值已经写入。

永久生效需要写入netplan或systemd-networkd配置

resolvectl命令设置的值重启后会丢，要让永久生效，需要写进netplan的配置文件（Ubuntu 18.04+）或systemd-networkd的.network文件。

netplan的配置在`/etc/netplan/.yaml`,典型配置逻辑如下：

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      nameservers:
        addresses: [223.5.5.5, 119.29.29.29]
        search: [example.com]

改完执行netplan apply即可生效,不需要重启系统。

systemd-networkd的配置目录在/etc/systemd/network/，你需要在网卡对应的.network文件里加上DNS=和Domains=选项，然后重启systemd-networkd服务。

桌面版和服务器版dns配置有啥区别，哪些坑必须绕开

桌面版往往被NetworkManager接管，别和resolv.conf硬刚

Ubuntu桌面版、Fedora工作站、Deepin这些系统，默认跑着NetworkManager，而且它会接管DNS管理，这种情况下，linux配置dns域名解析的正确路径是使用nmcli命令,或者直接改连接配置文件。

nmcli操作步骤：

# 查看当前连接名称，一般是Wired connection 1或enp3s0
nmcli connection show
# 修改DNS，注意要写UUID或连接名，且需要重新激活
nmcli con mod "Wired connection 1" ipv4.dns "223.5.5.5 8.8.8.8"
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
# 重新激活连接
nmcli con up "Wired connection 1"

改完后用nmcli device show查看DNS信息有没有更新，切忌在NetworkManager运行时手动改resolv.conf,你改了它也会在下次连接时恢复原样。

公司内网linux域名解析配置场景的特殊处理

如果你在公司内网，可能需要同时访问内网域名和公网域名，就得用到DNS搜索域和条件转发的配置，场景是这样的：你在公司配了AD域或内部GitLab，内网域名是corp.internal，但你又不想让所有DNS请求都走内网DNS,因为那会很慢。

方案一用的是在/etc/resolv.conf里配置search域加上两个nameserver,但这会导致内网DNS解析公网域名时不可用。

方案二更推荐，就是用dnsmasq做本地DNS转发，你在/etc/dnsmasq.conf里配一个上游DNS（比如223.5.5.5），再对.internal域单独指定用公司内部DNS服务器解析：

server=223.5.5.5
server=/corp.internal/10.10.10.53

这样所有公网域名走阿里DNS，内网域名走公司DNS，一条命令都不用等，这类配置在代码托管平台和CI/CD服务器上比较常见,很多运维都习惯在本地跑dnsmasq解决多DNS冲突问题。

Linux下查看DNS配置命令与验证方法汇总

一套完整的验证流程，从配置到生效

改完配置不等于生效,你需要按顺序检查三层。

第一步看系统解析状态，用resolvectl status查看每张网卡绑定的DNS服务器,确认地址是正确的。

第二步看实际查询走哪个DNS，用nslookup命令指定某个DNS来测试解析某个域名，如果你用不带参数的

nslookup baidu.com，它默认会走/etc/resolv.conf里设置的DNS，如果你发现输出里Server那行显示的是0.0.53，说明你正在走systemd-resolved的本地转发,这是正常的。

第三步用dig命令看解析耗时和路径，dig能看到更详细的查询链路。dig @223.5.5.5 www.example.com会强制用阿里DNS解析，不经过本地配置,适合排查是不是本地DNS缓存污染导致的问题。

常见的dns配置不生效原因排查

遇到配置了DNS但解析不了的情况,按优先级排查以下几个点：

• 检查/etc/nsswitch.conf里的hosts行，如果这行的顺序变成了files dns以外的东西,名字解析可能不走DNS。
• 检查/etc/resolv.conf是否被只读保护，用lsattr /etc/resolv.conf看有没有加i属性,加了这个属性你改什么都写不进去。
• 检查防火墙是否拦截53端口UDP流量，这条经常被忽略,特别是云服务器上的安全组规则。
• 检查网卡本身是不是处于degraded状态，用nmcli device status看，如果显示unavailable，说明网卡状态异常,DNS配置自然不生效。

大多数情况下，能ping通IP地址但解析不了域名，问题都出在DNS服务器地址配置错误或防火墙拦截上,不是系统解析器坏了。

Q&A：linux配置dns域名解析的常见疑难解答

为什么改了resolv.conf后一重启就还原？

这是因为你的系统运行着systemd-resolved或NetworkManager，开机时它们会用自己的配置重新生成/etc/resolv.conf，你想要永久生效，就得把DNS写进这两个服务读取的配置文件里,具体路径和命令已经在上文的描述中列出。

配置里写了多个DNS服务器，为什么第二个似乎没在用到？

这取决于你用的解析器实现，glibc默认只会用第一个nameserver做查询，如果第一个超时（连接超时一般是几秒到几十秒），才会去用第二个，所以很多人在第一个DNS失效时，觉得DNS整体变慢了，是正常现象，你可以通过options timeout:1 attempts:1来缩短超时时间,代价是DNS解析更快失败。

断网环境下，本机域名解析能测试吗？

可以，用dig @127.0.0.53来测试本地systemd-resolved是否正常工作，只要它能返回结果，说明你的systemd解析服务本身没垮，如果需要彻底验证配置是否解析正常，你可以用getent hosts这个命令，它会按照nsswitch.conf的配置走完整解析流程，模拟程序实际请求的行为,得到对照答案。