resolver_timeout 的作用是让 nginx 在 dns 查询超时时快速放弃，避免 worker 进程阻塞和请求堆积；它必须与 resolver、valid、upstream resolve 等配合使用，仅对动态域名解析生效，不能单独解决代理延迟问题。
resolver_timeout 不能单独“解决”代理请求延迟，但它能确保 DNS 查询这一步不拖垮整个请求——它的作用是让 Nginx 在 DNS 响应慢时快速放弃，避免 worker 进程卡死、连接堆积、TTFB 拉高。真正降低延迟，需要它和 resolver、valid、upstream 配置协同工作。
必须先配好 resolver 才能让 timeout 生效
resolver_timeout 只对动态 DNS 解析起作用，而动态解析的前提是显式配置了 resolver 指令。Nginx 不读取 /etc/resolv.conf，也不用系统默认解析器。
- 写在 http 块顶层最稳妥，例如：resolver 223.5.5.5 114.114.114.114 valid=30s;
- valid=30s 是关键：它控制 DNS 结果最多缓存 30 秒，过期后才会重新查询，这是实现“动态更新”的基础
- 至少配两个 nameserver，防止单点 DNS 不可用导致全部查询失败
- 避免用 127.0.0.1 或容器内 DNS（如 127.0.0.11），它们往往转发链路长、无缓存、响应不稳定
resolver_timeout 要设得既快又稳
值太小会误判，值太大等于没设。它不是越短越好，而是要匹配你的网络环境和 DNS 服务可靠性。
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 内网 + 自建 DNS（如 dnsmasq、CoreDNS）：设为 2s，延迟低且稳定
- 混合环境（部分走公网 DNS）：设为 4–5s，兼容 8.8.8.8 或 114.114.114.114 的偶发抖动
- 对故障切换敏感的系统：设为 3s，再配合 valid=15s 缩短缓存时间，提升响应灵敏度
- 绝不建议设为 1s 或更低——UDP 丢包重传或 ECS 查询都可能超过 1s，反而引发大量无效 502
proxy_pass 必须触发动态解析，否则 timeout 形同虚设
直接写 proxy_pass http://api.example.com; 是启动时静态解析一次，后续永远用旧 IP，resolver 和 timeout 全部不生效。
- 正确做法是用变量：在 location 中加 set $backend "api.example.com:8000";，再写 proxy_pass http://$backend;
- 或者用 upstream + resolve（Nginx ≥ 1.19.0）：upstream backend { server api.example.com:8080 resolve valid=20s; }
- 注意：变量方式需手动补 Host 头，例如 proxy_set_header Host api.example.com;，否则某些后端会路由失败
配合其他配置才能真正压低延迟
DNS 解析只是回源的第一步。光靠 resolver_timeout 无法解决整体延迟，还需组合优化：
- 启用 upstream keepalive，复用已解析 IP 的 TCP 连接，避免每次回源都握手+slow-start
- 加 proxy_next_upstream error timeout invalid_header http_502;，让 DNS 失败（返回 502）也能自动切到下一个节点
- 限制 worker_connections 1024;，防止个别 DNS 卡顿耗尽所有 worker 连接，引发雪崩
- 若后端域名极少变更，可改用 /etc/hosts 绑定或定时脚本更新 IP 后 reload nginx，彻底绕过运行时解析
