加斜杠决定路径重写逻辑：location /api/ + proxy_pass http://backend/ 使后端收到 /login；proxy_pass 带路径如 http://backend/v1/ 实现前缀重写；正则 location 必须显式指定 URI；不带斜杠的 proxy_pass 易致 404。
配置 proxy_pass 的末尾斜杠，本质是控制 Nginx 如何处理请求路径——不是格式问题，而是转发逻辑的开关。加不加那一个 /，直接决定后端收到的是 /users 还是 /api/users。搞错就 404，调通靠它，出问题也常栽在这儿。
location 和 proxy_pass 都带斜杠：最常用的安全组合
这是前后端分离场景下的推荐写法，适合后端服务监听根路径（比如 Spring Boot 默认跑在 /）。
-
配置示例：
location /api/ { proxy_pass http://backend/; } -
效果：前端请求
/api/login→ 后端收到/login -
原理：Nginx 把匹配到的
/api/整段“抠掉”，再把proxy_pass后的/拼上去，剩余路径直接接续
proxy_pass 带自定义路径：实现接口前缀重写
当后端 API 实际部署在子路径下（如 /v1），又不想让前端感知，可以用带路径的 proxy_pass 一步到位。
-
配置示例：
location /service/ { proxy_pass http://backend/v1/; } -
效果：前端请求
/service/users→ 后端收到/v1/users -
注意：末尾斜杠不能省，否则会变成
/v1/service/users，多出一层前缀
正则 location 必须显式写 URI：避免启动失败
用 ~、~* 或 = 匹配时，Nginx 无法自动推导要截哪段路径，必须手动指定目标 URI，否则配置校验不通过。
-
错误写法（Nginx 启动报错）：
location ~ ^/static/ { proxy_pass http://cdn; } -
正确写法：
location ~ ^/static/(.+)$ { proxy_pass http://cdn/$1; } -
健康检查特例：
location = /health { proxy_pass http://backend/health; }—— 精确匹配 + 显式路径，安全可靠
不建议的组合：proxy_pass 不带斜杠 + location 带斜杠
例如 location /api/ { proxy_pass http://backend; }，看似简洁，实则风险高。
-
效果：前端请求
/api/login→ 后端收到/api/login -
问题：后端若没部署在
/api上下文（比如只监听/），就会 404；且路径语义混乱，难维护 - 建议：除非后端明确要求保留前缀（如某些遗留 Java Web 应用），否则一律避免
