启用 mod_proxy_html 是为将反向代理后 HTML 中内网地址重写为客户端可访问路径，需按序启用 proxy、proxy_http、xml2enc、headers 四模块，并配置 ProxyHTMLURLMap 规则、禁用 Accept-Encoding 及调整缓冲区。
apache 启用 mod_proxy_html 的目的，是让反向代理后的 html 页面里那些写死的内网地址（比如 href="http://10.5.10.200/css/style.css" 或 src="/js/app.js"）能自动变成客户端可访问的路径（如 /lab/css/style.css）。但它不是万能补丁，必须配合模块依赖、顺序配置和关键规避措施才能真正生效。
必需启用的四个模块及加载顺序
该模块无法单独运行，以下四个模块必须全部启用，且加载顺序不能颠倒：
-
mod_proxy和mod_proxy_http：提供基础代理能力与 HTTP 协议支持 -
mod_xml2enc：识别 HTML 响应头中的字符编码（如charset=gb2312），没它就跳过解析 -
mod_headers：用于清除客户端请求头里的Accept-Encoding，防止后端返回 gzip 压缩内容导致解析失败
Debian/Ubuntu 系统执行：a2enmod proxy proxy_http proxy_html xml2enc headers
RHEL/CentOS 需确认 httpd.conf 中对应 LoadModule 行已取消注释。
URL 映射规则要分层写、带锚点、按优先级排列
映射不是简单替换字符串，而是按配置顺序逐条匹配 URL 前缀。顺序错，链接就可能被截断或误改：
- 先处理绝对 URL：
ProxyHTMLURLMap http://10.5.10.200 /lab（末尾不加斜杠，避免把/api错改成/lab/api） - 再处理根相对路径：
ProxyHTMLURLMap / /lab/（开头必须有斜杠，否则匹配不到href="css/main.css"） - 若后端用 HTTPS：
ProxyHTMLURLMap https://10.5.10.200 /lab - 多级嵌套时，优先写最具体规则，例如：
ProxyHTMLURLMap /v2/api/ /internal/ L（L表示匹配后终止，防止后续规则干扰）
所有 ProxyHTMLURLMap 必须放在 <Location> 或 <VirtualHost> 块内，不可写在 .htaccess 中。
绕过 gzip 和编码干扰的关键设置
如果后端返回的是 gzip 压缩的 HTML，mod_proxy_html 默认不处理，链接将原样保留：
立即学习“前端免费学习笔记（深入）”；
- 在
<Location>或<VirtualHost>中加入：RequestHeader unset Accept-Encoding，让后端不压缩 HTML 响应 - 静态资源（CSS/JS/图片）可继续启用 gzip，不影响 HTML 解析
- 若页面含大量内联 JS，可能超出默认缓冲区，需调大：
ProxyHTMLBufSize 16384（默认为 8192）
比 mod\_proxy\_html 更稳妥的替代思路
虽然 mod_proxy_html 能重写 HTML 内的链接，但它有明显局限：
- 无法处理 JS 代码中拼接的 URL（如
fetch('/api/user')或window.location.href = 'http://10.5.10.200/login'） - 修改 HTML 会改变
Content-Length，可能影响流式传输或压缩校验 - 不如从源头解决：启用
ProxyPreserveHost On，并让后端应用读取X-Forwarded-For和X-Forwarded-Proto头，自主生成正确链接
对 Java/Spring Boot 应用，只需配置 server.forward-headers-strategy=framework；前端框架如 Vue/React 也建议使用环境变量控制 API 基地址，而非硬编码内网路径。
