必须显式配置ProxyPassReverse修正后端302重定向地址，使其指向公网URL而非内网地址；它仅修改Location、Content-Location和URI响应头，且必须与ProxyPass路径、协议、主机、端口严格一致（含末尾斜杠），多后端需分别配对，并配合X-Forwarded-Proto等确保HTTPS正确传递。
全站启用 HTTPS 后，Apache 的 ProxyPassReverse 本身不处理协议切换，它只重写响应头中的 Location、Content-Location 和 URI 等字段的路径部分。若后端应用返回的是 http:// 开头的重定向（比如 302 跳转），用户会遇到混合内容或跳转到 HTTP 地址而失败——这正是问题核心。
确保后端返回 HTTPS 重定向地址
最根本的解法是让后端服务意识到“当前请求是通过 HTTPS 进来的”，从而生成正确的 https:// 重定向 URL。Apache 需向后端传递协议信息：
- 用
RequestHeader set X-Forwarded-Proto "https"（配合mod_headers）显式告知后端当前是 HTTPS - 同时建议设置
X-Forwarded-For和X-Forwarded-Host，便于后端构建完整 URL - 后端框架（如 Spring Boot、Django、Express）需配置信任这些头，并启用“forwarded header support”
ProxyPassReverse 只修正路径，不改协议
ProxyPassReverse 默认只匹配并替换响应头中与代理路径匹配的 路径前缀，例如：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
ProxyPass /app/ http://localhost:8080/ ProxyPassReverse /app/ http://localhost:8080/
它会把 Location: http://localhost:8080/login 改成 Location: /app/login，但不会把 http://example.com 改成 https://example.com。协议和域名必须由后端生成正确，或借助其他机制干预。
用 ProxyPassReverse 搭配重写规则补救（不推荐长期使用）
若短期无法修改后端，可借助 mod_substitute 或 mod_headers 强制替换响应体/响应头中的 HTTP 协议：
- 启用
mod_substitute，在<Location>或代理上下文中添加：
<Location "/app/"> Substitute "s|http://([^/]+)|https://$1|ni" Substitute "s|Location: http://|Location: https://|i" </Location>
- 注意：该方式对压缩响应（如 gzip）无效，且可能误替换 HTML 内容中的正常 HTTP 字符串，仅作临时过渡
检查 SSL 终止是否在 Apache 层完成
确认 HTTPS 是由 Apache 终止（而非前面的 CDN 或负载均衡器），否则 X-Forwarded-Proto 可能被覆盖或丢失：
- 查看访问日志中
%{X-Forwarded-Proto}i是否为https - 若前端有 Nginx/CDN，需确保它也设置了
X-Forwarded-Proto: https并透传给 Apache - Apache 配置中避免重复设置
RequestHeader set导致覆盖
