网站把/api/交给后端后，后端却收到带两层前缀的路径，或者原本需要的前缀突然不见。很多时候，问题出在location与proxy_pass后面的URI写法。
不要靠反复补斜杠猜结果。先写出客户端请求路径、期望的后端路径，再按Nginx官方规则核对。
带URI和不带URI有什么差别
官方文档说明，proxy_pass指定URI时，匹配location的那段规范化路径会被代理指令中的URI替换；未指定URI时，请求URI按相应处理规则传给后端。
例如location /api/搭配proxy_pass http://backend/;，通常把前缀/api/换成/。先确认后端是否本来就需要该前缀。
用最小配置复现目标路径
记录一条具体请求，例如/api/users。如果后端预期/users，使用带/的目标URI；如果后端预期保留/api/users，通常使用不带URI的代理地址。
这是路径替换规则的示意，不代表所有正则location和变量写法都适用。复杂规则需对照官方例外说明。
排除重写与重定向干扰
查看是否还有rewrite、应用内基础路径配置、上游返回的Location头和前端路由。用nginx -T确认最终生效的配置，并在后端访问日志中看实际URI。
浏览器地址变化与后端收到的路径是两件事；不要只凭页面404判断是Nginx替换错误。
上线前做配置与请求验收
修改后先执行nginx -t，通过后重载。分别请求前缀根路径、子路径和带查询参数的地址，记录状态码与后端收到的URI。
验收必须覆盖真实业务路由。仅检查首页成功，无法证明API、静态文件和回调路径都正确。
用测试环境验证路径映射
在萤光云或LightNode的隔离VPS中部署同样的Nginx配置和一个可记录请求URI的测试后端，再迁移到生产。生产变更前保留可回滚的原配置。
FAQ
问：proxy_pass http://backend;和proxy_pass http://backend/;差别大吗？答：前者未指定URI，后者指定了/；在前缀location中可能导致不同的路径传递结果。
温馨提示
温馨提示：正则location、变量代理和rewrite场景有额外规则，先用目标版本文档与最小请求验证，不要套用一条斜杠口诀。
