核心是proxy_pass末尾斜杠决定路径处理模式：带斜杠触发“替换”（移除location前缀后拼接剩余路径），不带斜杠触发“追加”（原样拼接完整请求URI），错配直接导致404或502。
排查 proxy_pass 转发路径拼接错误，核心是搞清 Nginx 如何处理请求 URI 与 proxy_pass 后端地址的组合逻辑——这一步错，后端收不到预期路径，404 或 502 就容易出现。
看 proxy_pass 末尾斜杠是否匹配请求 location
Nginx 对斜杠非常敏感，它直接决定 URI 是“替换”还是“追加”：
-
location 以 /path/ 开头，且 proxy_pass 以 / 结尾（如
proxy_pass http://backend/;）→ 前缀被完全替换：
请求/api/v1/users匹配location /api/ { proxy_pass http://backend/; }→ 实际转发到http://backend/v1/users -
location 以 /path/ 开头，但 proxy_pass 不以 / 结尾（如
proxy_pass http://backend;）→ 原 URI 全量追加：
同样请求/api/v1/users，用proxy_pass http://backend;→ 转发到http://backend/api/v1/users - location 精确匹配（
location = /api）或正则匹配时，proxy_pass 末尾斜杠规则依然生效，但需额外注意重写干扰
用 $request_uri 和 $uri 对比确认实际转发路径
在 proxy_pass 前加临时日志，快速验证 Nginx 解析出的路径：
location /api/ {
access_log /var/log/nginx/api_debug.log main;
log_format main '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'uri:"$uri" request_uri:"$request_uri"';
proxy_pass http://backend/;
}访问 /api/v1/users?x=1 后查看日志：
若 $uri 是 /v1/users、$request_uri 是 /api/v1/users?x=1，说明前缀 /api/ 已被剥离，符合 proxy_pass http://backend/ 的替换逻辑；反之若 $uri 还是 /api/v1/users，大概率是 proxy_pass 写成了 http://backend（少斜杠）或 location 没匹配上。
检查是否有 rewrite 干扰了原始 URI
rewrite 在 proxy_pass 之前执行，会修改 $uri 和 $request_uri，导致拼接结果偏离预期：
- 比如
rewrite ^/api/(.*)$ /v2/$1 break;+proxy_pass http://backend;→ 实际发给后端的是/v2/xxx - break 和 last 的区别很关键：break 终止当前 location 的 rewrite，last 会重新匹配 location —— 若误用 last，可能进入另一个 proxy_pass 块，路径被二次处理
- 临时注释 rewrite 规则，观察转发是否恢复正常，可快速定位是否为 rewrite 引发
验证后端真实收到的请求路径
不要只信 Nginx 日志，直接看后端服务的访问日志或用 tcpdump 抓包：
- 在后端机器运行：
tcpdump -i lo port 8080 -A | grep 'GET\|POST'（假设后端监听 8080） - 或在后端应用里打印原始 request.URL.Path（如 Go 的
r.URL.Path，Python Flask 的request.path） - 对比 Nginx 日志中的
$uri和后端实际收到的路径 —— 若不一致，问题一定出在 Nginx 配置；若一致而后端仍报错，则是后端路由配置问题
不复杂但容易忽略：多数拼接错误都卡在 proxy_pass 末尾斜杠和 location 前缀的对应关系上，先盯住这一条，再逐层排除 rewrite 和后端接收逻辑，基本就能定位。
