Linux 服务器上，最让人头疼的网络问题之一，是“能 ping 通 IP，但域名就是访问不了”。这种情况经常被误判成网站程序、Nginx、PHP 或数据库故障，实际源头可能只是 DNS 解析链路出了问题。DNS 看起来只是把域名转换成 IP，但在真实业务里，它会影响包管理器更新、接口回调、对象存储访问、证书签发、监控探测，甚至会让应用启动变慢。
排查 DNS 解析异常时，关键不是一上来就改配置，而是先判断问题发生在哪一层：系统解析器、DNS 服务器、网络连通性、域名本身，还是应用自己的缓存。下面按线上排障顺序，把常见命令、判断标准和安全处理方式梳理清楚。
先确认故障现象
第一步要把“访问不了”拆开看。可以先分别测试 IP 连通性和域名解析。如果直接访问 IP 正常，但访问域名失败，才更像 DNS 问题；如果 IP 也不通，那就要优先看路由、防火墙、安全组、运营商链路或目标服务状态。
常用测试可以从这几条开始：
ping -c 4 8.8.8.8
ping -c 4 example.com
curl -I https://example.com
getent hosts example.comping IP 用来确认基础网络是否通；ping 域名 可以粗略观察解析结果；curl -I 更接近真实 HTTP/HTTPS 访问；getent hosts 会走系统实际的名称解析流程，比单独看某个 DNS 工具更贴近应用侧表现。
看系统解析配置
Linux 上最常见的入口是 /etc/resolv.conf，里面通常包含 nameserver、search、options 等配置。排查时先查看当前内容，不要急着覆盖：
cat /etc/resolv.conf
ls -l /etc/resolv.conf如果 /etc/resolv.conf 是软链接，还要看它实际指向哪里。很多发行版会由 NetworkManager、systemd-resolved、云厂商初始化脚本或 DHCP 自动生成这个文件，手工改完可能很快又被覆盖。遇到“刚改好又变回去”的情况，不是服务器闹脾气，而是上游网络管理组件在接管配置。
如果服务器用于生产业务，建议记录修改前内容：
cp /etc/resolv.conf /etc/resolv.conf.bak.$(date +%F-%H%M)这个备份动作很小，但线上排障很有用。万一新 DNS 不稳定，可以快速回滚，避免把短暂解析问题扩大成全站故障。
用 dig 分层定位
dig 是排查 DNS 最常用的工具。它的价值在于可以指定 DNS 服务器、查看返回状态、观察解析耗时，还能判断问题到底出在本机解析器还是某个上游 DNS。
先看默认解析结果：
dig example.com重点关注 status、ANSWER SECTION 和 Query time。如果状态是 NOERROR 且有答案，说明解析基本成功；如果是 NXDOMAIN，通常表示域名不存在或拼写错误；如果是 SERVFAIL，可能是上游 DNS、权威 DNS、DNSSEC 或解析链路异常；如果一直超时，则要看 DNS 服务器是否可达。
再指定公共 DNS 或云厂商 DNS 对比：
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com
dig @223.5.5.5 example.com如果指定公共 DNS 能解析，而默认解析不行，问题多半在本机配置或默认 DNS 服务器；如果所有 DNS 都解析不到，要考虑域名记录、权威 DNS 或域名状态；如果某个地区 DNS 返回异常，可能是缓存未刷新、运营商递归 DNS 异常或解析线路策略不同。
检查 systemd-resolved
Ubuntu、Debian 新版本以及不少云镜像会启用 systemd-resolved。这时 /etc/resolv.conf 可能指向 127.0.0.53，表示本机 stub resolver，由 systemd-resolved 再向上游 DNS 查询。
可以这样查看状态：
systemctl status systemd-resolved --no-pager
resolvectl statusresolvectl status 会显示每个网卡使用的 DNS 服务器、搜索域和默认路由信息。如果这里显示的 DNS 与预期不一致，就要回到 netplan、NetworkManager 或云厂商网络配置中修改，而不是只改 /etc/resolv.conf。
如果只想临时验证，可以用 resolvectl query：
resolvectl query example.com它能帮助判断 systemd-resolved 自身是否能正常解析。若 dig @8.8.8.8 正常，但 resolvectl query 异常，就要重点看本机解析服务、缓存和上游 DNS 设置。
确认 DNS 服务器是否可达
DNS 通常使用 UDP 53，也可能在响应较大时回落到 TCP 53。很多人只检查了 HTTP 端口，却忘了服务器到 DNS 的出站访问也可能被防火墙、安全组或企业网关限制。
可以用这些命令做基础检查：
nc -vz 8.8.8.8 53
nc -vz 223.5.5.5 53
traceroute 8.8.8.8nc 对 UDP 的判断不如 TCP 直观，但仍可用于观察基本连通性。更实用的方式是直接用 dig @DNS服务器 域名 看是否超时。如果指定某个 DNS 一直超时，而另一个 DNS 正常，说明问题不在域名本身。
生产服务器如果经常出现 DNS 超时，除了换公共 DNS，也要考虑云厂商内网 DNS 或本地缓存 DNS。对于部署在速维云云服务器上的业务，排障时可以结合机房线路、系统镜像和安全组规则一起看，避免只盯着应用日志绕圈。
注意缓存和应用差异
DNS 排查还有一个坑：命令行解析正常，不代表应用立刻恢复。不同语言和运行时可能有自己的 DNS 缓存策略，例如 Java、Node.js、Go、PHP-FPM、Nginx upstream、容器运行时，都可能在一段时间内继续使用旧解析结果。
如果域名刚切换解析，建议同时检查 TTL：
dig example.com TTL更常用的写法是直接看普通 dig 输出中答案前面的数字，它表示剩余缓存时间。TTL 较长时，部分递归 DNS 或客户端缓存可能不会马上更新。此时频繁重启业务不一定有用，反而可能造成更多连接抖动。
如果确认 DNS 已恢复，但应用仍异常，可以按服务类型考虑重载或重启：
systemctl reload nginx
systemctl restart php-fpm这些操作在生产环境要谨慎，最好先确认服务配置无误，并安排低峰窗口。尤其是承载订单、支付、接口回调的业务，重启前要确认是否有连接保持、队列消费或定时任务正在运行。
容器环境要单独看
如果业务跑在 Docker、Kubernetes 或其他容器环境里，还要进入容器内部检查解析。宿主机 DNS 正常，不代表容器里的 /etc/resolv.conf 正常。
Docker 可以这样查看：
docker exec -it 容器名 cat /etc/resolv.conf
docker exec -it 容器名 getent hosts example.comKubernetes 则要关注 CoreDNS、Pod DNSPolicy、Service 域名和集群网络。很多“服务名解析不到”的问题，不是公网 DNS，而是集群内部 DNS 或命名空间写错。
安全修改建议
临时排障可以修改 DNS，但正式修复要找到配置源。不同系统的入口可能不同：Ubuntu 常见 netplan，CentOS 可能是 NetworkManager，云服务器可能由 DHCP 或 cloud-init 下发。正确做法是修改配置源，然后重载网络服务，而不是把 /etc/resolv.conf 当成永久配置文件。
比较稳妥的顺序是：
- 备份当前解析配置；
- 用
dig @指定DNS验证候选 DNS 是否稳定； - 确认系统使用 NetworkManager、systemd-resolved 还是静态网络配置；
- 修改真正的配置源；
- 回读
resolv.conf和resolvectl status； - 用应用真实访问目标做验证。
如果只是个人测试服务器，改错了最多影响自己；如果是企业网站、跨境业务或 API 服务，DNS 异常会直接影响收入和客户体验。选择服务器时，除了 CPU、内存和带宽，也要关注线路质量、网络策略和基础运维支持。速维云云服务器的香港、日本、美国等节点适合用来承载网站、接口服务和企业应用，但最终配置仍要按业务访问地区、解析策略和安全规则一起设计。
排查结论
Linux DNS 解析异常不要只记一条“改 nameserver”的经验。真正可靠的排查路径应该是：先区分 IP 连通性和域名解析，再检查 /etc/resolv.conf 与 systemd-resolved，随后用 dig 指定不同 DNS 做对比，最后结合防火墙、缓存、应用运行时和容器环境确认结果。
只要按层次拆开，DNS 问题通常并不神秘。怕的是在没定位清楚之前反复改配置、重启服务、切换解析，最后把一个小故障变成多层叠加问题。线上排障最重要的不是动作快，而是每一步都能证明自己离真相更近。
