Apache mod_proxy 本身不处理响应体，无法直接脱敏；需用mod_sed、mod_substitute或ModSecurity等模块实现，或由后端应用层完成更安全可控的脱敏。
Apache mod_proxy 本身不提供内容改写或敏感词脱敏能力，它只负责请求转发与响应头处理（如 ProxyPassReverse）。对后端响应体（HTML/JSON/文本）进行实时关键词识别与替换，需借助其他模块或外部机制配合实现。
核心限制：mod_proxy 不处理响应体内容
mod_proxy 的设计目标是协议代理与路由，所有响应体（body）数据流经时默认不做解析、不修改。即使启用了 mod_proxy_http 或 mod_proxy_balancer，也无法直接插入字符串替换逻辑。试图用 RewriteRule 或 Header 指令操作响应体内容，均无效——这些指令仅作用于请求行、请求头或响应头。
可行方案：组合使用内容过滤模块
若必须在 Apache 层做响应体脱敏，需引入支持 body 处理的第三方或官方扩展模块：
-
mod_sed（推荐）：Apache 2.4+ 内置，支持基于正则的响应体流式替换。需配合
SetOutputFilter启用，并注意编码兼容性（如 UTF-8 中文需确保正则正确匹配）。 -
mod_substitute：更轻量，专为简单文本替换设计。支持
Substitute s/原词/脱敏后/ni语法，适合固定关键词列表，但不支持动态算法（如哈希、保留首尾等）。 - mod_security + SecResponseBodyAccess On：通过 ModSecurity 规则引擎捕获并改写响应体。功能强大，可集成自定义脚本或 Lua 进行复杂脱敏（如调用外部 API 或执行 ShardingSphere 类脱敏逻辑），但部署和规则编写门槛较高。
典型配置示例（mod_substitute）
假设后端返回 JSON，需将字段值中的“身份证号”“手机号”脱敏为 ***：
<location>
ProxyPass http://127.0.0.1:8080/api/
ProxyPassReverse http://127.0.0.1:8080/api/
AddOutputFilterByType SUBSTITUTE application/json
Substitute "s/"idCard":"[0-9Xx]{18}"/"idCard":"**********"/ni"
Substitute "s/"phone":"1[3-9]\d{9}"/"phone":"***"/ni"
</location>
注意：Substitute 对响应体大小有限制（默认 1MB），超长内容会被跳过；正则需转义 JSON 双引号；不适用于压缩传输（需先禁用 gzip 或用 mod_deflate 配合处理）。
更健壮的做法：交由后端应用层脱敏
真正安全、可控且符合合规要求的脱敏，应由 Java/Python/Go 等后端服务在生成响应前完成。理由包括：
- 能准确识别字段语义（如区分“用户姓名”和“地址中的姓名”）；
- 支持上下文感知脱敏（如仅脱敏日志中手机号，不脱敏短信模板）；
- 可复用现有脱敏框架（如 Apache ShardingSphere 的
keep_first_n_last_m算法）； - 避免 Apache 层成为性能瓶颈或单点故障。
此时 Apache 仅需正确透传 X-Forwarded-For、X-Forwarded-Proto 等头，确保后端获取真实客户端信息即可。
