Nginx反向代理使用变量拼接上游地址后，日志出现no resolver defined to resolve，往往不是上游服务宕机，而是配置从启动时解析变成了请求阶段解析。
先确认proxy_pass是否含变量，再补充适合当前网络的resolver，不要把任意公共DNS直接写进内网生产环境。
先定位是哪条代理规则触发
执行nginx -T导出完整配置，搜索报错中的域名和proxy_pass。固定域名可在配置加载时解析；当地址含变量，Nginx需要在请求阶段解析，未配置resolver就会报错。
resolver应该写在哪个作用域
resolver可放在http、server或location作用域。示例为resolver 10.0.0.2 valid=30s;，地址应换成云网络或系统实际可达的DNS。内网服务名必须使用能够解析该私有域的服务器，并确认解析器从Nginx主机实际可达。
怎样处理IPv6与缓存时间
网络没有可用IPv6路径时，可按版本支持情况设置ipv6=off，避免得到不可达地址。valid控制解析结果缓存期，过长会延迟上游地址切换，过短会增加DNS压力，应结合服务发现的TTL确定。
修改前先检查哪些风险
解析器会接收运行时域名查询，需选择可信地址并限制网络访问。不要把用户输入未经校验地拼进proxy_pass，否则可能扩大服务端请求伪造风险。resolver解决的是解析能力，不等于上游地址可信。
加载与验收步骤
先运行nginx -t，通过后再平滑执行nginx -s reload。连续请求目标接口并查看错误日志，确认不再出现resolver错误，同时核对状态码、TLS域名和Host请求头。
云服务器上的配置建议
跨地区部署时先记录每个网络的DNS地址。可在萤光云或LightNode的测试实例复核解析与回源链路；不要把测试DNS配置直接复制到不同私网。
FAQ
问：系统里dig能解析，Nginx为何还报错？答：含变量的proxy_pass需要Nginx自己的resolver指令，系统命令解析成功不能替代请求阶段配置。
温馨提示
温馨提示：修改DNS和代理规则前保存当前配置，保留一个已验证的回滚版本，并在低流量时段平滑加载。
