“域名无法解析”？服务器端DNS故障排查终极指南：从dig/nslookup到系统resolv.conf配置
更多云服务器知识，尽在hostol.com
在我们的服务器运维生涯中，总有那么一些错误信息，它的出现，几乎能瞬间让你的所有网络服务陷入瘫痪。它不是“502 Bad Gateway”那种后端应用的“小情绪”，也不是“404 Not Found”那样的资源路径问题，而是更底层、更根本的“失联”——“域名无法解析”（Could not resolve host）。当你满怀信心地在服务器上执行apt update，却看到它卡在“无法解析 'archive.ubuntu.com'”；或者你的应用程序尝试连接数据库或第三方API，却无情地抛出“Unknown Host”异常时，你就会意识到，你的服务器，这位平时能与全世界自由通信的“网络公民”，突然变成了一个“睁眼瞎”，不认识回家的路了。它知道要去“谷歌大厦”，却不知道“谷歌大厦”的具体门牌号。这种“失联”的根源，往往就出在DNS（Domain Name System，域名系统）解析上。今天，Hostol就来为你奉上一份服务器端的DNS故障排查终极指南，带你化身“网络侦探”，从<code>dig</code>和<code>nslookup</code>这两大神器入手，层层深入，直到揪出问题的真正“元凶”，让你的服务器重见光明。
万病之源：理解服务器的DNS解析流程
在动手排查之前，我们得先搞清楚一个问题：当你的服务器上的一个程序（比如curl或你的应用）想要访问<code>www.example.com</code>时，它到底是怎么知道这个域名对应的IP地址的？这个过程，就是DNS解析。
DNS解析的“四步走”简易模型
这个过程，我们可以把它想象成一个“问路”的场景。
- 应用发起请求：你的程序（比如<code>curl</code>）想去“Example公司大楼”（<code>www.example.com</code>），但它只知道名字，不知道地址。
- 求助“操作系统”这位总机：程序会向操作系统的网络库（通常是glibc的解析器）发起一个“问路”请求：“嘿，总机，帮我查查‘Example公司大楼’的地址！”
- 总机查阅“通讯录”：操作系统总机会翻开一本至关重要的“内部通讯录”——那就是<code>/etc/resolv.conf</code>文件。
- 联系“信息中心”：这本“通讯录”里记录了它应该去咨询哪个“信息中心”（DNS服务器）的电话号码。于是，操作系统就向这个DNS服务器发起查询，最终获取到“Example公司大楼”的IP地址，然后告诉你的程序。
所以，你看，整个流程中，<code>/etc/resolv.conf</code>文件和它指向的DNS服务器，是决定你的服务器能否成功“问路”的关键。
关键的“通讯录”：<code>/etc/resolv.conf</code>文件详解
让我们先来看看这本“通讯录”里通常都写了些什么。你可以用<code>cat /etc/resolv.conf</code>命令查看它的内容，它可能长这样：
# Generated by systemd-resolved
nameserver 127.0.0.53
options edns0 trust-ad
search localdomain
或者这样：
nameserver 8.8.8.8
nameserver 8.8.4.4
这里面的关键指令是：
nameserver IP地址: 这就是你服务器的“DNS信息中心”地址。可以配置多个，当第一个查询失败时，会尝试下一个。常见的公共DNS有谷歌的8.8.8.8和8.8.4.4，Cloudflare的1.1.1.1，或国内的114.114.114.114。search 域名: 定义了搜索域。比如你查询一个不带点的主机名myserver，系统会尝试把它和你设置的搜索域组合起来查询，比如myserver.localdomain。options 选项: 定义一些解析器的行为，比如超时时间、尝试次数等。
如果这个文件不存在、内容为空，或者里面nameserver的IP地址是错的、无法访问的，那你的服务器自然就“瞎”了。
成为“DNS侦探”：两大神器的入门与实战
要排查DNS问题，光看配置文件是远远不够的，我们得有专业的“侦测工具”。在Linux世界里，<code>dig</code>和<code>nslookup</code>就是我们最重要的两件法宝。
dig命令：DNS排错的“瑞士军刀”
dig (Domain Information Groper) 是一个功能极其强大、信息输出极其丰富的DNS查询工具，是专业运维人员的首选。
基础用法与输出解读
最简单的用法就是直接跟上你要查询的域名：
Bash
dig www.example.com
它的输出信息非常详细，我们挑重点看：
QUESTION SECTION: 显示你查询的问题是什么，这里是查询<code>www.example.com</code>的A记录。ANSWER SECTION: 这是最重要的“答案区”！它会告诉你查询的结果。比如，<code>www.example.com. 3600 IN A 93.184.216.34</code>，这表示<code>www.example.com</code>的A记录（IPv4地址）是<code>93.184.216.34</code>，并且这个记录的TTL（缓存时间）是3600秒。Query time: 这次查询花了多长时间。SERVER: 这次查询是通过哪个DNS服务器完成的（默认是你<code>/etc/resolv.conf</code>里配置的那个）。STATUS: 查询的状态。NOERROR表示成功。如果是NXDOMAIN，则表示域名不存在。
实战dig命令
- 查询特定记录类型：
dig www.example.com MX(查询邮件交换记录),dig example.com NS(查询权威名称服务器记录),dig www.example.com CNAME(查询别名记录)。 - 指定DNS服务器查询：这是排查问题的关键技巧！它可以绕过你服务器本地的解析器设置，直接向一个指定的DNS服务器（比如谷歌的
8.8.8.8）发起查询，从而判断问题是出在本地配置还是DNS服务器本身。 Bashdig @8.8.8.8 www.example.com - 追踪完整的解析路径：使用<code>+trace</code>参数，<code>dig</code>会模拟一次从根域名服务器（.）开始，一步步向下查询的完整递归过程。这对于诊断域名授权、 delegation等更深层次的问题非常有用。 Bash
dig +trace www.example.com
nslookup命令：快速便捷的“常用手电筒”
nslookup是另一个DNS查询工具，比dig更老一些，输出也更简洁，适合做一些快速的查询验证。
基础用法
Bash
nslookup www.example.com
它会直接返回域名对应的IP地址。
交互模式
直接输入nslookup回车，会进入一个交互模式。在这里你可以设置要查询的DNS服务器（server 8.8.8.8），然后直接输入域名进行查询，很方便。
对于复杂的排错，我们更推荐使用信息量更大的<code>dig</code>。
按图索骥：系统化的服务器端DNS故障排查流程
好了，工具在手，我们来建立一套系统化的“破案”流程。当你遇到“域名无法解析”的问题时，请按照以下步骤一步步排查：
-
确认问题范围：是“全瞎”还是“个别失明”？ 首先，判断是所有域名都无法解析，还是只有个别域名不行。
Bashping baidu.com # 尝试ping一个肯定没问题的公网域名 ping your-specific-domain.com # 尝试ping你出问题的那个域名如果连
baidu.com都ping不通（或无法解析），那很可能是你服务器的DNS配置或网络出口有问题。如果只有特定域名不行，那可能是那个域名本身的问题，或者是针对那个域名的特殊网络策略。 -
检查本地“通讯录”配置 (<code>/etc/resolv.conf</code>)： 执行<code>cat /etc/resolv.conf</code>，检查：
nameserver指令是否存在？- 后面的IP地址是否正确？是不是一个可达的DNS服务器地址？你可以尝试<code>ping</code>一下这个IP。
- 注意： 很多现代Linux发行版（如Ubuntu 18.04+）使用<code>systemd-resolved</code>服务来管理DNS。这时你可能会看到<code>/etc/resolv.conf</code>里的<code>nameserver</code>指向了<code>127.0.0.53</code>。这是正常的，表示所有查询都先交给本地的<code>systemd-resolved</code>服务处理。这时你需要用<code>resolvectl status</code>命令来查看它实际上游的DNS服务器是哪些。
-
绕过本地配置，直接“拷问”DNS服务器： 使用我们前面学到的<code>dig @</code>语法，绕过本地<code>/etc/resolv.conf</code>的设置，直接向一个已知的、可靠的公共DNS服务器发起查询。
Bashdig @8.8.8.8 www.example.com- 如果这条命令成功返回了正确的IP地址，而直接<code>dig www.example.com</code>失败了，那么问题几乎可以100%确定出在你服务器本地的DNS配置上（也就是<code>/etc/resolv.conf</code>指向的那个DNS服务器有问题，或者<code>systemd-resolved</code>服务配置有问题）。
- 如果这条命令也失败了，那问题可能更严重，比如你服务器的出站网络有问题。
-
检查防火墙规则 DNS查询主要使用UDP 53端口，当响应包过大时会切换到TCP 53端口。你需要检查你的服务器防火墙（包括云平台的<a href="/blog/cloud-firewall-security-group-guide/">云防火墙（安全组）</a>和操作系统内部的<code>iptables</code>/<code>firewalld</code>）是否允许出站到目标DNS服务器的UDP/TCP 53端口的流量。
-
对于使用<code>systemd-resolved</code>的系统，检查其服务状态：
Bashsystemctl status systemd-resolved确保它是<code>active (running)</code>状态。并用<code>resolvectl status</code>查看其配置和统计信息。
-
使用<code>dig +trace</code>进行“终极诊断”： 如果问题只针对某个特定域名，并且你怀疑是该域名自身的DNS设置问题，那么<code>dig +trace https://www.google.com/url?sa=E&source=gmail&q=your-problematic-domain.com</code>就是你的“杀手锏”。它会告诉你从根服务器到顶级域服务器，再到权威域名服务器，整个查询链条的每一步。如果中间哪一步出错了，会一目了然。
常见问题解答 (FAQ)
问：我应该在<code>/etc/resolv.conf</code>里设置哪些DNS服务器？ 答：你可以选择：
- 公共DNS：如谷歌的
8.8.8.8,8.8.4.4，Cloudflare的1.1.1.1，或国内的114.114.114.114。它们通常稳定、快速。 - 云服务商提供的内网DNS：如果你使用的是云服务器，你的服务商通常会提供一个内网DNS地址。使用它查询云服务商内部的其他服务域名通常速度最快，也更可靠。
- 通常建议至少配置两个DNS服务器作为冗余。
问：为什么我的<code>/etc/resolv.conf</code>文件每次重启都会被重置？ 答：这很可能是因为你的网络是由NetworkManager或<code>systemd-networkd</code>这类网络管理服务控制的。它们会根据自己的配置文件动态生成<code>/etc/resolv.conf</code>。你不能直接修改这个文件，而应该去修改对应网络管理服务的配置文件（比如NetworkManager的连接配置，或者<code>systemd-networkd</code>的.network文件），在那里指定你的DNS服务器。
问：DNS查询用TCP还是UDP？ 答：绝大多数情况（超过99%）下，DNS查询使用UDP 53端口，因为它更轻量、更快。但当DNS响应包的大小超过512字节（对于支持EDNS0的现代DNS则更大），或者进行区域传输（AXFR）等特殊操作时，会自动切换到TCP 53端口来保证数据传输的完整性和可靠性。所以，防火墙最好同时放行UDP和TCP的53端口出站。
问：什么是DNS缓存？我需要手动清除它吗？ 答：为了提高效率，操作系统、应用程序甚至你的本地路由器都会对DNS查询结果进行缓存。这意味着第二次查询同一个域名时，可能直接从缓存获取结果而无需再次向外请求。这通常是好事，但有时也可能因为缓存了旧的、错误的记录而导致问题。在Linux服务器上，如果使用<code>systemd-resolved</code>，它自带缓存功能，可以用<code>sudo resolvectl flush-caches</code>来清除。其他应用（如nscd）也可能有自己的缓存。
当你为你的业务<a href="/products/cloud-server/">选择合适的服务器</a>后，确保其网络配置畅通无阻是至关重要的第一步。如果DNS解析的“任督二脉”没有打通，那么再强大的服务器也只是一个信息孤岛。如果你在排查DNS或其他服务器问题时遇到了困难，随时可以<a href="/contact/">联系我们</a>寻求专业的帮助。
DNS故障排查的过程，就像是解开一个复杂的线团，需要耐心和清晰的思路。但只要你掌握了今天我们聊到的这套从宏观到微观、从本地到远程的排查流程，并学会善用<code>dig</code>这样的强大工具，那么下一次当你再遇到那句令人心烦的“域名无法解析”时，你就能从容不迫地定位问题，让你的服务器重新与这个精彩纷呈的网络世界紧密“连接”起来。