Apache的byrequests算法本质是轮询，按请求顺序依次分发，需正确加载proxy_balancer模块、使用balancer://协议定义后端组、确保节点状态正常且权重非零，并通过/balancer-manager或日志验证分配公平性。
Apache 的 byrequests 算法本质就是轮询（Round Robin），它按请求到达顺序，依次分发给后端节点，不依赖响应时间或连接数，天然适合请求数层面的公平分配。但“公平”不是配完就自动达成——很多配置疏漏会让它看起来“不公平”，甚至退化为单点转发。
确保轮询真正启用而非静默失效
byrequests 是 mod_proxy_balancer 的默认策略，但前提是模块必须加载且配置写对：
- 运行
a2enmod proxy_balancer（Debian/Ubuntu）或确认httpd.conf中已启用：LoadModule proxy_balancer_module modules/mod_proxy_balancer.so - 检查是否生效：
apachectl -M | grep proxy_balancer，输出应含proxy_balancer_module - 必须使用
balancer://协议定义后端组，例如ProxyPass / http://a/ http://b/不会触发轮询，Apache 会退化为普通代理，所有请求都发给第一个地址
让每个节点实际参与轮询
节点状态和权重直接影响是否被纳入轮询队列：
- status 参数要谨慎：
status=+D（禁用）、status=+H（仅健康检查，初始不参与）都会让节点跳过分配 - loadfactor 值为 0 会导致该节点完全不接收请求（注意：weight=0.8 会被截断为 0）
- 所有
BalancerMember应至少保持默认状态（无 status 修饰）且loadfactor=1，才能实现严格 1:1 请求轮转
验证分配是否真实公平
别靠浏览器反复刷新看 IP 变化——Keep-Alive、缓存、CDN 都会干扰判断：
- 临时关闭连接复用：
KeepAlive Off，并用 curl 加头测试：curl -H "Connection: close" -sI http://proxy/ | grep X-Backend（需后端在响应头中写入标识） - 开启
mod_status并访问/balancer-manager，页面中 “Current Requests” 列实时显示各节点当前处理请求数，多发几次请求，观察计数是否交替递增 - 日志中记录环境变量：
%{BALANCER_WORKER_ROUTE}e，可精确追溯每次请求落到哪个节点
避免路径配置破坏轮询语义
ProxyPass 的斜杠结尾决定 URL 重写逻辑，错误写法会导致后端 404 或路由错乱，间接影响负载表现：
- 正确写法：
ProxyPass / balancer://mycluster/→ 将/api转为/api发往后端 - 错误写法：
ProxyPass / balancer://mycluster（末尾无 /）→ 将/api拼成http://node//api，多数后端拒绝处理 - 若后端有 context-path（如 Spring Boot 的
server.servlet.context-path=/app），需配合ProxyPass /app balancer://mycluster/app/保证路径对齐
