核心是让 Nginx 主动、及时、可靠地解析上游域名，避免卡在 DNS 查询上导致 502、超时或流量打到已下线节点；需在 http 块顶层显式配置 resolver（如 resolver 114.114.114.114 8.8.8.8 valid=5s;），配合变量 proxy_pass 和 resolver_timeout 3s 实现动态解析与快速失败。
核心是让 Nginx 主动、及时、可靠地解析上游域名，避免卡在 DNS 查询上导致 502、超时或流量打到已下线节点。静态写死域名或依赖系统默认解析，都会放大延迟风险。
显式配置 resolver 并设合理缓存时效
必须在 http 块顶层声明 resolver，Nginx 不读取 /etc/resolv.conf，也不支持 server 或 location 级配置：
- 指定至少两个稳定 DNS（如 114.114.114.114 8.8.8.8），主挂时自动切备选
- 加 valid=5s–30s：短缓存适配云服务扩缩容；TTL 短于上游 DNS 记录值才真正生效
- 避免只写一个地址，也别用不可靠的内网 DNS（如未部署本地缓存）
强制每次请求动态解析（而非启动时查一次）
直接写 proxy_pass http://api.example.com 是静态解析——Nginx 启动时查一次就固定 IP，后续永不更新：
- 改用变量方式：
set $backend "api.example.com"; proxy_pass http://$backend; - 确保
proxy_pass后不带路径（如不能写http://$backend/），否则变量失效 - 若必须用 upstream，需启用
resolve参数（如server api.example.com resolve;），且 Nginx ≥ 1.19.0
控制 DNS 查询失败节奏，不拖垮 worker
resolver_timeout 不是“等更久”，而是“快失败、早切换”：
- 公网环境建议设为 3–5s：覆盖 95% 的公共 DNS 响应，又防偶发抖动误判
- 内网 DNS（如 dnsmasq）可设为 2s，响应稳、延迟低
- 严禁设为 10s+：一个卡住的查询会让整个 worker 连接挂起，高并发下迅速雪崩
- 必须配合
proxy_next_upstream error timeout http_502，DNS 失败时立即重试或降级
降低 DNS 查询压力的实用补充
光调参数不够，还要减少实际查询次数：
- 部署本地 DNS 缓存（如 dnsmasq 或 CoreDNS），Nginx 的 resolver 指向
127.0.0.1:53，利用其 TTL 缓存和重试逻辑 - 关键外部服务，DNS 记录 TTL 建议设为 60–300 秒，太短增加查询压力，太长影响故障收敛
- 禁用 IPv6 查询（加
ipv6=off），避免 AAAA 查询无响应拖慢整体解析 - 对固定不变的后端，直接写 IP 地址，彻底绕过运行时 DNS 解析
