ProxyPass 本身不处理请求头或过滤，需配合 RequestHeader unset early 清除 X-Forwarded-For、Authorization、X-Real-IP 等高危头，并通过 ProxyPreserveHost On 和 env 条件注入可信头来保障安全。
ProxyPass 本身不处理请求头，更不会自动过滤敏感头——它只负责路径转发。真正防止信息泄露，靠的是在 ProxyPass 前后配合 RequestHeader unset 主动清除客户端可伪造的危险头，并用 ProxyPreserveHost On 和可信头注入来确保后端拿到的是真实、干净的上下文。
必须清除的三类高危请求头
客户端可随意构造这些头，若透传给后端，可能绕过认证、污染日志或触发 SSRF：
- X-Forwarded-For：伪造源 IP，干扰访问控制和审计
- Authorization：携带无效或恶意凭证，后端误解析导致越权或解析异常
- X-Real-IP：与 X-Forwarded-For 类似，非标准且易被滥用
配置写法（放在 <Location> 或 <VirtualHost> 内，必须加 early）：
RequestHeader unset X-Forwarded-For early
RequestHeader unset Authorization early
RequestHeader unset X-Real-IP early
只允许可信来源带转发头
如果前端有 CDN 或 WAF，它们发来的 X-Forwarded-* 是可信的，但普通用户请求一律不能带。Apache 可通过条件判断实现“仅内网代理可传”：
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 先用
RemoteIPInternalProxy声明可信代理 IP 段（如10.0.0.0/8） - 再用
Require ip限制入口，或用Require expr判断来源是否在可信段内 - 对非可信请求，强制重写或拒绝，而非简单忽略
用 ProxyPreserveHost + 标准头替代伪造输入
后端需要 Host、协议、端口等信息，但绝不能信客户端传的。正确做法是：
- ProxyPreserveHost On：透传原始 Host（安全，因 Host 不可伪造跨域）
- RequestHeader set X-Forwarded-Proto "https" env=HTTPS：由 Apache 自己判断并注入，不依赖客户端
- RequestHeader set X-Forwarded-Port "443" env=HTTPS：同理，避免后端错误生成 HTTP 链接
这样既满足后端需求，又杜绝了头污染风险。
验证是否生效
用 curl 模拟带恶意头的请求：
curl -H "X-Forwarded-For: 1.2.3.4" -H "Authorization: Bearer fake" https://yourdomain.com/api/test
抓包或查看后端 access log，确认收到的请求中已无这两个头；同时检查后端能否正确识别 HTTPS 协议和原始 Host。
