必须启用mod_proxy_balancer才能实现真实分流，仅加载mod_proxy和mod_proxy_http会导致单点代理；健康检查需同时满足三要素：启用mod_proxy_hcheck、定义ProxyHCExpr、在BalancerMember中完整配置hc参数；lbmethod应优先选bybusyness并配合loadfactor动态调权；所有后端宕机时须用ErrorDocument 503提供友好页面，并通过脚本监控/balancer-manager状态。
mod_proxy_balancer 必须启用，否则只是单点代理
只加载 mod_proxy 和 mod_proxy_http 无法实现分流——它只会把所有请求发给第一个可用后端。真实分流依赖 mod_proxy_balancer，而 Apache 2.4 默认不启用它。用 httpd -M | grep proxy 检查输出里必须含 proxy_balancer_module，缺了就得手动启用：
Ubuntu/Debian 执行 a2enmod proxy_balancer；RHEL/CentOS 则确认 /etc/httpd/conf.modules.d/00-proxy.conf 中有 LoadModule proxy_balancer_module modules/mod_proxy_balancer.so。
健康检查不是加个 status=+H 就自动生效
很多人在 BalancerMember 后写 status=+H 就以为启用了探测，其实这只是标记“允许被探测”，真正触发 HTTP 健康检查需要三要素同时存在：
-
mod_proxy_hcheck模块（Apache ≥2.4.33 才有），需显式LoadModule - 定义
ProxyHCExpr表达式，比如ProxyHCExpr ok {%{REQUEST_STATUS} =~ /^[23]/} - 在
BalancerMember中指定完整参数：hcmethod=HTTP hcuri=/health hcinterval=10 hcfail=3 hcpass=2
漏掉任意一项，节点宕机后仍会持续收请求，直到被动失败计数（如 retry=60）起作用——这比主动探测慢几十秒。
分流算法选错会导致流量倾斜甚至雪崩
lbmethod 不是随便选的：
– byrequests（默认）按请求数轮询，但忽略响应时长，慢节点积压连接；
– bytraffic 按字节数，对大文件传输友好，但小请求多的场景不敏感；
– bybusyness 真正看当前活跃连接数，生产环境最稳，尤其适合 Java 或 Python 这类易阻塞服务。
还要配合 loadfactor 动态调权，比如新扩容的机器先设 loadfactor=1，观察 10 分钟后再提到 3；别一上来就和老节点同权重。
隔离失效常因错误页没兜底
当所有后端都被健康检查标为 Down，Apache 默认返回 503，但用户看到空白页容易误判为服务崩溃。必须加一层容错：
- 用
ProxyBadHeader Ignore防止后端返回非法头导致整个请求失败 - 配
failonstatus=500,502,503,504让单次错误也计入失败计数，加速隔离 - 通过
ErrorDocument 503 /maintenance.html返回友好提示，而不是裸 503
最关键的是：别依赖 /balancer-manager 页面做日常监控——它本身要权限放行、依赖 mod_status，且无告警能力。应该用脚本定期调用 curl -s http://localhost/balancer-manager?auto=1 解析状态字段，发现 Down 节点立即发通知。
