Apache mod_proxy_balancer 不支持时间窗口调度和带宽限流，需借助 mod_rewrite（配合 TIME_HOUR 等变量）实现时段路由，以及 mod_ratelimit 或 mod_qos 实现限流，二者可叠加使用且须在请求转发前生效。
Apache mod_proxy_balancer 本身不原生支持基于时间窗口的流量调度或带宽限流。它专注后端节点健康探测、请求分发与会话粘滞，而时间维度控制（如“早8点到晚10点走A集群，其余时间走B集群”）和字节级带宽限制（如“单IP每分钟限10MB”）需借助其他模块协同实现。
下面分两类说明具体落地方式：
时间窗口流量调度：用 mod_rewrite + 系统时间变量
Apache 提供 %{TIME_HOUR}、%{TIME_MIN}、%{TIME_WDAY} 等环境变量，可结合 RewriteCond 实现按小时、星期甚至分钟粒度的路由切换。
-
在
<VirtualHost>或全局配置中启用重写引擎：RewriteEngine On
-
示例：工作日 9:00–18:00 流量导向
balancer://prod-day，其余时间走balancer://prod-night# 工作日白天（周一至周五，9–18点） RewriteCond %{TIME_WDAY} ^[1-5]$ RewriteCond %{TIME_HOUR} ^09|1[0-7]|18$ RewriteRule ^/(.*)$ balancer://prod-day/$1 [P,L] # 其余时间走夜间集群 RewriteRule ^/(.*)$ balancer://prod-night/$1 [P,L]
⚠️ 注意：
-
TIME_HOUR是两位字符串（如"09"），匹配需用正则，不能直接比数字； - 所有
BalancerMember必须提前在<Proxy "balancer://...">块中定义； - 切换是实时生效的，无需 reload，但规则顺序影响结果，建议把精确条件放前面。
带宽限流：用 mod_ratelimit 或 mod_qos（非 balancer 模块）
mod_proxy_balancer 不处理响应体限速，真正起作用的是：
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
mod_ratelimit：对每个响应强制限速（单位：bytes/second），适合静态资源或统一降速场景<Location "/api/"> SetOutputFilter RATE_LIMIT SetEnv rate-limit 51200 # 限 50KB/s </Location>
-
mod_qos（第三方模块）：更精细，支持按 IP、URL、Header 组合限流，含时间窗口计数（如“每分钟最多100次 /login 请求”）
需单独编译加载，典型配置：# 限制 /login 每分钟最多 100 次 QS_LocRequestLimitMatch "^/login" 100 60
若需出向带宽总控（如整个 Apache 出口限 100Mbps），应交由系统层（如 Linux tc）或前置硬件负载均衡器处理，Apache 层不适合做网络层限速。
关键协同要点
-
时间调度与限流可叠加使用，例如：
RewriteCond %{TIME_HOUR} ^2[2-3]|0[0-5]$ RewriteRule ^/api/.*$ - [E=OFFHOURS:1] <Location "/api/"> QSS_ReqPerSec 10 QSS_ReqPerSec 50 env=!OFFHOURS # 非深夜放宽到50QPS </Location> 所有限流策略都应在
ProxyPass或RewriteRule [P]之前生效，否则请求已转发至后端，限流就失去意义；生产环境务必开启
ProxyStatus或/balancer-manager页面（需授权），实时观察各BalancerMember的Current Load和Elected计数，验证时间规则是否按预期触发。
不复杂但容易忽略。
