NGINX正则匹配ProxyPass与Resolver配置失效问题排查

问题原因解析 #

1. 未配置resolver时的报错原因 #

当proxy_pass使用变量（如${context}、${path}）拼接目标地址时，NGINX无法提前解析域名（哪怕是localhost），必须显式指定resolver来动态解析域名，因此会抛出no resolver defined to resolve localhost错误。

2. 配置resolver后连接拒绝的原因 #

配置resolver 127.0.0.1后报错Connection refused，是因为NGINX默认用53端口做DNS解析，但你的环境（比如Docker容器）里本地DNS服务（127.0.0.1:53）并未运行，导致解析请求被拒绝。

3. 预期返回main.html却得到502的原因 #

正则location规则~ /(first-context|second-context)/custom-path/(.*)$的匹配优先级高于前缀location/first-context/test，访问/first-context/custom-path/test时会先命中正则location进入代理逻辑，而非触发返回main.html的规则，最终因代理失败返回502。

修复方案 #

方案一：调整location优先级，优先返回main.html #

如果核心需求是让目标URL返回main.html，可以给前缀location添加^~修饰符，让它的匹配优先级高于所有正则location：

location ^~ /first-context/custom-path/test {
    try_files /main.html =404;
}

location ~ /(first-context|second-context)/custom-path/(.*)$ {
    # 保留原代理逻辑（若其他路径需走代理）
    resolver 8.8.8.8;
    set $context $1;
    set $path $2;
    proxy_pass http://localhost:80/${context}/${path};
}

方案二：修复resolver配置，让代理逻辑正常运行 #

若需要保留代理逻辑，解决resolver报错：

• 使用公共DNS服务替代本地DNS，比如resolver 8.8.8.8;（谷歌公共DNS）或resolver 1.1.1.1;（Cloudflare DNS），避开本地53端口未运行的问题。
• 若在Docker容器中运行NGINX，可使用Docker内置DNS：resolver 127.0.0.11;

修改后的正则location配置：

location ~ /(first-context|second-context)/custom-path/(.*)$ {
    resolver 8.8.8.8;
    set $context $1;
    set $path $2;
    proxy_pass http://localhost:80/${context}/${path};
}

方案三：避免变量拼接，直接用正则捕获配置proxy_pass #

如果代理目标地址可通过正则捕获直接实现，无需变量拼接，这种写法不需要resolver：

location ~ ^/(first-context|second-context)/custom-path/(.*)$ {
    proxy_pass http://localhost:80/$1/$2;
}

内容的提问来源于stack exchange，提问作者vsfer