proxy_pass 不决定匹配优先级，真正起作用的是 location 的四层匹配规则：精确匹配（=）、前缀优先（^~）、正则匹配（~或~*，从上到下）、最长普通前缀；其路径拼接逻辑取决于 proxy_pass 是否带尾部 /。
proxy_pass 本身不参与匹配优先级判断，它只在 location 块被选中后才生效。真正决定“哪个 proxy_pass 被执行”的，是 location 的匹配逻辑——而这个逻辑有一套明确、固定的优先级顺序。
location 匹配的四层优先级
请求进来时，Nginx 按以下顺序扫描所有 location 块，一旦命中就停止查找：
-
精确匹配（=）：完全一致才触发，比如
location = /health只响应/health，不响应/health/或/healthz - 前缀优先匹配（^~）：以指定字符串开头即匹配，且命中后不再检查正则，适合静态资源等确定性路径
-
正则匹配（~ 或 ~*）：按配置文件从上到下顺序执行，第一个匹配成功的即生效；
~区分大小写，~*不区分 -
最长普通前缀匹配（无修饰符）：比如请求
/api/v2/users，会匹配location /api/v2/而不是更短的location /api/
proxy_pass 的路径处理逻辑
location 块选定后，proxy_pass 如何拼接目标 URI，取决于它自身结尾是否有 /：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
-
proxy_pass 后带
/：表示“绝对路径替换”，location 匹配的部分会被完全剥离。例如：location /app/ { proxy_pass http://backend:8080/api/; }
访问/app/user→ 转发为http://backend:8080/api/user -
proxy_pass 后不带
/：表示“相对路径追加”，location 匹配部分原样保留。例如：location /app/ { proxy_pass http://backend:8080; }
访问/app/user→ 转发为http://backend:8080/app/user -
proxy_pass 后带非根路径（如
/admin/）：匹配部分被移除，该路径直接作为新前缀。例如：location /app/ { proxy_pass http://backend:8080/admin/; }
访问/app/list→ 转发为http://backend:8080/admin/list
容易踩坑的两个细节
实际配置中，这两点常导致转发结果出人意料：
-
location 末尾斜杠影响匹配范围：
location /api会匹配/api、/api/、/apixxx；而location /api/只匹配以/api/开头的路径，更安全 -
正则匹配与前缀匹配的冲突：即使你写了
location /api/，如果上面存在location ~ ^/api，正则可能抢先命中——因为正则虽排第三，但只要顺序靠前，就会覆盖后面的前缀规则
验证是否生效的小技巧
可以通过返回头或日志确认实际转发路径：
- 在 upstream 服务中打印原始请求路径，对比输入和收到的 URI
- 启用 Nginx
error_log并设为info级别，它会记录每次请求匹配了哪个 location 块 - 用
curl -v查看响应头中的X-Forwarded-Uri（需手动添加）或自定义 header 辅助调试
