proxy_pass末尾斜杠决定路径拼接逻辑：location /api/配proxy_pass http://backend/时后端收/v1/user，不加斜杠则收/api/v1/user；多级代理须透传x-forwarded-*头，html相对路径需用或sub_filter修复。
proxy_pass末尾斜杠决定路径拼接逻辑
真实路径被“吃掉”或“错位”，八成是因为proxy_pass结尾有没有/没搞清。这是多级代理中最常踩的坑，直接导致后端收到的PATH_INFO和预期不符。
关键规则就一条：如果location /api/带末尾/，那么proxy_pass http://backend/也必须带末尾/，否则/api/会被原样拼到后端路径前——比如请求/api/v1/user，后端实际收到/api/v1/user而非/v1/user。
-
location /api/ { proxy_pass http://backend/; }→ 后端收/v1/user -
location /api/ { proxy_pass http://backend; }→ 后端收/api/v1/user -
location /api { proxy_pass http://backend/api; }→ 后端收/api/v1/user（注意这里location不带/，proxy_pass也不能带）
多级代理中X-Forwarded-*头必须透传
前端HTML里用fetch('/user')发请求，经过Nginx A → Nginx B → 后端服务，若中间某一级没透传X-Forwarded-For和X-Forwarded-Prefix，后端就无法还原原始请求路径，尤其在生成跳转URL或签名链接时会出错。
每层代理都得显式加这几行：
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Prefix $request_uri;
注意：$request_uri包含查询参数，若只需路径部分，改用$uri；但$uri不带参数，选哪个取决于后端解析逻辑。
HTML中相对路径在代理后失效的修复方式
静态HTML里写<script src="js/app.js"></script>，本地开发能跑，一上反向代理就404——因为浏览器按当前URL路径解析相对地址，而代理没改<base href>或没重写资源路径。
- 最稳方案：在HTML头部加
<base href="/subpath/">，所有相对路径以此为根 - 次选方案：Nginx用
sub_filter动态替换HTML里的src="js/为src="/subpath/js/（需开启subs_filter_types text/html;） - 避免方案：硬编码绝对路径如
src="https://example.com/subpath/js/app.js"——跨环境难维护
后端服务如何安全还原原始请求路径
后端语言（如Python Flask、Node.js Express）不能只信req.url，得组合X-Forwarded-Prefix和X-Forwarded-For来重建原始路径。很多框架默认不处理这个，得手动做。
例如Flask中：
from flask import request
def get_original_path():
prefix = request.headers.get('X-Forwarded-Prefix', '')
if prefix and prefix.startswith('/'):
return prefix + request.path
return request.path
注意两点：一是X-Forwarded-Prefix可能为空或非法，必须校验；二是如果代理链中有多个X-Forwarded-Prefix（比如两层Nginx都设了），取第一个即可，后续会被覆盖。
真正麻烦的不是配置本身，而是各层代理对proxy_pass斜杠、rewrite规则、sub_filter启用与否的组合爆炸——一个环节漏掉，路径就断在半路。别指望“试几次就能通”，得从第一层开始逐级验证curl -v看到底转发成了什么。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
