resolver_timeout是规避DNS故障导致Nginx挂起的核心开关，需同时满足配置resolver、proxy_pass/upstream用域名、server显式声明resolve、DNS协议匹配；内网设2s，混合环境5s，高敏系统3s配valid=15s；须搭配upstream resolve、proxy_next_upstream及worker连接限制防雪崩。
要解决 DNS 服务器异常导致 Nginx 代理请求长时间挂起，关键不是延长等待时间，而是让 DNS 解析失败得快、切得准、缓存得当——resolver_timeout 就是控制这一跳响应速度的核心开关，但它必须和 resolver、upstream 配置协同生效。
确保 resolver_timeout 生效的必要条件
这个指令不会自动起作用，必须同时满足以下四点：
- 配置了 resolver 指令（至少一个可用的 nameserver，例如
resolver 114.114.114.114 8.8.8.8 valid=30s;） -
proxy_pass 或 upstream server 使用的是域名（如
proxy_pass http://api.example.com;），而非固定 IP - upstream 块中对应 server 显式声明 resolve（例如
server api.example.com resolve;），否则仅启动时解析一次，不触发超时控制 - DNS 协议匹配：若禁用 IPv6（
ipv6=off），而 nameserver 只响应 AAAA 查询，会导致隐式卡死
按环境设定合理的 timeout 值
设太短会误判丢包重传，设太长则拖垮并发。推荐分级配置：
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 内网 + 自建 DNS（如 CoreDNS、dnsmasq）：resolver_timeout 2s;，网络稳定，延迟通常低于 10ms
- 混合环境（含公网 DNS）：resolver_timeout 5s;，兼容 8.8.8.8 或 114.114.114.114 的偶发抖动
- 高敏系统（如支付、实时风控）：resolver_timeout 3s; 并配
valid=15s，缩短缓存提升切换灵敏度 - 避免设为 1s 或更低——公网 DNS 在丢包重传时可能超过 1s，反而引发大量无效失败
搭配 upstream 和重试机制防雪崩
单靠 resolver_timeout 无法应对后端不可达或 DNS 故障蔓延，需组合防御：
- upstream 中每个 server 都加 resolve，确保每次请求都做实时 DNS 查询
- 启用 proxy_next_upstream error timeout invalid_header http_502;，让 DNS 解析失败（返回 502）或连接超时可自动切到下一个节点
- 限制 worker 并发连接数（
worker_connections 1024;），防止个别 DNS 卡顿耗尽全部 worker 连接 - 若后端域名极少变更，可改用本地
/etc/hosts绑定，或定时脚本更新 IP 后 reload nginx，彻底绕过运行时解析
验证配置是否真正起效
改完配置后不能只信 nginx -t：
- 执行
nginx -t && nginx -s reload - 临时将 resolver 设为不可达地址（如
resolver 192.0.2.1;），观察 error.log 是否在设定的 timeout 秒后出现resolving timed out并返回 502 - 正常运行时，检查 access.log 中
$upstream_addr字段是否随 DNS 记录变更而更新，确认缓存刷新逻辑生效
