设置服务器上的DNS地址，核心是改系统的解析配置文件或网卡接口参数，临时调试用命令直接生效，重启不丢则必须落到持久化配置中，云服务器还要确认云平台的DHCP或初始化脚本不会覆盖你的设定。
服务器dns地址怎么改：先分清临时与持久化两种改法
改DNS这件事,不少运维第一次上手容易踩坑，因为同样的修改动作，不同系统的持久化方式差别很大，分不清临时和持久化，就会遇到“明明改了、重启又变回去”的尴尬。
- 临时改动：直接写入当前运行环境，适合网络调试，重启网络服务或系统后丢失。
- 持久化改动：写入网卡配置文件或网络管理服务，重启后依然生效。
- 云服务器场景下,还需要额外关注初始化脚本对解析文件的接管行为，这部分后面单独展开。
linux服务器dns配置文件修改步骤
对于普通发行版,最直接的临时改动是编辑/etc/resolv.conf，格式为nameserver加IP地址。
- 执行
vi /etc/resolv.conf - 加入一行
nameserver 223.5.5.5 - 保存后立即生效,无需重启网络服务
- 缺点是重启网络或DHCP续租后可能被覆盖
CentOS/RHEL系列的持久化修改，正确路径是编辑网卡接口文件。
- 打开
/etc/sysconfig/network-scripts/ifcfg-eth0（网卡名以实际为准） - 在文件末尾追加
DNS1=223.5.5.5和DNS2=119.29.29.29 - 执行
systemctl restart network让配置生效 - 确认
DNS1的顺序，解析时会按顺序请求，第一个超时才用第二个，把最快的地址放前面
Ubuntu/Debian使用NetworkManager管理的环境，推荐用nmcli命令改。
nmcli con mod "Wired connection" ipv4.dns "223.5.5.5 119.29.29.29"修改连接配置nmcli con up "Wired connection"重新激活连接nmcli device show eth0可以验证当前生效的DNS
windows服务器dns设置界面与命令两种路径
Windows Server图形界面操作比较直观。
- 进入“控制面板”中的“网络连接”
- 右键网卡图标选择“属性”
- 双击“Internet协议版本4 (TCP/IPv4)”
- 勾选“使用下面的DNS服务器地址”
- 填入首选和备用DNS后点击确定
命令行方式在批量操作或远程维护时更高效。
- 管理员身份打开PowerShell
- 执行
Set-DnsClientServerAddress -InterfaceAlias "以太网" -ServerAddresses 223.5.5.5, 119.29.29.29 - 用
Get-DnsClientServerAddress验证是否修改成功 - 如果网卡名称包含空格或中文,先用
Get-NetAdapter确认准确的接口别名
域环境下的Windows Server通常由DHCP或组策略统一下发DNS，单机手动修改优先级低于域策略，改完可能被策略覆盖，这一点需要特别注意。
云服务器dns设置和本地机房配置的主要差异
云服务器的DNS参数是由控制台发放的元数据决定的,本地自建机房则完全由管理员自定义，这个差异在故障排查时往往被忽略。
云平台默认dns地址和自定义dns的冲突
大多数云厂商的初始化进程会在每次实例启动时重置解析配置,把手工改过的地址覆盖回平台默认的私有DNS，行业共识认为，这是云服务器自己改DNS后重启失效的头号原因。
- 查看
/etc/resolv.conf头部是否有“Generated by”字样，有就说明DHCP或初始化组件在管理这个文件 - 登录云控制台检查安全组出方向规则,大部分情况需要放行UDP 53端口
- 如果自定义DNS写在网卡配置文件里,但仍然不生效，检查cloud-init的
resolv_conf模块是否开启了自动接管 - 直接编辑
/etc/cloud/cloud.cfg.d/下的配置，把解析文件管理权交回系统层，是绕开覆盖的一种做法
国内机房和海外节点的解析速度参考
国内服务器解析海外域名时,直接使用海外公共DNS不一定更慢，但跨网路径在晚高峰可能出现明显丢包，多数国内运维会选择简米云223.5.5.5、腾讯DNSPod 119.29.29.29这类国内公共DNS，减少中间跳转。
- 国内业务：配置一个内网DNS、一个公共DNS作为兜底，不要两个都指向同一运营商的骨干网IP
- 海外业务：建议同时启用DoH或DoT加密查询，用1.1.1.1配合加密方式可规避Local DNS污染
- 据CNNIC历年报告显示,域名解析配置错误是政企服务器排障中较为常见的根因之一，多分布在跨网访问场景
服务器dns设置不生效时怎么排查
多数情况下,改完不生效不是命令敲错，而是被系统其他组件截胡了。
配置文件被覆盖是多数情况的元凶
- 检查
/etc/resolv.conf内容是否与修改前一致，观察是否有异常恢复痕迹 - 查看
journalctl -u systemd-resolved日志，看是否有重启或续租后的自动重写动作 - 在CentOS系列的网卡配置里补上
PEERDNS=no，这一步能阻止DHCP下发的DNS覆盖手动设置 - 使用Terraform、Ansible等自动化工具管理的机器，每次provision时可能强制重写解析模板，需要改代码仓库里的配置，而不是在运行中的实例上做修改
防火墙与安全组对53端口的隐性拦截
- 用
nslookup www.baidu.com测试，出现“connection timed out; no servers could be reached”提示时，先排除网络链路，再检查防火墙 - Linux本地firewalld或iptables通常会放行出站53,但企业安全加固脚本经常误伤入站递归查询规则
- 云平台安全组中出方向规则允许UDP 53即可，部分高安全策略要求同时放行TCP 53用于大响应传输
- 如果自建DNS服务器,确认UDP和TCP 53端口都在监听，UDP处理常规查询，TCP处理区域传送与超过512字节的响应
使用dig与nslookup验证解析结果
dig @223.5.5.5 www.example.com指定公共DNS查询，如果命令能返回结果而系统默认解析超时，说明问题出在本地DNS指向没有生效cat /etc/resolv.conf检查有没有写错地址，比如把网关地址当DNS、子网掩码写成IP这类的低级错误，在真实故障中占比不低resolvectl status可以查看systemd-resolved环境下每个网卡实际生效的DNS，这个值往往和/etc/resolv.conf的显示结果不一致
服务器dns设置错误的常见问题与修复
改完服务器dns要重启网络服务吗？
临时修改/etc/resolv.conf后无需重启操作，但重启网络服务时改动会被重置，如果修改的是网卡配置文件，需要执行systemctl restart network或nmcli con up让参数落到运行状态，最快的验证方法是新开一个终端标签页执行解析命令，确认生效即可。
服务器dns设置成公共dns（比如114或223）之后会变慢吗？
不一定,公共DNS的骨干网络覆盖较广，解析主流网站的响应速度与自建DNS差别不大，但由于公共DNS没有内网记录解析能力，访问git.internal这类企业私有域名时会直接失败，所以内网解析依赖和公网解析兜底要拆开使用，不能只填一个公共地址。
如何把服务器dns地址恢复成自动获取？
Linux系统删除网卡配置文件中的DNS1和DNS2行，再执行dhclient -r与dhclient重新租约即可，Windows系统在IPv4属性中改回“自动获得DNS服务器地址”，云服务器如果忘记改过哪些参数，重置网卡或回滚系统盘镜像是最省事的做法，但回滚前记得备份现有配置改动。
设置服务器DNS并不复杂，关键在确认改动是否落在持久化配置层，以及云平台是否有自动化机制接管解析文件，顺着这两个线索定位，多数解析问题都能在几分钟内找到根因。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/793030.html
