关键在于斜杠决定Nginx是替换前缀还是原样拼接：proxy_pass末尾带/则删除location匹配部分后拼接；不带/则原样拼接或错误拼接路径，易致404或重定向循环。
关键不在“怎么配”，而在理解斜杠是行为开关：它决定 Nginx 是替换前缀还是原样拼接。错一个斜杠，后端就收不到正确路径，404 或重定向循环立马出现。
proxy_pass 末尾带 /：安全替换前缀
这是最常用、最推荐的方式，适用于绝大多数前后端分离场景（后端监听根路径，如 /users、/login）。
- location 匹配到的部分（如
/api/）被完整移除 - 剩余 URI 直接拼到
proxy_pass的路径之后（哪怕只是/） - 示例：
location /api/ { proxy_pass http://backend:8080/; }
→ 请求/api/v2/profile，后端收到/v2/profile
proxy_pass 末尾不带 /：小心原样拼接
分两种情况，都容易出问题：
-
只写地址，无路径（如
http://backend）：Nginx 把整个原始请求 URI 原封不动拼过去
→location /admin { proxy_pass http://dashboard; }+ 请求/admin/log→ 后端收到/admin/log -
带路径但不带尾部 /（如
http://backend/v1）：Nginx 用/v1替换 location 前缀，且不加斜杠分隔
→location /api/ { proxy_pass http://backend/v1; }+ 请求/api/users→ 后端收到/v1users（不是/v1/users！）
location 和 proxy_pass 斜杠要对齐
两者结尾是否带 / 会影响行为一致性，尤其在边界请求时：
-
location /api { proxy_pass http://backend/; }：请求/api会被转发为http://backend//（双斜杠），部分后端会重定向或报错 -
location /static/ { proxy_pass http://cdn; }：请求/static（无尾斜杠）→ 后端收到/static；请求/static/→ 收到/static/，行为不一致易引发跳转循环 - 建议统一写法：
location /api/ { proxy_pass http://backend/; }，清晰可控
需要保留部分前缀？用 rewrite 配合带路径的 proxy_pass
当你要把 /v2/api/users 映射成 /api/v2/users 这类非简单替换时，单靠斜杠不够，需显式改写：
- 先用
rewrite提取并重组路径 - 再配带尾部
/的proxy_pass确保后续拼接干净 - 示例：
location ^~ /v2/api/ {<br> rewrite ^/v2/api/(.*)$ /api/v2/$1 break;<br> proxy_pass http://backend/;<br>}
→/v2/api/users→ 重写为/api/v2/users→ 转发给后端
