Linux配置DNS地址的核心操作就一句话：找到系统的DNS配置文件或网络管理工具，写入正确的nameserver地址，并确保重启后配置不被覆盖。
很多人在服务器上遇到域名解析失败，第一反应是网络断了，其实多数情况下只是DNS地址没配对，Linux系统没有统一图形界面，配置DNS需要分发行版、分工具来看,下面按实际使用频率拆解。
linux怎么设置dns地址：先找到配置文件
Linux里DNS配置最常见的入口是/etc/resolv.conf，这个文件直接决定系统向哪台DNS服务器发起查询，先用cat /etc/resolv.conf查看当前内容,正常会看到类似：
nameserver 223.5.5.5
nameserver 114.114.114.114如果这个文件是空的，或者只有0.0.53，说明系统可能由systemd-resolved或NetworkManager接管了DNS。
临时修改：直接编辑resolv.conf
适合快速测试，重启后可能失效,用root权限编辑：
sudo vim /etc/resolv.conf改成：
nameserver 223.5.5.5
nameserver 8.8.8.8保存后执行ping www.baidu.com验证，如果解析恢复，说明问题就出在DNS地址上，但服务器重启后，很多发行版会重新生成这个文件,所以临时改完还得做永久配置。
永久修改：按工具区分
NetworkManager（CentOS、Rocky Linux、部分Ubuntu桌面版）
用nmcli命令最稳：
nmcli con mod eth0 ipv4.dns "223.5.5.5 114.114.114.114"
nmcli con up eth0eth0要替换成实际网卡名，可通过nmcli con show查看，这种方法会同步写入resolv.conf,重启也保留。
systemd-resolved（Ubuntu Server 18.04+）
Ubuntu的/etc/resolv.conf通常是软链接，指向/run/systemd/resolve/stub-resolv.conf，直接编辑没有用,要改netplan配置：
sudo vim /etc/netplan/00-installer-config.yaml在对应网卡下加入：
nameservers:
addresses:
- 223.5.5.5
- 114.114.114.114
然后执行sudo netplan apply生效,这是Ubuntu上linux怎么设置dns地址的标准答案。
centos配置dns地址和ubuntu配置dns地址的区别
这两个系统是服务器市场主力，但DNS配置路径差异很大，新手容易搞混,下面用表格对比。
| 对比项 | CentOS / Rocky Linux | Ubuntu Server |
|---|---|---|
| 主要工具 | nmcli、网卡配置文件 | netplan、systemd-resolved |
| 配置文件路径 | /etc/sysconfig/network-scripts/ifcfg-eth0 | /etc/netplan/.yaml |
| resolv.conf是否可编辑 | 可临时编辑，但NetworkManager可能覆盖 | 不可直接编辑，是软链接 |
| 永久配置命令 | nmcli con mod ipv4.dns | netplan + apply |
| 验证命令 | nmcli dev show eth0 | resolvectl status |
CentOS具体操作
CentOS 7和8都可以用nmcli，如果系统最小化安装没有NetworkManager,则需要编辑网卡文件：
sudo vim /etc/sysconfig/network-scripts/ifcfg-eth0加入或修改：
DNS1=223.5.5.5
DNS2=114.114.114.114保存后重启网络：
sudo systemctl restart networkCentOS 8以上建议直接用nmcli，避免network.service与NetworkManager冲突。
Ubuntu具体操作
Ubuntu 20.04和22.04必须通过netplan，编辑配置文件后，用sudo netplan try可以先测试，没问题再正式应用，这比直接apply更安全，因为配置错误会导致断网，try会在超时后自动回滚。
docker容器linux配置dns地址的场景
容器环境下的DNS配置和宿主机不同，很多人在容器里发现/etc/resolv.conf被自动生成，手动改完重启容器又还原,这是docker容器linux配置dns地址时最典型的坑。
单容器指定DNS
docker run时用--dns参数：
docker run -d --dns 223.5.5.5 --dns 114.114.114.114 nginx这样容器启动后，/etc/resolv.conf会自动写入这两个DNS地址,重启容器也会保留。
全局默认DNS
如果不想每个容器都手动指定，可以修改/etc/docker/daemon.json：
{
"dns": ["223.5.5.5", "114.114.114.114"]
}然后执行sudo systemctl restart docker重启服务，之后新建容器都会默认使用这些DNS,已经存在的容器需要重新创建才会生效。
docker-compose写法
在compose文件中给某个服务单独配置：
services:
web:
image: nginx
dns:
- 223.5.5.5
- 114.114.114.114这个场景常见于微服务架构中，不同服务走不同DNS解析策略，比如内网服务用内网DNS,公网服务用公共DNS。
国内服务器linux配置dns地址不生效排查
这是搜索量很高的实际问题，有些用户改了DNS，重启后还是原来的，或者解析仍然失败,排查顺序可以从下往上查。
第一步：确认resolv.conf是否被覆盖
执行：
cat /etc/resolv.conf如果里面出现了不是你设置的地址，比如0.0.53，说明有别的服务在接管，常见的是systemd-resolved，可以用resolvectl status查看当前DNS。
第二步：检查NetworkManager是否关闭了自动获取
CentOS上如果网卡配置里同时存在BOOTPROTO=dhcp和手动DNS，可能出现冲突，把BOOTPROTO改为none或static,再指定DNS。
第三步：测试DNS服务器本身是否可用
用nslookup或dig直接指定DNS测试：
nslookup www.baidu.com 223.5.5.5如果返回结果正常，说明DNS服务器没问题，是本地配置没生效；如果不正常，换一个DNS地址试试，114.114.114.114和223.5.5.5在国内机房连通性通常较好，但部分云服务器对UDP 53端口有内部限制,需要改用云平台提供的内部DNS。
第四步：查看系统日志
journalctl -u systemd-resolved -n 50日志中如果有timeout或network unreachable，说明UDP 53端口不通,需要检查安全组或防火墙。
linux配置dns地址收费吗
修改Linux的DNS配置本身
不收费，无论你用哪个发行版，编辑配置文件、执行命令都不需要额外付费,DNS解析是否收费取决于你使用的DNS服务商。
- 公共DNS：如114.114.114.114、阿里223.5.5.5、腾讯119.29.29.29，个人和中小企业免费使用。
- 云平台内部DNS：简米云、酷番云的VPC内网DNS对云服务器免费,但跨地域解析或私有域名解析可能有少量费用。
- 企业级DNS服务：如DNSPod企业版、简米云解析企业版，按套餐收费,价格从每年几百元到数千元不等。
行业共识认为，绝大多数Linux服务器直接使用公共DNS或云平台免费内网DNS即可满足需求，不需要额外购买付费DNS解析服务，只有在需要高防DNS、多线路智能解析、私有域名管理时才考虑付费方案。
Linux配置DNS地址的思路比命令更重要：先判断系统由谁管理网络，再选择对应的配置文件或工具，改完记得用nslookup或dig验证,不要只看配置没报错就认为成功了。
Q&A
linux配置dns地址后多久生效
临时修改/etc/resolv.conf立即生效，通过nmcli修改后，重启网络连接生效；通过netplan修改后执行netplan apply立即生效，如果你改的是网卡配置文件，需要重启网络服务，容器里修改daemon.json后，只有新建容器才会生效,旧容器需要重新创建。
linux配置dns地址和windows配置dns地址的区别
Windows在图形界面的网络适配器属性里直接填写DNS，或者用netsh命令修改，Linux没有统一界面，不同发行版配置文件路径不同，Windows修改后通常立即生效，Linux某些方法需要重启服务或重新加载配置，Windows下DNS设置跟随网卡，Linux下可能被多个服务同时管理,更容易出现配置被覆盖的情况。
linux配置dns地址不生效怎么检查
按顺序执行：查看/etc/resolv.conf内容是否为你设置的地址；执行systemd-resolve --status或resolvectl status查看实际生效的DNS；用nslookup www.baidu.com 223.5.5.5测试DNS服务器本身连通性；检查防火墙或云安全组是否放行UDP 53端口，多数情况下，不是DNS地址配错了,而是配置文件被系统服务重新生成覆盖了。