byrequests真正生效的前提是同时启用mod_proxy_balancer、使用balancer://协议定义后端、且无节点被静默剔除；漏掉任一条件将退化为单点代理。
byrequests 真正生效的前提是什么
它不是“设了就公平”，而是依赖三个硬性条件同时满足：mod_proxy_balancer 必须启用、后端必须用 balancer:// 协议定义、且不能有节点被静默剔除。常见错误是只启用了 mod_proxy 和 mod_proxy_http，漏掉 mod_proxy_balancer ——此时 Apache 会退化为普通反向代理，所有请求都发给配置里的第一个 BalancerMember，日志里连警告都没有。
验证方式很简单：apachectl -M | grep proxy_balancer 必须有输出；curl -sI http://your-proxy/ | grep X-Backend（前提是后端写了这个头）要能看到多个不同值；否则别急着调权重，先修基础。
loadfactor=1 和 loadfactor=2 不等于 1:2 的请求数比
byrequests 是计数轮询，但实际分发节奏受节点状态干扰极大。比如：
-
loadfactor=2和loadfactor=1的节点，理论请求数比是 2:1，但若其中一个响应慢导致ping超时，Apache 会临时把它标记为failed，剩下的节点就变成 1:0 分配，直到健康检查恢复 -
status=+D（禁用）或status=+H（热备）会让节点退出轮询队列，权重再高也没用 - 如果某节点返回 5xx 频繁，又没配
ProxyHCExpr健康检查，它仍会持续收请求，只是成功率低
所以“公平”是动态的，不是静态权重表。别只看配置，得盯 /balancer-manager 页面里的 “Current Requests” 和 “Elected” 计数器变化。
为什么浏览器反复刷新看不出轮询效果
因为 HTTP Keep-Alive、CDN 缓存、甚至后端 Tomcat 的 session 复用都会让单个客户端看起来总落在同一台机器上。这不是 byrequests 失效，而是连接复用掩盖了调度行为。
真要验证，得切断复用链：
- 临时加
KeepAlive Off（仅测试用） - 用
curl -H "Connection: close" -sI http://proxy/发请求 - 确保后端在响应头写入唯一标识，比如
X-Backend: node1 - 配合日志：在
LogFormat里加%{BALANCER_WORKER_ROUTE}e，然后tail -f access_log看 route 变化
byrequests 在什么场景下会“不公平”
它对长连接、慢响应、异构后端最不友好。比如一个节点处理 API 很快（100ms），另一个跑文件下载（5s），byrequests 仍按请求计数分发，结果慢节点积压大量连接，活跃请求数飙升，但算法看不见——它只数“发出去几个”，不管“还剩几个没回”。
这时该换 lbmethod=bybusyness，它实时读每个节点的 busy 计数器，优先挑空闲的。或者至少加 ping=5 和 retry=60，让故障节点更快被隔离。
真正容易被忽略的点是：默认 byrequests 没有内置健康探测逻辑，status=+H 只是标记，不触发心跳；要真做故障转移，必须配 ProxyHCExpr 和 ProxyHCTemplate，否则“公平”只是纸面公平。
