Nginx中proxy_pass写死域名仅启动时解析DNS，加resolver不生效是因为必须配合变量使用（如set $upstream "x.com"; proxy_pass http://$upstream;），resolver才触发动态解析；推荐1.19.9+的upstream resolve方案。
proxy_pass 写死域名（如 proxy_pass https://api.example.com;）永远只在 Nginx 启动或重载时解析一次 DNS，后续所有请求都发往缓存下来的 IP——哪怕后端已扩容、切流、下线，Nginx 也完全无感。这是生产环境 502/连接超时最隐蔽却最高频的根源。
为什么加了 resolver 还是不生效？
常见错误是：配置了 resolver 8.8.8.8 valid=10s;，但 proxy_pass 仍直接写域名。根本原因在于——resolver 指令本身只是“备好了解析器”，而 Nginx 默认对字面量域名（如 https://api.example.com）压根不会调用它，而是走启动时的静态 getaddrinfo() 路径。
真正触发 resolver 的唯一方式是：proxy_pass 的值必须是一个变量。哪怕只是简单赋值：
set $upstream "api.example.com";proxy_pass https://$upstream;
只有这时，Nginx 才会在每次新建连接（或缓存过期后）调用 resolver 指定的 DNS 服务器去查记录。变量是开关，resolver 是工具，缺一不可。
resolver 必须和变量同级作用域
把 resolver 写在 http 块顶层，但在 location 里用变量，旧版 Nginx（location 或 server 块内：
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
location /api/ {
resolver 114.114.114.114 8.8.8.8 valid=15s;
set $backend "api.example.com";
proxy_pass https://$backend;
}
valid 不是照搬 DNS TTL，而是你给 Nginx 缓存结果设定的“保质期”：
- 设为
15s：最多 15 秒后下次请求会重新查 DNS - 设为
300s：几乎退化成静态解析 - 云服务扩缩容、CDN 回源切流等场景，建议
10–30s - 内网稳定服务可放宽至
60s
更稳的方案：upstream + resolve
Nginx 1.19.9+ 原生支持 resolve 参数，这才是面向生产环境的推荐写法：
http {
resolver 1.1.1.1 valid=10s;
upstream origin_backend {
server origin.example.com:443 resolve;
keepalive 32;
}
}
location /origin/ {
proxy_pass https://origin_backend;
}
这个组合的好处是：
- 按
valid时间自动轮询 DNS，无需变量绕路 - 支持 SRV 记录和多 A/AAAA 记录负载均衡
- 自动剔除失效 IP（配合健康检查更佳）
- 协议匹配更明确（HTTPS 回源需注意 SSL 配置）
验证是否真的动态解析了
不能只看配置有没有写，得看运行时行为：
- 查
error.log：搜索resolving、could not be resolved、no resolver defined等关键词 - 抓连接目标：
ss -tnp | grep :443或lsof -i :443，观察实际连接的 IP 是否随 DNS 变更而切换 - 临时将 DNS TTL 设为 5 秒，在变更 IP 后，观察 Nginx 是否在
valid时间内完成切换 - 避免用
strace抓connect()：它看到的是 TCP 层目标 IP，但无法区分是 DNS 解析结果还是连接复用缓存
最容易被忽略的一点：即使用了变量 + resolver，如果 DNS 服务器本身不可达、UDP 53 端口被防火墙拦截，Nginx 会 fallback 到旧缓存甚至静默失败——务必确保 resolver 指向的 DNS 服务真实可用且低延迟。
