mod_proxy_html是修复反向代理页面内网url的核心方案，需按序启用proxy、proxy_http、proxy_html、xml2enc和headers模块，严格配置proxyhtmlurlmap顺序，并禁用gzip压缩以确保html内容体被正确重写。
要修复反向代理页面中残留的内网 URL（比如 http://10.5.10.200/css/app.css 或 /api/data），核心不是改响应头，而是重写 HTML 文档体内的链接——这正是 mod_proxy_html 的职责。它不依赖 ProxyPassReverse，后者只处理 Location 响应头和重定向，对页面内 <a href></a>、<img src>、<script src></script> 等完全无效。
必须启用且按序加载的关键模块
mod_proxy_html 不是独立运行的模块，它强依赖三个基础模块协同工作：
-
mod_proxy和mod_proxy_http：提供基本代理能力，必须先加载 -
mod_xml2enc：负责识别并正确解析 HTML 的字符编码（如charset=gb2312）。缺失时，非 UTF-8 页面直接跳过重写，静默失效 -
mod_headers：必需用于禁用后端压缩（RequestHeader unset Accept-Encoding），否则 gzip 响应无法被解析和重写
启用命令示例（Debian/Ubuntu）：
a2enmod proxy proxy_http proxy_html xml2enc headers
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
URL 映射顺序与写法必须精准
ProxyHTMLURLMap 不是字符串替换，而是基于路径前缀的模式匹配，且严格按配置顺序执行。顺序错误会导致绝对 URL 被误当成相对路径处理，引发链接损坏。
- 先处理绝对地址：
ProxyHTMLURLMap http://10.5.10.200 /lab（末尾不加/，避免把http://10.5.10.200/api错改成/lab/api） - 再处理相对地址：
ProxyHTMLURLMap / /lab/（开头斜杠不能省，否则匹配不到href="css/main.css"） - 若后端用 HTTPS，补一行：
ProxyHTMLURLMap https://10.5.10.200 /lab - 所有
ProxyHTMLURLMap必须放在<location></location>或<virtualhost></virtualhost>块内，不可写在.htaccess
绕过压缩与编码干扰
后端返回 Content-Encoding: gzip 是最常见的失效原因——mod_proxy_html 默认不处理压缩内容，直接跳过重写。
- 在代理配置中加入：
RequestHeader unset Accept-Encoding（需mod_headers） - 更稳妥的做法：让后端仅对静态资源（JS/CSS/图片）开启 gzip，HTML 响应保持未压缩
- 若页面含超长内联脚本或样式，调大缓冲区：
ProxyHTMLBufSize 16384（默认 8192 字节，不足会截断导致解析失败） - 避免缓存污染：如启用
mod_cache，添加CacheIgnoreHeaders Set-Cookie，防止未重写的原始 HTML 被缓存
启用并验证过滤器
仅配置映射还不够，必须显式启用输出过滤：
- 在对应位置块中添加：
ProxyHTMLExtended On（启用对<script></script>、<style></style>内链接的深度解析） - 加上：
ProxyHTMLEnable On（激活过滤器） - 推荐同时启用：
ProxyHTMLFixups lowercase（自动小写标签名，兼容老旧 HTML） - 验证是否生效：用
curl -I检查响应头是否含Content-Type: text/html，再用浏览器开发者工具查看源码，确认src和href已变为/lab/css/app.css类路径
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
