resolver_timeout 的作用是主动放弃卡住的 dns 查询，释放 worker 连接，避免单个慢查询拖垮整台机器；它必须与全局 resolver 指令和变量式 proxy_pass 配合才生效，单独设置无效。
要解决 Nginx 反向代理外部域名时因 DNS 解析慢引发的请求延迟，关键不是延长等待时间，而是让解析失败得快、切得准——resolver_timeout 的作用是主动放弃卡住的 DNS 查询，释放 worker 连接，避免单个慢查询拖垮整台机器。它必须和 resolver、变量式 proxy_pass 配合才生效，单独设置无效。
确保 resolver_timeout 起作用的前提
这个指令只在以下条件全部满足时才真正介入：
- 全局 http 块中已配置
resolver（例如resolver 8.8.8.8 114.114.114.114 valid=30s;），Nginx 不读取系统 /etc/resolv.conf -
proxy_pass使用变量形式（如set $upstream "api.example.com"; proxy_pass http://$upstream;），硬写域名会跳过运行时解析 - 目标是外部域名（非固定 IP），且该域名需实际发起 DNS 查询（例如未被本地 hosts 覆盖）
- 未启用 IPv6 或 DNS 服务器支持所用协议，否则可能隐式卡在协议协商阶段
合理设置 timeout 值（针对外部域名）
外部 DNS 延迟波动大，超时值需兼顾稳定性与响应速度：
- 纯公网环境（如调用第三方 API）：设为
resolver_timeout 5s;，能覆盖 95% 的 8.8.8.8/114.114.114.114 响应，又不至于频繁误判 - 混合网络（部分请求走内网 DNS，部分走公网）：仍建议统一设为
5s，并配多个 nameserver 提升可用性 - 避免设为 1–2s：公网 DNS 在丢包重传或跨洲际路由时，偶发超过 2s 很常见，容易引发大量 502
- 严禁设为 30s 或更高：一个卡住的 DNS 查询会让整个 worker 连接挂起，快速耗尽
worker_connections
必须搭配的三项关键配置
仅调 resolver_timeout 无法根治延迟问题，需组合防御：
-
强制每次请求都查 DNS：在
upstream中使用server api.example.com resolve valid=15s;（Nginx ≥ 1.19.0），或坚持用变量 +proxy_pass模式 -
自动故障转移：启用
proxy_next_upstream error timeout http_502;，DNS 解析失败返回 502 时可立即切到备用 upstream 或返回兜底响应 -
限制连接雪崩：通过
worker_connections 1024;和keepalive_timeout 15s;控制并发压力，防止 DNS 卡顿引发连接堆积
验证是否真正生效
别只信配置语法正确，要看运行时行为：
- 执行
nginx -t && nginx -s reload后，观察/var/log/nginx/error.log是否出现resolving "api.example.com"日志 - 临时把
resolver改成一个不可达地址（如resolver 192.0.2.1;），看是否在设定的 timeout 秒后准确报出resolving timed out - 修改目标域名的 DNS 解析结果（比如指向一个新 IP），等超过
valid时间后发起请求，用ss -tnp | grep :80确认 Nginx 实际连接的目标 IP 是否已更新
