不推荐用 mod_rewrite 的 [p] 标志做反向代理，因其绕过标准处理链导致响应头不重写、路径错乱、重定向失效，且缺乏负载均衡等高级功能；应使用 proxypass + proxypassreverse 组合。
不推荐用 mod_rewrite 的 [P] 标志做反向代理 —— 它不是为高性能或生产环境设计的，容易引发路径错乱、头信息丢失、重定向失效等问题，且缺乏 ProxyPassReverse 级别的响应头自动重写能力。
为什么[P]标志不适合透明反向代理
RewriteRule ... [P] 本质是让 mod_proxy 在内部调用一次代理逻辑，但它绕过了标准反向代理的完整处理链：
- 不自动改写
Location、Set-Cookie、Content-Location等响应头，后端返回的 302 跳转或 Cookie 域名/路径会直接暴露内网地址（如http://127.0.0.1:8080/login） - 不继承
ProxyPreserveHost On、ProxyPassReverse等关键行为，需手动补全大量头操作（如用Header edit和RequestHeader），配置冗长易错 - 无法与负载均衡、健康检查、连接池等高级功能集成
- 性能上无优势：底层仍依赖
mod_proxy_http，但缺少连接复用优化和缓存策略支持
真正透明且高性能的替代方案
用标准 ProxyPass + ProxyPassReverse 组合，配合必要头传递，才是 Apache 反向代理的正确打开方式：
-
必须启用模块：
mod_proxy和mod_proxy_http（缺一不可，否则报 500 或Invalid command 'ProxyPass'） -
强制开启 Host 透传：
ProxyPreserveHost On，确保后端生成的绝对 URL 使用真实域名而非代理地址 -
严格匹配路径斜杠：如
ProxyPass /api/ http://127.0.0.1:8080/api/，前后斜杠必须一致，避免路径拼接错误 -
传递客户端真实信息：添加
RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}e"和RequestHeader set X-Forwarded-Proto "http"（HTTPS 下改为https）
典型安全透明配置示例
以代理本地 Java 应用（http://127.0.0.1:8080）为例，部署在 app.example.com 域名下：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
<virtualhost>
ServerName app.example.com
ProxyPreserveHost On
ProxyRequests Off
<pre class="brush:php;toolbar:false;"># 代理全部请求
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
# 传递客户端IP和协议
RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}e"
RequestHeader set X-Forwarded-Proto "http"
# 可选：隐藏代理身份
ProxyVia Off
Java 应用需启用对 X-Forwarded-For 和 X-Forwarded-Proto 的解析（如 Spring Boot 配置 server.forward-headers-strategy=framework），否则 request.getRemoteAddr() 仍返回 127.0.0.1。
如果非要使用[RewriteRule [P]]的极少数场景
仅限简单调试或单页临时转发（如 RewriteRule ^/test$ http://127.0.0.1:8080/test [P,L]），且必须同步手动处理响应头：
- 用
Header edit Location替换重定向地址中的内网部分 - 用
Header edit Set-Cookie修正Domain和Path - 禁用
mod_cache干扰，避免缓存原始响应头
这种写法维护成本高、可读性差，不建议用于 API 网关、登录系统或任何含跳转/会话逻辑的服务。
