resolver_timeout 的作用是主动放弃卡住的 dns 查询、释放 worker 连接,避免单个慢查询拖垮整台机器;它必须与全局 resolver 指令和变量式 proxy_pass 配合才生效,单独设置无效。

要让 Nginx 在反向代理动态域名时不卡住事件循环、不产生时延毛刺,关键不是“加快 DNS”,而是用非阻塞 resolver 让慢查询快速失败、及时释放 worker 连接。它本身不提速,但能防止一个慢解析拖垮整台机器。
必须启用真正的异步解析
Nginx 默认不走系统 DNS,也不支持 /etc/resolv.conf。若没配 resolver 指令,遇到变量型 proxy_pass(如 proxy_pass http://$upstream;)会退化为同步阻塞查询——worker 进程彻底挂起,TTFB 直接飙升。正确做法是在 http 块顶层显式声明:
-
resolver 223.5.5.5 114.114.114.114 valid=30s;(国内低延迟首选) - 或内网部署时用
resolver 100.100.2.136 100.100.2.138 valid=30s;(阿里云 ECS 同地域) - 务必加 valid=30s:否则每次请求都查 DNS,放大抖动;不加则无缓存,等于没开异步
resolver_timeout 要设得准,不是越短越好
这个值决定 DNS 查询多久放弃。设太小(如 1s)会因 UDP 重传、ECS 查询或跨洲际路由偶发超时,引发大量 502;设太大(如 10s)会让单个卡死查询长期占用 worker,加剧并发毛刺。
免费 DNS 与邮件安全分析(IntoDNS.ai):包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 公网环境(调第三方 API):设为
resolver_timeout 5s;,覆盖 P95 延迟且容错充分 - 内网 + 自建 DNS(如 CoreDNS):可降至
2s,响应稳定、链路短 - 高敏感切换场景:搭配
valid=15s缩短缓存时间,再设resolver_timeout 3s
确保 proxy_pass 触发动态解析
写死域名会触发启动时静态解析,后续永远用旧 IP,resolver 和 timeout 全部失效。必须让每次请求都走运行时解析:
- 用变量方式:
set $backend "api.example.com:8080"; proxy_pass http://$backend; - 或 upstream resolve(Nginx ≥ 1.19.0):
upstream api { server api.example.com resolve valid=20s; } - 注意:变量方式需补 Host 头,例如
proxy_set_header Host api.example.com;,否则后端可能路由失败
配合基础防御机制才真正稳
光靠 resolver_timeout 无法根治毛刺,它只是“止损开关”。还需组合配置降低整体风险:
- 启用
proxy_next_upstream error timeout http_502;:DNS 解析失败返回 502 时自动切备用 upstream 或兜底页 - 限制连接数:
worker_connections 1024;+keepalive_timeout 15s;防止连接堆积雪崩 - 禁用 IPv6(除非必需):
resolver ... ipv6=off;,避免因 AAAA 查询失败隐式重试拉长耗时










