这篇指南教你在一台 Linux 服务器上部署 Unbound 本地 DNS 缓存，用本地递归解析减少对外部上游 DNS 的重复请求，从而提升域名解析速度、降低上游依赖。对经常发起大量请求的建站服务器、接口服务和爬虫节点来说，一份稳定的本地缓存能明显改善首字节响应和解析抖动。
Unbound 是一款开源的递归式 DNS 服务器（递归解析器，即自己从根域逐级向下查询，并把结果暂存在本地），以安全和性能见长，适合作为本地解析缓存。它最大的价值在于：第一次查询某个域名后，结果会被保留一段时间；后续相同的查询直接命中缓存，不再向外网重复请求，既加快了响应，也减少了对外部解析服务的依赖。
搭建过程并不复杂，主要包括安装、配置监听地址与缓存参数、配置系统解析、验证生效四个步骤。我们会在后面逐节展开。
一、为什么本地 DNS 缓存能加速
每次域名解析（把域名如 example.com 转换为 IP 地址）都需要经过一次或多次查询，这一过程由 DNS（域名系统，用于将域名解析为 IP 地址的分布式服务）完成。默认情况下，Linux 系统的请求直接发给系统里配置的解析服务器（通常是机房或公共 DNS），命中与否由对方决定，本机并不保留结果。当你的站点频繁解析同一个域名时，每次都要走一遍完整的查询链路，延迟和抖动就被放大了。
Unbound 把解析结果按 TTL（生存时间，域名解析结果允许被缓存的时长）暂存在本机。第二次起，查询直接返回缓存结果，省去了网络往返。对高并发或频繁建连的服务，这通常能把解析耗时有规律地降下来。缓存同样能缓解上游解析服务波动带来的影响，比如上游某次响应变慢时，你仍能从本地缓存拿到结果。
如果你的服务器还承担多项网络功能，可以一并参考站内关于 MySQL 慢查询分析 和 Redis 持久化与恢复 的实践，把整个服务栈的性能瓶颈一起排查。
需要说明的是，Unbound 默认行为与上游解析并不冲突：它本身不依赖某个固定的公共 DNS，而是作为递归解析器直接向根服务器和各级权威服务器查询。这意味着它更少受单一上游故障影响，同时通过 DNSSEC（域名系统安全扩展，用于验证 DNS 应答真实性的机制）校验应答，能降低被中间人篡改解析结果的风险。对安全要求较高的生产环境，这是一个值得纳入考量的加分项。
缓存策略上还有一点容易被忽略：不同域名的 TTL 差别很大，静态资源往往设置较长 TTL，而动态服务或轮询类域名可能设置较短 TTL。Unbound 通过 cache-min-ttl 与 cache-max-ttl 对缓存时长做上下限约束，配合 prefetch 预取，可以在冷热波动中维持稳定的解析体验。
二、安装并配置 Unbound
安装前先确认系统版本。以下是基于 Debian/Ubuntu 的 Debian/Ubuntu 系操作步骤，CentOS/RHEL 系使用 dnf 或 yum 命令（示例：dnf install -y unbound）。先更新软件源并安装 Unbound。
apt update apt install -y unbound unbound -V | head -1
安装完成后，Unbound 的默认配置一般位于 /etc/unbound/unbound.conf。建议在安装目录中查看是否有 include 进来的额外配置文件，再决定修改哪个文件。下面我们创建一个本地解析缓存的配置片段，放在独立文件里便于管理。
# 在 /etc/unbound/unbound.conf.d/ 下新建 local-cache.conf
# 仅监听本机回环地址，限制在本地使用
server:
interface: 127.0.0.1
port: 53
do-ip6: no
do-daemonize: no
access-control: 127.0.0.0/8 allow
access-control: ::1 allow
cache-min-ttl: 300
cache-max-ttl: 86400
prefetch: yes
num-threads: 2
几个关键参数说明：interface 指定监听地址，只监听 127.0.0.1 表示仅本机可用；cache-min-ttl 与 cache-max-ttl 分别设置缓存结果的最小与最大保留秒数；prefetch 开启预取，会在缓存即将过期前提前刷新，减少过期瞬间的等待。这些数值均可按需调整（示例），实际取值应结合你的业务请求频率来定。
配置完成后重启服务并确认状态。若你同时管理多个站点的证书与端口，可参考 Certbot 证书排错 避免部署时踩到网络与证书相关的坑。
systemctl restart unbound systemctl enable unbound systemctl status unbound --no-pager
三、把系统解析指向本地缓存
要让本机的所有程序都走 Unbound，需要把系统默认解析服务器改成 127.0.0.1。最常见的方式是修改 /etc/resolv.conf，但要注意很多[云主机](https://cn.hostease.com/vps/)由 DHCP（动态主机配置协议，自动分配网络参数）或 netplan 覆盖该文件。下面给出两种做法。
做法一是直接编辑 resolv.conf。把 nameserver 改成 127.0.0.1 并保留一组上游作为回退（备用 DNS，通常写机房提供的解析地址，示例）。做法二是对使用 netplan 的系统，在 netplan 配置文件的 nameservers 段里加入 127.0.0.1，再执行 netplan apply。修改后建议重新加载网络服务，让新配置立即生效，并确认 resolv.conf 没有被云平台的初始化脚本在重启后自动覆盖。
# /etc/resolv.conf 示例 nameserver 127.0.0.1 nameserver 8.8.8.8
修改完成后用 dig 或 nslookup 验证。下面这条命令会打印实际用于查询的服务器以及查询耗时，确认 127.0.0.1 已生效。
dig @127.0.0.1 example.com # 观察 SERVER: 127.0.0.1 与 Query time
如果你的业务与反向代理、限流相关，部署本地缓存后仍要关注到站请求的治理，可以参考 Nginx 限流配置 把解析与流量控制配套做完整。
四、验证缓存命中与效果
部署是否真的加速，不能只看配置完就结束，需要通过统计来确认缓存确实在生效。Unbound 提供 unbound-control 管理接口，可查询缓存命中数、上游查询数等指标。
先把管理接口打开。在配置中加入 remote-control 段，并允许本机回环访问。
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-port: 8953
control-use-cert: no
unbound-control start unbound-control prefetch example.com unbound-control flush_zone example.com
验证思路如下：先对某个域名连续查询两次，第一次应显示较高的 Query time（冷缓存，示例约 20～80ms），第二次命中缓存后 Query time 会明显下降。接着用 unbound-control stats_noreset 查看 num.query.tcp 或缓存相关统计字段，判断命中情况。如果连续多次查询同一域名而 Query time 仍然居高不下，多半是系统解析没有真正指向本地缓存，或 Unbound 进程没有成功接管 53 端口。
unbound-control stats_noreset | grep -i cache # 输出中查看 num.cache.query 等命中相关字段
如果观察不到命中，优先检查系统解析是否真的指向了本地缓存，以及 Unbound 是否成功启动。排查思路可参考站内 Grafana 部署实践 中关于服务启动与日志定位的经验。
五、监控效果并做必要的取舍
本地缓存并非所有场景都无脑有利。它的收益取决于业务的域名请求重复率：如果请求高度集中在少数域名，命中率高、收益明显；如果大量请求都是低频甚至一次性域名，缓存收益有限，反而要付出解析器本身的开销。建议上线一周后观察命中率，再决定是否加大缓存 TTL。
Unbound 也适合与流量分析结合，帮你观察服务对外请求模式。例如把 unbound-control 的统计接入轻量监控，就能看到一段时间内哪些域名被解析得最频繁、命中率是否稳定。若你同时维护消息队列等组件，可参考 Kafka 消费积压分析，把解析、网络、消费几个环节统一定位。
还有两个常见误区需要提醒。一是不要为了”加速”而无脑把 cache-max-ttl 调得极大，过长的缓存会掩盖上游记录的真实变更，导致域名切换到新 IP 后本机仍访问旧地址；二是不要在同一台机器上同时跑多个解析缓存服务去抢 53 端口，这会引入端口冲突和配置不一致，反而增加排查成本。生产环境建议保持一套解析缓存，并做好配置的版本管理，方便回滚。
最后给出可操作建议：先备份现有解析配置，再逐节完成安装、配置、指向和验证；用连续查询的 Query time 对比确认命中，再决定是否长期启用。把本地缓存当作解析层的一项基础优化，能让你更快定位真正影响体验的瓶颈。如果你希望在一个便于管理的托管环境里做这类服务层优化，也可以考虑像 Hostease 这类提供中文支持与清晰控制台的海外主机服务，把解析、部署与日常运维放在同一套工作流中处理。