HTML文档真实访问路径需依赖X-Forwarded-Prefix、X-Forwarded-For和Host头完整透传与校验，document.location.pathname仅反映客户端URL，无法体现代理链中被重写的原始路径；后端须组合可信头还原，而非信任req.url。
多级反向代理下，HTML文档的访问来源结构不是“一层层剥洋葱”，而是靠头信息拼出来的——关键不在请求路径本身，而在 X-Forwarded-Prefix、X-Forwarded-For 和 Host 这三个头是否被完整透传且未被篡改。
为什么 document.location.pathname 不能直接反映真实访问路径
浏览器里的 document.location.pathname 是当前 URL 解析结果，它只反映客户端看到的路径，和后端收到的请求路径完全无关。比如用户访问 /admin/dashboard，经过 Nginx A → Nginx B → 后端，如果中间某层没透传 X-Forwarded-Prefix，后端就无法知道这个 /admin 是原始前缀还是某层代理自己加的。更糟的是，有些代理会重写 Host 或覆盖 X-Forwarded-For，导致路径还原失真。
常见错误现象：
- 前端发
fetch("/api/user")，后端日志里却看到请求来了/admin/api/user或/api/user，但不确定哪段是代理加的 - 生成跳转链接时用
req.url拼接，结果跳到https://backend:3000/api/user（漏了子路径） - 同一套 HTML 部署在
/app1/和/app2/下，但资源加载全部 404
X-Forwarded-Prefix 和 $request_uri 的选与用
X-Forwarded-Prefix 是人工约定头，不是 HTTP 标准，但它在多级代理中是还原原始路径最可靠的依据——前提是每层都显式设置且不覆盖。Nginx 中必须用 $request_uri（带 query）或 $uri（仅 path）来赋值，不能硬写死。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 第一层代理（最靠近客户端）应设
proxy_set_header X-Forwarded-Prefix $request_uri;，这样能保留原始请求全貌 - 后续中间层代理**不要覆盖**
X-Forwarded-Prefix，而应追加或透传：用proxy_set_header X-Forwarded-Prefix $http_x_forwarded_prefix; - 后端语言（如 Express、Flask）应优先读
X-Forwarded-Prefix，再 fallback 到X-Forwarded-For+Host组合推导 - 避免用
Referer推路径——它可能被浏览器或中间件过滤或重写
HTML 中相对路径失效的根本原因与修复边界
问题不在代理本身，而在浏览器解析相对路径时，锚定的是当前 URL 的 origin + pathname，而代理没改这个上下文。比如 HTML 在 https://example.com/sub/app/index.html 被访问，但页面里写 <script src="js/app.js">，浏览器就会请求 /sub/app/js/app.js；若代理没把 /sub/app/ 映射对，就 404。
修复方案选择逻辑：
- 用
<base href="/sub/app/">最轻量，但要求所有静态资源路径都按此 base 解析，且不能动态切换 - Nginx
sub_filter可动态重写 HTML 内容，但只适用于 text/html 响应，且需开启subs_filter_types text/html;，对 gzip 响应无效 - 绝对路径如
src="/sub/app/js/app.js"可行，但部署路径变更时需重新构建或注入环境变量，不适合纯静态托管场景
后端还原原始路径时最容易忽略的兼容点
很多后端框架默认信任 req.url 或 req.originalUrl，但在多级代理下，这些值已被 Nginx 的 proxy_pass 重写过，不再是客户端原始请求。真正安全的做法是：组合 X-Forwarded-Prefix（路径前缀）、X-Forwarded-Proto（协议）、Host（域名），再拼出原始 URL。
关键细节：
-
X-Forwarded-Prefix值末尾是否带/？后端拼接时要统一处理，否则可能变成/sub//api - 若某层代理用了
rewrite ^/sub/(.*)$ /$1 break;，则$request_uri已被改写，此时X-Forwarded-Prefix必须由该层手动设为/sub，不能依赖变量 - Node.js 的
req.headers['x-forwarded-prefix']默认是小写，Express 中需用app.set('trust proxy', true)才启用自动解析，否则得手写逻辑
复杂点在于：没有哪一层代理能 100% 保证头信息可信。生产环境必须校验 X-Forwarded-Prefix 是否匹配已知部署前缀白名单，否则可能被伪造头诱导跳转或路径遍历。
