proxy_pass末尾斜杠决定路径处理模式：带斜杠则替换location前缀，不带则原样拼接；正则location必须显式指定proxy_pass路径；需保留部分前缀时可用rewrite配合带路径proxy_pass。
关键就看 proxy_pass 末尾有没有斜杠——它不是格式问题，而是路径处理模式的开关。带斜杠走“替换”，不带斜杠走“原样拼接”，错一个字符，后端就收不到正确路径，404 就跟着来了。
proxy_pass 带斜杠：用后端路径替换 location 前缀
这是最常用也最稳妥的方式，适合后端监听根路径（如 /user、/api/profile）的场景。
- location 匹配到的部分（比如
/api/）会被完整移除 - proxy_pass 后的路径（哪怕只是
/）会作为新起点，接上剩余 URI - 请求
/api/users→ 后端收到/users - 请求
/api/v2/login→ 后端收到/v2/login
配置示例：
location /api/ {proxy_pass http://backend:8080/;
}
proxy_pass 不带斜杠：把完整请求路径直接拼过去
这种写法容易触发 404，除非后端明确部署在对应上下文路径下（比如 Spring Boot 的 server.servlet.context-path=/api），否则慎用。
- location 匹配部分（如
/user-service/）不被移除 - Nginx 把整个原始请求路径（
/user-service/api/profile）拼到后端地址后 - 结果就是
http://backend:8080/user-service/api/profile - 如果后端没监听
/user-service这层，必然 404
配置示例（不推荐，除非后端真需要这个前缀）：
location /user-service/ {proxy_pass http://backend:8080;
}
正则匹配 location 必须显式指定 proxy_pass URI
当用 ~ 或 ~* 写正则 location（比如 location ~ ^/v\d+/api/），Nginx 不再自动推导路径替换逻辑，必须手动写清楚 proxy_pass 后的路径。
- 不能只写
proxy_pass http://backend;（会报错或行为异常） - 必须带上路径，比如
proxy_pass http://backend/;或proxy_pass http://backend/api/; - 这样 Nginx 才知道该用哪个 URI 替换匹配内容
需要保留部分前缀？用 rewrite 配合带路径的 proxy_pass
有时要改写路径但又不想完全去掉前缀，比如把 /service-a/api/xxx 转成 /api/xxx，可结合 rewrite 和 proxy_pass 带路径写法。
- 先用 rewrite 去掉不需要的段（
rewrite ^/service-a(/.*)$ $1 break;） - 再用
proxy_pass http://backend/;确保后续路径从根开始转发 - 或者一步到位：
proxy_pass http://backend/api/;，把所有匹配请求都映射到后端的/api/下
