HTML文档在多级反向代理环境下的访问来源结构解析方案-html教程-PHP中文网

html文档真实访问路径需依赖x-forwarded-prefix、x-forwarded-for和host头完整透传与校验，document.location.pathname仅反映客户端url，无法体现代理链中被重写的原始路径；后端须组合可信头还原，而非信任req.url。

html文档在多级反向代理环境下的访问来源结构解析方案

多级反向代理下，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）来赋值，不能硬写死。

实操建议：

Wechat HTML Publisher

直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

下载

第一层代理（最靠近客户端）应设 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"></script>，浏览器就会请求 /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) 才启用自动解析，否则得手写逻辑