服务器自动获取DNS地址失败,通常是DHCP服务未响应、网卡驱动异常或网络环境冲突所致,最直接的解决方法是手动指定公共DNS地址(如114.114.114.114),然后按下面步骤排查。
先别急着重装系统,按顺序做这三件事
服务器不像家用电脑,DNS获取失败会导致域名解析不了,网站打不开,甚至影响整个内网,遇到这个问题,先别慌,也别急着重启,下面三个动作能解决大多数情况。
第一步:确认是“获取失败”还是“拿到了但用不了”
很多人把这两个混在一起,真正的自动获取失败,是网卡里显示“无Internet访问”或“DNS服务器未分配”,这时候打开命令行输入ipconfig /all(Windows)或cat /etc/resolv.conf(Linux),看看有没有DNS地址。
- 如果地址是空的,说明DHCP没分配。
- 如果地址是192.168.x.x之类的内网IP,说明拿到了但可能DNS服务本身有问题。
- 如果你看到的是8.8.8.8或114.114.114.114,那说明之前有人手动改过,不是自动获取的。
第二步:重启DHCP客户端服务
这个操作简单但经常被忽略,在Windows服务器上,按Win+R输入services.msc,找到DHCP Client服务,右键重启,如果服务停着,直接启动。
Linux服务器则用命令:
sudo systemctl restart systemd-resolved
或者对于老版本:
sudo service network-manager restart
第三步:检查网卡是否被“禁用”或“半禁用”
某些服务器面板(比如宝塔、Plesk)可能改过网卡配置,导致自动获取被覆盖,到网络适配器设置里,把网卡禁用再启用,有时候就能重新触发DHCP请求。
做完这三步,大概率问题就解决了,如果还没好,接着往下看。
服务器dns获取失败怎么修复?手动指定DNS地址最靠谱
自动获取失败,最省心的办法就是手动指定DNS,这不算违背“自动获取”的初衷因为很多服务器场景下,手动指定反而比依赖DHCP更稳定。
Windows服务器手动指定DNS
- 打开“网络和共享中心”→“更改适配器设置”。
- 右键当前网卡(通常是“以太网”),选择“属性”。
- 双击“Internet协议版本4 (TCP/IPv4)”。
- 选择“使用下面的DNS服务器地址”,填入:
- 首选:
5.5.5(阿里) - 备用:
29.29.29(腾讯)
- 首选:
- 确定后重启网卡(禁用再启用),立刻生效。
Linux服务器手动指定DNS
如果是Ubuntu/Debian(使用Netplan):
sudo nano /etc/netplan/00-installer-config.yaml
在nameservers下加:
nameservers:
addresses: [223.5.5.5, 119.29.29.29]
然后执行sudo netplan apply。
如果是CentOS/RHEL,直接改:
sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
添加:
DNS1=223.5.5.5
DNS2=119.29.29.29
重启网络服务systemctl restart network。
这里有个关键点:手动指定DNS后,记得确认网卡没有同时勾选“自动获得DNS服务器地址”,否则重启后可能被覆盖,行业共识认为,服务器长期运行最好用固定的DNS,避免每次重启都要重新获取。
为什么服务器自动获取dns地址总是失败?常见三处坑
有些服务器隔三差五就出这问题,不是偶然,是下面几个原因在反复作妖。
坑一:路由器/交换机上的DHCP地址池枯竭
小公司集群尤其常见,当内网设备太多,DHCP池分光了,新服务器自然拿不到地址,去路由器管理页面看看地址池剩余量,如果只剩个位数,就扩大范围或减少设备。
坑二:网卡驱动和虚拟化平台不兼容
跑在VMware或KVM上的服务器,如果用的是半虚拟化驱动,偶尔会出现DHCP请求发不出去的情况,去厂商官网更新驱动,或者把网卡模式从“自动协商”改成“强制1000M全双工”,能解决一部分怪问题。
坑三:防火墙挡住了UDP 67/68端口
DHCP依赖这两个端口,如果服务器自带防火墙或安全组策略,把它们给禁了,那获取请求就石沉大海,检查入站规则,确保UDP 67(服务端)和68(客户端)是放行的,特别是简米云、酷番云的安全组,很多人改了实例的防火墙但忘了后台安全组。
手动配置完dns还是不行?试试刷新缓存和检查hosts
手动指定DNS之后,如果还是解析不了,那就不是“获取”的问题了,而是“使用”的问题。
刷新本地DNS缓存
Windows:
ipconfig /flushdns
Linux(systemd-resolved):
sudo systemd-resolve --flush-caches
检查hosts文件有没有被篡改
有些挖矿病毒会改服务器的hosts文件,把常见域名指向恶意IP,打开C:\Windows\System32\drivers\etc\hosts(Windows)或/etc/hosts(Linux),看看有没有奇怪的条目,正常的hosts文件除了注释,基本没有实际内容,如果看到一堆陌生的IP和域名,直接清空(保留localhost那行)。
用nslookup做交叉测试
在命令行输入:
nslookup baidu.com 223.5.5.5
如果这个有响应,说明网络通,只是DNS服务器配置有问题,如果这个也超时,那就是网络二层或三层的问题,跟DNS半毛钱关系都没有。
服务器dns设置不生效?多半是网络服务没重启
有个特别常见的误区:改了配置但没重启网络服务,结果以为设置没用,改完任何配置,必须重启对应的服务,这个步骤跑不了。
Windows下重启网卡的命令
以管理员身份运行:
netsh interface set interface "以太网" disabled
netsh interface set interface "以太网" enabled
如果网卡名称不是“以太网”,先用ipconfig看名字。
Linux下统一重启网络
sudo systemctl restart systemd-networkd
或者对于NetworkManager用户:
sudo systemctl restart NetworkManager
一个实用技巧:在Linux服务器上,修改DNS后先不要重启网卡,直接执行
sudo resolvectl dns ens33 223.5.5.5
临时生效,测试流畅后,再写进永久配置,这样可以避免重启网卡导致SSH断开,尤其对远程机器特别友好。
如何避免下次再犯?设置DNS自动备份和监控
服务器运维不能全靠出问题再修,要提前设防,既然自动获取不稳定,那就用一个“半自动”方案。
写一个DHCP失败自动回退脚本
在Linux服务器上,写一个crontab脚本,每5分钟检测一次DNS是否可用:
#!/bin/bash
if ! nslookup baidu.com 223.5.5.5 &> /dev/null; then
echo "nameserver 223.5.5.5" > /etc/resolv.conf
fi
然后在crontab里加上/5 /root/check_dns.sh,这样即使DHCP又出问题,脚本也会自动把DNS改回公共地址,不影响业务。
给Windows服务器做DNS事件日志告警
在事件查看器里,网络相关的“警告”事件ID为1014和1016,它们就表示DNS获取失败,用任务计划程序在触发这两个事件时发邮件,就可以第一时间知道,不用等用户反馈。
常见问题Q&A
问:服务器显示“DNS地址未分配”,但手动填了还无法上网,怎么回事?
这通常不是DNS问题,而是网关地址错了或路由表乱了,先看网卡上的默认网关是否正确,如果网关还是自动获取的,但获取不到,那就需要手动指定一个网关IP,在Windows里检查route print,Linux里用ip route,确认默认路由指向真正的路由器。
问:公共DNS用哪个比较好?国内服务器用114还是223.5.5.5?
如果服务器主要服务国内用户,推荐用5.5.5(阿里DNS)或29.29.29(腾讯DNS),这两个解析较快,且自带防污染能力,114.114.114.114虽然老牌,但近年有些地区网络解析速度波动,跨境业务可以加一个8.8.8作为备用,但别当首选,因为国内访问延迟高。
问:自动获取DNS失败会导致服务器被攻击吗?
不会,DNS获取失败只是让域名解析不可用,属于可用性问题,不是安全问题。真正要担心的是手动配置了不可信的DNS地址,比如被劫持到恶意DNS服务器,那才会导致钓鱼风险,所以务必只用已知可信的DNS地址,并定期检查/etc/resolv.conf有没有被篡改。
最后说一句
服务器自动获取DNS失败,本质上是网络配置的“脆弱性”暴露了,与其每次手动折腾,不如直接改成固定DNS,然后把网卡服务设为开机自启,对于生产环境,稳定性比“自动”更重要,你只需要花十分钟做一次彻底排查,就能让这台服务器在很长一段时间里不再犯这个毛病。