在Ubuntu服务器运维与使用过程中，遇到ping不通域名但能正常ping通IP地址的情况，核心上文归纳通常指向DNS解析故障或系统网络配置错误，而非物理链路中断，这意味着网络层（Layer 3）是通畅的，但应用层（Layer 7）无法将人类可读的域名转换为机器可识别的IP地址，解决这一问题需遵循“先诊断、后修复、再验证”的逻辑，重点检查DNS配置文件、Netplan网络管理器配置以及systemd-resolved服务状态。
诊断故障源头：区分网络问题与DNS问题
在动手修改配置之前，必须精准定位问题，首先尝试ping一个公网IP地址，例如Google的公共DNS 8.8.8或国内的114.114.114，如果能够ping通IP地址，且延迟正常，说明服务器的网络连接、网关配置以及路由表均无异常，问题确凿无疑地出在DNS解析环节，反之，如果连IP都无法ping通，则需优先检查网卡驱动、网关设置及云厂商的安全组策略，本文主要聚焦于前者——即网络通畅但域名解析失败的场景。
临时解决方案：修改/etc/resolv.conf配置
对于急需恢复业务的场景，最快的修复方法是直接修改DNS解析配置文件，在Ubuntu中，DNS配置通常位于/etc/resolv.conf，使用文本编辑器打开该文件，检查其中是否包含正确的nameserver条目，如果该文件为空，或者指向了无法访问的IP（如错误的内网DNS）,则需手动添加。
通常建议添加国内访问速度较快的公共DNS，如阿里云DNS（5.5.5、6.6.6）或腾讯云DNS（29.29.29），亦或是Google的8.8.8，修改完成后，保存文件并再次尝试ping域名，需要注意的是，在Ubuntu 18.04及之后的版本中，/etc/resolv.conf通常是一个软链接，由systemd-resolved服务动态管理，重启系统或网络服务后，手动修改的内容可能会被覆盖，这仅作为临时应急措施。
永久解决方案一：通过Netplan配置固定DNS
为了确保DNS配置在重启后依然生效，必须从网络管理的源头进行设置，现代Ubuntu版本（18.04+）默认使用Netplan作为网络配置工具，其配置文件通常存放在/etc/netplan/目录下，文件名可能为00-installer-config.yaml或类似名称。
编辑该YAML文件时，需特别注意语法格式（缩进必须使用空格而非Tab键），在对应的网卡配置块下，添加nameservers字段，并填入DNS地址,配置示例如下：
network:
ethernets:
eth0:
addresses: [...]
gateway4: ...
nameservers:
addresses: [223.5.5.5, 8.8.8.8]
version: 2
修改完成后，执行sudo netplan apply命令使配置生效，此方法将DNS直接写入网卡配置，是最稳定、最符合系统规范的永久修复方案。
永久解决方案二：配置systemd-resolved服务
如果Netplan配置未生效，或者系统环境较为复杂，可能涉及到systemd-resolved服务的存根DNS（Stub DNS）监听问题，Ubuntu默认运行该服务来处理DNS，它会在/etc/resolv.conf中指向0.0.53，如果该服务卡死或配置冲突,会导致解析失败。
可以通过编辑/etc/systemd/resolved.conf文件来修复，在该文件中找到[Resolve]部分，取消DNS行的注释，并填入公共DNS地址，同时将FallbackDNS也进行补充，修改完毕后，需重启服务：sudo systemctl restart systemd-resolved，为了防止/etc/resolv.conf被意外还原，可以将其删除，然后重新创建一个指向/run/systemd/resolve/resolv.conf的软链接，或者直接写入静态内容并锁定文件属性（使用chattr +i命令），但这属于进阶操作,需谨慎使用。
进阶排查：防火墙与端口检查
除了DNS配置本身，防火墙规则也可能阻断DNS查询流量，DNS查询主要使用UDP协议的53端口，部分大型查询也会使用TCP 53端口，如果服务器本地启用了UFW（Uncomplicated Firewall），需检查是否放行了出站流量,或者是否有规则阻止了DNS服务器的回包。
通常情况下，UFW默认允许出站连接，但如果之前有过严格的定制化安全策略，可能需要执行sudo ufw status进行检查，如果是云服务器（如阿里云ECS、腾讯云CVM），还需确认控制台的安全组设置是否限制了UDP 53端口的出站权限，虽然这种情况较少见,但在高安全级别的生产环境中不容忽视。
独立见解：选择合适的DNS策略
在解决Ubuntu ping不通域名的问题时，很多运维人员习惯直接使用8.8.8，根据笔者的运维经验，对于部署在国内的Ubuntu服务器，盲目使用Google DNS往往并非最优解，由于网络链路原因，Google DNS在国内的解析延迟较高,甚至可能出现丢包导致解析超时。
更专业的做法是采用“混合DNS策略”：主DNS优先使用运营商Local DNS或阿里云/腾讯云公共DNS，以确保解析速度和针对国内CDN节点的智能调度准确性；备用DNS再选用Google或Cloudflare（1.1.1）作为兜底，这样既能保证访问国内网站的极速响应，又能确保国际域名的解析兼容性，对于企业级应用，建议在本地搭建DNS缓存服务器（如dnsmasq或bind9），以减少外部DNS查询的频率,降低延迟并提升安全性。
相关问答模块
Q1：为什么Ubuntu服务器重启后，之前修改的/etc/resolv.conf文件会恢复原状？
A： 这是因为现代Ubuntu版本（特别是18.04及以后）默认使用systemd-resolved服务来管理DNS。/etc/resolv.conf文件通常是一个指向../run/systemd/resolve/stub-resolv.conf的软链接，每次系统重启或网络服务重启时，systemd-resolved都会根据其内部配置动态重新生成该文件，从而覆盖了手动修改的内容，要永久生效，必须修改Netplan配置文件或/etc/systemd/resolved.conf,或者将软链接指向静态文件。
Q2：能够ping通IP地址但无法解析域名，是否一定是DNS服务器的问题？
A： 不完全是，虽然90%的情况是DNS配置问题，但也有可能是系统的nscd（Name Service Cache Daemon）服务缓存了错误的解析结果，或者/etc/nsswitch.conf文件中配置的解析顺序（如hosts: files dns）有误，导致系统优先在本地hosts文件查找失败后未正确轮询到DNS，如果服务器处于严格的NAT环境后，且DNS数据包过大导致IP分片，也可能因防火墙丢弃分片包而造成解析失败,但这通常表现为间歇性故障。
希望以上方案能帮助你彻底解决Ubuntu域名解析难题，如果你在操作过程中遇到任何报错信息，或者有特定的网络环境（如公司内网），欢迎在评论区详细描述,我们将提供更具针对性的排查建议。
