Apache的mod_proxy_balancer本身不提供IP哈希算法，需加载mod_lbmethod_byrequests模块并配置lbmethod=iphash，结合route参数和RemoteIP模块确保真实客户端IP参与哈希计算，实现基于源IP的会话粘性。
Apache 的 mod_proxy_balancer 本身不直接提供 IP 哈希算法，它依赖调度模块（如 mod_lbmethod_byrequests）配合 lbmethod=iphash 实现基于源 IP 的会话粘性。关键在于启用对应模块、正确配置 Balancer 并显式指定哈希策略——不是靠 Cookie，而是靠客户端真实 IP 地址做一致性哈希，确保同一 IP 始终落到同一后端节点。
必须启用的模块
IP 哈希功能由独立调度模块 mod_lbmethod_byrequests 提供（注意：不是 bytraffic 或 bybusyness），需在 Apache 配置中加载：
LoadModule proxy_module modules/mod_proxy.soLoadModule proxy_balancer_module modules/mod_proxy_balancer.soLoadModule proxy_http_module modules/mod_proxy_http.soLoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.so
缺一不可。若漏掉 lbmethod_byrequests_module，lbmethod=iphash 将无法识别，Apache 启动会报错或回退到默认轮询（byrequests）。
配置 Balancer 使用 iphash 算法
在 <Proxy> 块中定义集群时，必须通过 ProxySet lbmethod=iphash 显式启用 IP 哈希。示例配置如下：
<Proxy "balancer://mycluster">
BalancerMember http://192.168.1.10:8080 route=node1
BalancerMember http://192.168.1.11:8080 route=node2
ProxySet lbmethod=iphash
</Proxy>
ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
注意：route 参数虽非强制，但建议显式设置，便于后续排查和与 Cookie 粘性混用；lbmethod=iphash 必须写在 <Proxy> 块内，不能只放在 ProxyPass 行里。
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
处理代理链中的真实 IP
如果前端有 CDN、Nginx 或其他反向代理，Apache 收到的 REMOTE_ADDR 是上一级代理的 IP，而非用户真实 IP，会导致哈希失效。此时需：
- 确保上游代理在请求头中携带真实 IP，如
X-Forwarded-For或X-Real-IP - 在 Apache 中启用
mod_remoteip模块，并配置RemoteIPHeader X-Forwarded-For和可信代理网段（RemoteIPInternalProxy） - 验证生效：查看 Apache 日志中
%a是否已变为真实客户端 IP
否则，所有请求可能被哈希到同一个后端（因为都来自同一个代理 IP）。
与 Cookie 粘性共存的注意事项
IP 哈希和 Cookie 粘性（stickysession）可同时启用，但逻辑不同：
-
lbmethod=iphash在网络层起作用，无需应用配合，天然支持会话保持 -
stickysession=JSESSIONID在应用层解析 Cookie，要求后端返回的 Session ID 必须带.route后缀（如jsessionid=abc123.node1） - 二者不冲突，但优先级：若
stickysession匹配成功，则忽略 IP 哈希；未匹配时才走 IP 哈希
生产环境推荐以 IP 哈希为主，尤其当后端应用无法控制 Cookie 格式时，更稳定可靠。
