Apache通过mod_proxy_balancer和mod_proxy_hcheck实现动态故障隔离，配置hcmethod、hcuri等参数可主动探测后端健康状态，连续失败则自动标记Down并剔除节点，支持手动干预与主被动双机制容错。
Apache 本身不直接做“流量隔离”，而是通过负载均衡机制实现**动态故障隔离**——当后端节点异常时，自动停止转发请求，从而达到保护核心业务、避免雪崩的效果。关键不在“隔离流量”，而在“识别异常 + 快速剔除 + 安全恢复”。 以下是实操中真正起效的配置要点：
必须启用的核心模块
缺一不可，尤其注意版本兼容性：
- mod_proxy：提供代理基础能力
- mod_proxy_balancer：实现负载分发与成员管理（2.4 默认未启用，需手动加载）
- mod_proxy_hcheck（Apache ≥2.4.33）：支持主动健康检查（推荐，比被动更及时）
- mod_status：/balancer-manager 页面依赖它，否则打不开管理界面
主动健康检查配置（推荐用于核心业务）
在
- hcmethod=HTTP：用 HTTP 请求探测（也可选 TCP 或 SSL）
-
hcuri=/health：后端必须暴露该路径，返回 2xx 才算健康（如 Spring Boot 的
/actuator/health） - hcinterval=5：每 5 秒探测一次（核心业务建议 ≤10 秒）
- hcfail=2：连续 2 次失败即标记为 Down
- hcpass=2：连续 2 次成功才恢复为 Up
示例：
<proxy balancer:> BalancerMember http://10.0.1.10:8080 route=node1 hcmethod=HTTP hcuri=/health hcinterval=5 hcfail=2 hcpass=2 BalancerMember http://10.0.1.11:8080 route=node2 hcmethod=HTTP hcuri=/health hcinterval=5 hcfail=2 hcpass=2 </proxy>
被动容错增强（补主动之不足）
主动检查无法覆盖所有异常场景（如瞬时超时、慢响应、500 内部错误），需叠加被动策略：
- retry=30：节点被标记为 Down 后，30 秒内不尝试重试（防止反复试探失败服务）
- failonstatus=500,502,503,504：任意一次请求返回这些状态码，就计入失败计数
- loadfactor=3 和 loadfactor=1：按能力分配权重，降低问题节点初始流量占比
这样即使某次健康检查“侥幸”通过，后续真实请求失败仍会快速触发隔离。
验证与应急干预手段
上线后务必确认三项：
- 访问
http://your-apache/balancer-manager，检查各节点状态是否实时更新（Down/Up）、失败次数是否增长 - 手动 curl 后端
/health端点，模拟返回 503，观察 Apache 是否在 10 秒内将其标为 Down - 出问题时可立即在 balancer-manager 页面点击 “Mark as Down” 或 “Mark as Up”，无需重启 Apache
注意：/balancer-manager 默认仅允许 localhost 访问，生产环境需严格限制 IP 范围，例如：Require ip 192.168.10.0/24
不复杂但容易忽略
