关键是要确认是否真在动态解析、resolver是否生效、解析行为是否按预期运行：查error.log中“no resolver defined”等关键词；验证resolver位置、DNS可达性、valid与timeout参数；确保proxy_pass引用变量而非字面量域名。

排查 Nginx 中 proxy_pass 动态解析域名时的 DNS 缓存失效故障，关键不是等出问题再翻日志，而是分三步定位：确认是否真在“动态解析”、验证 resolver 是否生效、检查解析行为是否按预期运行。

看 error.log 里有没有明确的 DNS 触发痕迹

打开 /var/log/nginx/error.log，重点搜这几类关键词：

• “no resolver defined”：说明用了变量（如 $arg_upstream）但没配 resolver，或 resolver 写错位置（比如塞进 location 块里）
• “resolving” 或 “could not be resolved”：表示 Nginx 确实在运行时尝试解析，但失败了——这时要查 DNS 可达性
• “host not found in upstream”：这是启动/重载阶段报的错，说明你写的是字面量域名（如 proxy_pass http://api.example.com;），根本没走动态逻辑
• “resolver timeout” 或 “getaddrinfo() failed”：前者是 DNS 服务器响应慢或不可达；后者常见于变量为空、拼错域名、或 K8s 环境下没补全 namespace（如该写 redis.default.svc.cluster.local 却只写了 redis）

验证 resolver 配置是否真正起作用

光写 resolver 8.8.8.8; 不代表就通了。要逐项核对：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• 位置必须对：resolver 必须放在 http{} 块顶层，或至少在同级 server{} 块内；不能写在 upstream、location 或 events 里
• DNS 服务器本身要通：在 Nginx 所在机器上执行 nslookup api.example.com 8.8.8.8，确认能返回 IP；若超时，换内网 DNS 或阿里 DNS（223.6.6.6）
• 加 valid 和 resolver_timeout：比如 resolver 223.6.6.6 valid=10s resolver_timeout 3s;。不设 valid，默认缓存 5 分钟，IP 变了也刷不出来
• 关 IPv6 干扰（可选）：加 ipv6=off，避免因 IPv6 查询失败拖慢整个解析流程

确认 proxy_pass 真正触发了变量解析

这是最容易踩空的一环：resolver 和变量必须同时存在、且用法正确。

• 必须用 set 定义变量，例如：set $backend "api.example.com";
• proxy_pass 必须引用该变量，写成 proxy_pass http://$backend:8080;；如果还写 proxy_pass http://api.example.com;，那 resolver 就是摆设
• 不能混用 upstream + 字面量域名：比如 upstream backend { server api.example.com; } + proxy_pass http://backend;，这种永远只在启动时解析一次
• 临时验证方法：把 resolver 指向一个不可达地址（如 resolver 192.0.2.1 valid=5s;），观察 error.log 是否出现 resolver timeout 日志——有，说明解析逻辑确实在运行时触发

快速验证 DNS 是否已按需更新

上线前就该跑通这个闭环：

• 改本地 DNS 或 hosts，让 api.example.com 返回一个新 IP
• 等 valid 时间过去（比如设了 valid=10s，就等 15 秒）
• 用 strace -p $(pgrep nginx) -e trace=connect 抓 worker 进程的连接目标，看是否连到了新 IP
• 或者直接 curl 接口，再查后端 access log，确认流量已切过去