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