resolver_timeout用于控制Nginx单次DNS查询等待上限，仅对动态域名解析生效；需配合resolver指令及resolve关键字使用，合理设为3–5秒并结合valid、proxy_next_upstream等参数协同优化。
调优 resolver_timeout 能有效缓解反向代理外部域名时因 DNS 解析超时导致的首字节延迟（TTFB 增高），但关键不在于一味调大，而在于匹配实际网络环境与上游 DNS 服务的响应能力。
理解 resolver_timeout 的作用范围
该参数仅影响 Nginx 使用 resolver 指令配置的 DNS 解析器在解析变量化域名（如 proxy_pass http://$host）时的单次查询等待上限，并不控制缓存有效期或连接复用。它不作用于静态写死的域名（如 proxy_pass http://api.example.com），后者由系统默认解析机制处理，不受此参数约束。
确认是否真由 resolver_timeout 触发超时
开启 Nginx 错误日志的 debug 级别（需编译时启用 --with-debug），观察是否有类似以下日志：
"resolving timeout ... while connecting to upstream"
同时用 dig +stats example.com @8.8.8.8 或 nslookup -debug example.com 1.1.1.1 实测目标 DNS 服务器的真实响应时间。若多数查询在 200ms 内完成，却频繁触发 5s 默认超时，则说明存在丢包、路由异常或 DNS 服务器过载，而非参数设置过小。
合理设置 resolver_timeout 值
建议按如下方式调整：
- 基础值设为 3–5 秒：覆盖绝大多数公共 DNS（如 1.1.1.1、8.8.8.8）在正常网络下的 P95 响应时延
- 若使用内网 DNS（如 CoreDNS、dnsmasq），且已确认其平均响应 1 秒，加快失败感知
- 避免设为 10s+：过长等待会阻塞 worker 进程，放大并发下的延迟毛刺；Nginx 不支持 per-upstream 的 timeout，全局生效需谨慎
- 配合
resolver的 valid 参数使用，例如：resolver 1.1.1.1 8.8.8.8 valid=30s;resolver_timeout 3s;
比调参更有效的替代方案
单纯调大 resolver_timeout 是治标。更推荐以下实践：
- 静态 proxy_pass：对固定上游域名，直接写死地址，彻底规避运行时解析
-
预解析 + 变量 fallback：用
map预先映射域名到 IP，配合resolver作兜底，降低实时解析频次 -
部署本地缓存 DNS：如 dnsmasq 或 CoreDNS，将
resolver指向 127.0.0.1:53，利用其内置缓存和重试逻辑，显著降低超时概率 -
启用 IPv6 回退控制：若上游仅支持 IPv4，在
resolver后加ipv6=off，避免 AAAA 查询拖慢整体解析流程
