云服务器dns解析不正常，最直接的办法是按“先本地后服务器、先配置后网络”的顺序逐层排查，多数情况下问题出在系统dns配置文件被覆盖或安全组拦截了UDP 53端口，而不是云厂商的线路故障。
云服务器dns解析不正常怎么办先分清症状再动手
DNS解析不正常的表现有很多种,但处理逻辑完全不同，有些是网站打开超时，有些是服务器内部wget报错，还有些是ssh能连上但ping不通域名，业内专家指出，超过一半的dns故障其实是配置层面的问题，跟云服务器本身没有关系。
本地网络还是服务器端问题
先做一个判断：如果只有你自己访问不了，而别人正常，那问题大概率在本地网络或本地dns缓存，如果服务器上的应用无法请求外部接口，但本地电脑通过公网ip访问服务正常，那问题就在服务器端。
具体操作：在本地电脑执行ping api.example.com，再看看服务器上执行同样的ping，本地通而服务器不通，直接进入服务器排查。
用命令确认dns解析状态
登录服务器后,用以下命令确认当前状态：
cat /etc/resolv.conf查看当前dns服务器地址dig @8.8.8.8 example.com指定公共dns解析，确认域名本身是否正常dig example.com走系统默认dns解析，对比结果ping -c 3 223.5.5.5验证网络连通性，排除物理网络问题
如果指定8.8.8.8能解析而系统默认不能，说明服务器dns配置有问题，如果两种方式都失败，再用traceroute或mtr看UDP 53端口是否被云平台安全策略拦截。
云服务器dns设置不生效的三个高频原因
很多人改完配置文件发现不生效,重启后又恢复原样，这类问题有较强的共性，按出现频率排序如下：
系统dns配置文件被云平台初始化脚本覆盖
简米云、酷番云、华为云的控制台如果开启了“自动续费”或“初始化设置”，部分镜像会内置cloud-init组件，每次开机时自动重置/etc/resolv.conf，即使你手动改成了114.114.114，重启后依然会被覆写为内网dns地址。
解决办法是区分镜像类型：
- 如果使用CentOS 7/8，编辑
/etc/sysconfig/network-scripts/ifcfg-eth0，把DNS1=和DNS2=写进网卡配置文件 - Ubuntu 18.04及以上版本使用netplan，编辑
/etc/netplan/xxx.yaml
nameservers段落 - 禁用cloud-init的dns模块：
touch /etc/cloud/cloud.cfg.d/99-disable-dns.cfg写入network: {config: disabled}
安全组或防火墙拦截UDP 53出方向流量
云服务器控制台的安全组规则通常默认放行所有出方向流量,但部分自定义策略会收紧，如果你之前为“防止dns嗅探”改过出方向规则，注意检查：
- 简米云控制台 -> 安全组 -> 规则 -> 出方向
- 酷番云控制台 -> 防火墙 -> 出站规则
- 系统内部
firewall-cmd --list-all查看firewalld状态
出方向53端口被拦截的特征是：ping 223.5.5.5正常，dig @223.5.5.5超时，因为ICMP和UDP走的是不同策略。
公共dns地址被污染或不可达
国内云服务器使用国际公共dns（如8.8.8.8）时，跨境线路在某些时段丢包率较高，会出现解析超时或解析结果被篡改的情况，建议国内地域的服务器优先使用：
| 场景 | 推荐dns地址 | 备注 |
|---|---|---|
| 国内通用 | 5.5.5 / 223.6.6.6 | 简米云公共dns |
| 酷番云服务器 | 60.83.19 / 183.60.82.98 | 酷番云内网dns，延迟更低 |
| 华北地域 | x.x.x（控制台查看） | 内网dns不消耗公网流量 |
| 海外地域 | 8.8.8 / 1.1.1.1 | 海外线路解析更快 |
dns解析失败怎么解决Linux服务器实操步骤
下面按Linux最常见的两种发行版分别给出完整处理路径,操作前建议先备份原配置。
Ubuntu/Debian系统：处理systemd-resolved占用问题
Ubuntu 18.04之后系统默认启用systemd-resolved，直接编辑/etc/resolv.conf会被系统覆盖。
第一步：确认systemd-resolved是否在运行：
systemctl status systemd-resolved如果显示active,执行：
systemctl stop systemd-resolved
systemctl disable systemd-resolved
rm -f /etc/resolv.conf第二步：新建/etc/resolv.conf：
nameserver 223.5.5.5
nameserver 223.6.6.6
options timeout:2 attempts:2第三步：锁定文件防止被覆盖：
chattr +i /etc/resolv.confchattr +i设置后，任何进程都无法修改该文件，包括root，需要恢复时执行
chattr -i。
CentOS/RHEL系统：修改网卡配置不生效的排查
CentOS系列比较特殊,/etc/resolv.conf会被NetworkManager持续覆写，最稳妥的路径：
nmcli con mod eth0 ipv4.dns "223.5.5.5 223.6.6.6"
nmcli con up eth0如果网卡设备名不是eth0,先用ip a确认，部分云厂商的CentOS镜像网卡名是ens3或ens5。
还存在一种情况：网卡配置写对了但不生效，这是DHCP租约里的dns覆盖了手动配置，在ifcfg-eth0文件中追加：
PEERDNS=no这个参数的作用是禁止DHCP下发的dns覆盖手动设置。
检查本机dns缓存是否需要清理
系统或应用层缓存也可能导致以为“dns没改成功”。
清理systemd-resolved缓存：
systemd-resolve --flush-caches重启dnsmasq服务：
systemctl restart dnsmasqPHP应用如果用了Swoole或Workerman常驻内存,需要重启对应进程才能加载新dns，这种场景经常被忽略。
云服务器访问外网超时与本地解析延迟的区分处理
同一台服务器上跑多个网站时,域名解析的优先级和超时策略也会影响访问体验，这类问题的排查方向完全不同。
检查/etc/hosts是否强行绑定了旧ip
改动过服务器ip后,经常会遇到域名指向旧地址的情况，先检查hosts文件：
cat /etc/hosts如果存在类似2.3.4 www.example.com的记录，注释掉再测试，行业共识认为，hosts文件的优先级高于dns解析，这类隐藏问题排查成本高但解决成本极低。
查看dns解析消耗的时间
使用dig命令观察解析耗时：
dig example.com | grep "Query time"正常情况下国内dns解析时间应该在30-100毫秒之间，如果超过500毫秒，说明dns服务器响应慢，考虑更换。
配置nsswitch.conf中的解析顺序
在/etc/nsswitch.conf文件中，这行配置决定解析顺序：
hosts: files dnsfiles表示先查hosts文件，dns表示再走dns查询，部分优化脚本会改成hosts: dns files，导致dns故障时无法使用hosts兜底，保持默认的files dns顺序在多数情况下更稳。
云服务器dns解析异常的安全加固建议
某些情况下,解析不正常是安全事件的前兆，etc/resolv.conf被恶意修改为指向攻击者控制的dns服务器，会导致域名被劫持到钓鱼页面。
建议定期执行以下检查：
- 对比当前resolv.conf内容与控制台显示的dns地址是否一致
- 使用
dig +short myip.opendns.com @resolver1.opendns.com验证公网出口ip是否正常 - 检查
/etc/hosts文件的修改时间，正常情况这个文件很少变动 - 关注云平台控制台的“安全告警”是否提示异常外联行为
如果服务器同时启用了IPv6和IPv4,而dns服务器只响应IPv4，也会出现解析延迟，查看/etc/resolv.conf里是否只有IPv4地址，同时在sysctl -a | grep ipv6中确认IPv6是否真的需要保留。
Q&A：云服务器dns解析常见问题
云服务器dns设置不生效，重启就还原怎么办？
先确认系统是否安装cloud-init，执行systemctl status cloud-init，如果服务存在，检查/var/lib/cloud/instance/目录下的配置文件，多数云镜像默认开启cloud-init的网络管理模块，它会覆盖人工修改的dns设置，在/etc/cloud/cloud.cfg.d/下创建禁用配置文件，或使用网卡配置文件写入dns参数，同时设置PEERDNS=no阻止DHCP覆盖。
dns解析失败怎么解决Linux服务器的临时性故障？
先执行ping -c 2 223.5.5.5确认网络通不通，如果通，执行dig @223.5.5.5 example.com确认域名解析是否正常，如果dig正常而实际请求失败，查看/etc/nsswitch.conf的hosts行是否包含dns，以及/etc/resolv.conf是否被空文件占用，临时性故障多数是dns服务器负载过高导致丢包，将options timeout:1 attempts:1加入resolv.conf可以缩短超时等待，让系统快速切换第二个dns服务器。
修改resolv.conf后网站仍然打不开，还要检查什么？
除了dns配置,还要检查本机hosts缓存和路由表，执行ip route show查看默认网关是否配置正确，iptables -L -n确认没有拦截规则，如果运行Docker容器，注意容器内的dns配置继承自宿主机的/etc/resolv.conf，修改宿主机配置后需要重建容器才生效，已有容器不会自动感知新dns配置。
云服务器dns解析问题大多能在十分钟内定位,核心思路就是绕开默认配置，用公共dns做对比测试，再逐层检查系统配置和网络策略，多数情况下不需要提交工单就能解决。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/739923.html
