nginx路径裁剪核心是location前缀匹配与proxy_pass末尾斜杠协同作用，自动剥离匹配前缀；推荐location和proxy_pass均带/，正则捕获用$1实现灵活裁剪，^~可提升匹配效率与确定性。
核心是靠 location 前缀匹配 + proxy_pass 末尾斜杠协同控制路径裁剪，不是靠 rewrite 指令“改 URL”，而是让 Nginx 在转发前自动剥离请求中与 location 匹配的部分，使后端服务只收到干净的子路径。
用带斜杠的 proxy_pass 实现自动裁剪
这是最常用、最可靠的方式。location 定义前缀，proxy_pass 以 / 结尾，Nginx 就会把匹配到的整个前缀从原始请求路径中去掉，再拼接到后端地址后：
-
location /api/user/ { proxy_pass http://user-svc:8081/; } → 请求
/api/user/profile转发为/profile -
location /v2/order/ { proxy_pass http://order-svc:8082/; } → 请求
/v2/order/list?status=1转发为/list?status=1 - 关键点：location 的末尾斜杠和 proxy_pass 的末尾斜杠要保持语义一致；都带 / 或都不带 / 容易出错，推荐统一带 /
用正则捕获 + $1 反向引用实现灵活裁剪
适合需要动态提取、重排路径的场景，比如按版本号或服务名路由，同时裁剪掉前缀：
-
location ~ ^/v1/(.+)$ { proxy_pass http://svc-v1/$1; } →
/v1/users/123→/users/123 -
location ~ ^/api/(product|payment)/(.*)$ { proxy_pass http://$1-svc:8080/$2; } →
/api/product/detail→/detail发往 product-svc - 注意：正则匹配优先级低于 = 和 ^~，但高于普通 / 匹配；写在配置靠前位置更可控
避免常见裁剪错误
路径裁剪失效，多数源于对 proxy_pass 斜杠行为理解偏差：
-
错例：
location /api/user { proxy_pass http://user-svc:8081; }（proxy_pass 不带 /）→ 请求/api/user/profile会原样发成/api/user/profile，后端可能 404 -
错例：
location /api/user/ { proxy_pass http://user-svc:8081; }（proxy_pass 不带 /）→ 实际转发为http://user-svc:8081/api/user/xxx，多了一层冗余路径 - 验证方法：开启 Nginx error_log debug 级别，或在后端加日志打印原始 request URI，确认收到的路径是否符合预期
配合 ^~ 提升匹配效率与确定性
当路径前缀固定、无需正则时，用 ^~ 明确告诉 Nginx “匹配成功就停，别再往下找正则”：
- location ^~ /static/ { root /var/www/static; } —— 静态资源不走代理，且阻断后续正则检查
- location ^~ /api/auth/ { proxy_pass http://auth-svc:8083/; } —— 确保所有 /api/auth/ 开头请求一定走这条，不受后面 location ~ 规则干扰
- 这对网关稳定性很重要：避免因正则顺序或意外匹配导致路径裁剪逻辑被绕过
