proxypass本身不实现负载均衡，真正依赖balancer://协议地址背后由定义的集群提供健康感知、故障剔除与流量调度能力；必须配置balancermember、proxyset lbmethod、stickysession及proxypassreverse等协同工作。
ProxyPass 本身不实现负载均衡，它只是请求转发的“出口”。真正构建高可用集群，靠的是 ProxyPass 指向一个 balancer:// 协议地址，而这个地址背后由 <proxy balancer:></proxy> 定义的集群提供健康感知、故障剔除和流量调度能力。
必须先定义带健康检查的 balancer 集群
所有后端节点必须注册到一个命名的 balancer 组中，并启用状态监控。例如：
-
<proxy balancer:></proxy>是集群声明起点，myapp是自定义组名 - 每个
BalancerMember后需加status=+H（H 表示启用健康检查），否则节点始终在线，故障不会自动下线 - 推荐显式指定
route参数，如route=node1，为后续会话粘滞打基础 - 必须配置
ProxySet lbmethod=byrequests或bytraffic，否则默认轮询可能不生效
ProxyPass 必须指向 balancer:// 地址，不能直连单台后端
错误写法：ProxyPass / http://10.0.1.10:8080/ —— 这只是普通反向代理，无集群能力
正确写法：ProxyPass / balancer://myapp/ —— 把所有 / 下请求交由 myapp 集群统一分发
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
关键细节：
-
balancer://myapp/末尾斜杠必须与ProxyPassReverse保持一致，否则重定向、Cookie 路径错乱 - 必须配对使用
ProxyPassReverse / balancer://myapp/，确保后端返回的 Location、Set-Cookie 等头被正确重写 - 若只代理子路径（如
/api），则 ProxyPass 和 ProxyPassReverse 都要限定该路径前缀
开启会话保持与真实客户端信息透传
高可用不只是转发，还要保障业务连续性：
- 加
stickysession=ROUTEID到ProxySet，让同一用户始终落到同一后端节点（配合 Tomcat 的jvmRoute） - 用
RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}e"主动注入原始 IP，避免日志全记成 Apache 本机地址 - 若 Apache 终止 HTTPS，加
RequestHeader set X-Forwarded-Proto "https" early，让后端能正确生成安全链接 - 启用
remoteip_module并配置RemoteIPHeader X-Forwarded-For，可使%h日志字段和限流模块真正识别真实用户
验证集群是否真正生效
光配对没用，得确认健康检查和故障转移在运行：
- 访问
/balancer-manager（需在<location></location>中授权），查看各节点状态是否为OK或IN ERROR - 手动停掉一个后端服务，观察 balancer-manager 是否几秒内将该节点标为
DISCONNECTED，且流量自动切到其余节点 - 检查 Apache 错误日志，出现
proxy_balancer: for worker (http://...): retry表示健康检查已触发重试逻辑 - 用
curl -I http://your-domain/查看响应头是否含X-Balancer-Worker（需开启mod_headers并手动注入）
