关键在于proxy_pass带路径时是否触发运行时dns解析：变量+路径写法（如http://$backend$request_uri）可动态解析，字面量或错误拼接则退化为启动期静态解析，导致502或启动失败；resolver须与proxy_pass同级配置，且需日志和连接验证解析行为。
排查 proxy_pass 带路径时的域名解析问题，关键不是“语法是否通过”，而是看它是否触发了运行时 DNS 解析——因为带路径的写法极易无意中禁用变量机制，导致 Nginx 退回到启动期静态解析，进而引发 502 或启动失败。
先确认 proxy_pass 是否真用了变量
带路径的 proxy_pass 容易写成字面量形式，看似有路径，实则丧失动态能力：
- ✅ 正确（变量 + 路径保留）：
set $backend "api.example.com"; proxy_pass http://$backend$request_uri; - ✅ 正确（变量 + 固定路径）：
set $backend "api.example.com"; proxy_pass http://$backend/v1/;（注意结尾斜杠含义） - ❌ 错误（字面量 + 路径）：
proxy_pass http://api.example.com/v1/;—— 启动时强制解析，不支持动态 - ❌ 错误（变量但路径硬拼错）：
set $backend "api.example.com/v1"; proxy_pass http://$backend;—— 后端收到重复路径如/v1/v1，可能 404
检查 resolver 是否在有效作用域内
resolver 必须和 proxy_pass 在同一配置块（location 或 server），且不能只放在 http 全局块（旧版不认，新版也易失效）：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 推荐写法：在
location内直接配，例如：resolver 114.114.114.114 valid=30s; - 避免写法：
http { resolver ...; }+location { proxy_pass http://$backend; }—— 变量解析会失败 - 若用
map动态选域名，resolver仍需落在引用该变量的location块里
验证是否真的在运行时解析
光看 nginx -t 通过没用，要观察真实行为：
- 重启后查
/var/log/nginx/error.log，应出现resolving "api.example.com"和后续resolved to 10.1.2.3日志 - 用
ss -tnp | grep :8080查看 worker 进程连接的目标 IP，手动更新后端地址（如重启容器），等 30 秒后发请求，确认连接 IP 是否变化 - 若日志只有一次
resolved to且长期不变，说明valid=30s未生效，大概率是resolver位置错了或变量没用对
带路径时的 Host 和路径处理别漏掉
用变量后，Nginx 不再自动设置 Host 头，路径转发逻辑也变敏感：
- 显式补上：
proxy_set_header Host api.example.com;（否则后端可能拒收或路由错） - 末尾斜杠决定路径剥离行为：
proxy_pass http://$backend/;会去掉匹配前缀，proxy_pass http://$backend;则原样透传 - 需要改写路径时，优先用
rewrite预处理，再让proxy_pass无路径调用，避免拼接出错
