resolver + valid 能解决动态域名解析问题，因为 resolver 启用运行时 DNS 查询能力，valid 显式控制缓存 TTL（如 30s），使 Nginx 定期刷新上游 IP，避免长期指向已下线地址；若无 resolver 则仅启动时解析一次，无 valid 则依赖不可控系统默认 TTL。
当后端服务使用动态域名（如 Kubernetes Service、云厂商内网 SLB、或容器化服务发现域名）时，Nginx 默认在启动时只做一次 DNS 解析，之后长期缓存 IP 地址。若后端 IP 变更而 Nginx 未及时更新，就可能持续向已下线的旧 IP 发起请求，造成连接失败、超时或 504 错误。
为什么 resolver + valid 能解决这个问题
Nginx 的 resolver 指令启用运行时 DNS 查询能力，配合 valid 参数可控制缓存 TTL，让 Nginx 定期刷新上游地址。这不同于静态 upstream 配置，是真正支持服务发现的基础机制。
关键点：
- 没有 resolver，proxy_pass 后跟域名时，Nginx 仅在 reload 时解析一次，后续永不更新；
- 有 resolver 但没设 valid，Nginx 使用系统默认 TTL（常为 30 秒），不可控且易受 DNS 服务器影响；
- 显式设置 valid（如 5s、30s），才能确保在后端 IP 变更后，Nginx 最多等待该时间就重新查询，避免发往失效地址。
基础配置写法（HTTP 块或 Server 块内）
在 nginx.conf 的 http 或 server 上下文中添加：
resolver 114.114.114.114 8.8.8.8 valid=30s; # 或使用内网 DNS，例如：resolver 10.0.0.2 valid=10s;
然后在 location 中用域名 proxy_pass：
location /api/ {
proxy_pass http://backend-service.internal/;
# 注意：这里不能写死 IP，必须是可被 resolver 解析的域名
}
⚠️ 注意事项：
- resolver 必须在 http 或 server 级别声明，不能放在 location 内；
- valid 单位支持 s（秒）、m（分钟），推荐 10s–60s，太短增加 DNS 压力，太长导致故障恢复延迟；
- proxy_pass 域名不能带端口（如 backend:8080 ✅，backend:8080 ❌），否则 resolver 不生效；
- 若后端域名需通过内网 DNS 解析，请确保 Nginx 所在机器能访问该 DNS，并优先列出内网 DNS 地址。
配合 upstream 实现更健壮的动态代理
单纯用 proxy_pass 域名虽可行，但缺乏健康检查与负载均衡。推荐结合 upstream 和 resolver：
resolver 10.0.0.2 valid=15s;
<p>upstream dynamic_backend {
server backend-service.internal:8080 resolve; # 关键：resolve 表示启用动态解析</p><h1>不要写 weight/max_fails 等——这些由 resolve 自动管理</h1><p>}</p>
再在 location 中引用：
location /api/ {
proxy_pass http://dynamic_backend;
}
这样 Nginx 会：
- 每 15 秒主动刷新 backend-service.internal 的 A 记录；
- 自动剔除已失效的 IP（如对应 Pod 已销毁）；
- 对新返回的多个 IP 做轮询，天然支持无状态扩容。
验证与排查要点
确认配置是否生效，重点看三处日志和行为：
- 检查 error.log 是否出现 “no resolver defined to resolve” —— 说明 resolver 缺失或位置错误；
- 用
nginx -t测试语法，reload 后观察 access_log 中 upstream_addr 字段是否随时间变化（如从 10.1.2.3:8080 变为 10.1.2.4:8080）； - 模拟后端 IP 变更（如重启 Pod），用
dig backend-service.internal @10.0.0.2确认 DNS 已更新，再观察 Nginx 是否在 valid 时间内完成切换； - 若仍报 504，请排除：后端本身响应慢（查 upstream_response_time）、防火墙拦截新 IP、或 resolver 设置的 DNS 不可达（用 nslookup 测试连通性）。
