Apache默认不自动恢复故障节点，必须显式配置retry参数：它定义节点失效后的冷却时间（如retry=60表示60秒内不转发请求），超时后才试探恢复；retry=0则永久离线，需手动干预。
Apache 默认不自动恢复故障节点，必须显式配置 retry 参数
mod_proxy_balancer 不会“定时 ping”或“持续轮询”后端是否已恢复；它只在节点被标记为失效（DOWN）后，静默等待一段冷却时间，到期才尝试下一次请求转发——这便是 retry 的真实含义。没配 retry，节点一旦失败就永久离线（除非手动干预）。
常见错误现象：后端服务已重启，/balancer-manager 页面仍显示 DOWN，流量完全不回来。
-
retry=60表示该节点失败后，60 秒内不参与任何新请求分发；超时后 Apache 会用下一个请求试探它，成功即自动标为 UP -
retry=0是危险值：节点进入 DOWN 状态后永不自动重试，必须通过a2ctl graceful或 balancer-manager 手动启用 - 若后端典型恢复耗时约 8 秒（如 Spring Boot 启动 + Actuator 就绪），建议设
retry=15，留出缓冲余量
健康检查触发的 DOWN 状态，恢复逻辑更严格
仅靠 retry 不足以让主动健康检查（mod_proxy_hcheck）下的节点顺利恢复。Apache 要求两个条件同时满足：连续健康检查成功 + 冷却期结束。这两个条件彼此独立，缺一不可。
典型陷阱：后端刚返回一次 200 OK，但业务接口还没准备好，Apache 却已恢复流量，导致用户看到 502。
-
hcfail=3和hcpass=2搭配时，节点从 DOWN 恢复需先连续通过 2 次检查，且这 2 次之间至少间隔hcinterval（如 10 秒），即至少空等 20 秒才允许首次重试 -
retry=60与hcinterval=10并存时，实际恢复延迟是二者最大值，不是叠加——Apache 取更长的那个窗口 - 务必确认后端
/health端点真实反映业务就绪状态（例如校验数据库连接、缓存连通性），不能只返回静态 JSON
failonstatus + retry 组合才是最实用的被动恢复路径
相比依赖外部健康端点，用 failonstatus 基于真实响应码做判断，更贴近业务异常场景，也更容易对齐开发预期。它和 retry 配合，构成轻量但可靠的被动恢复链路。
容易踩的坑：只配了 failonstatus=503，但没设 retry，结果节点失败后一直卡在 DOWN，页面打不开也查不到日志报错。
-
failonstatus=500-599表示只要后端返回任一 5xx，本次请求即计入失败计数，达到阈值（默认 1 次）就触发retry冷却 - 配合
timeout=5和retry=15，可覆盖超时、502、503、504 等常见故障，无需额外模块 - 注意：
failonstatus判断发生在收到完整响应后，对 TCP 连接拒绝、RST、SYN timeout 类错误无效，这类问题得靠ping或底层网络探测
调试恢复失败，别只盯 balancer-manager 页面
/balancer-manager 显示的是最终状态快照，看不到健康检查是否真发出了请求、收到了什么响应、为什么判定失败。很多“配置明明写了却没生效”的问题，根源都在日志里。
最常被忽略的一点：无论用 retry、ping 还是 mod_proxy_hcheck，都依赖后端真实返回明确的状态码或响应体。如果后端因进程卡死而无响应，或返回了非标准状态码（如 499、000），Apache 就无法按规则决策。
- 开启
LogLevel proxy_hcheck:trace8（Apache ≥2.4.33），在error.log中搜索hcheck关键字，确认探测请求是否发出、耗时多少、响应状态码是什么 - 对
ping探测，加ping_timeout=2显式控制超时，避免默认 1 秒太激进导致误跳过 - 用
curl -I http://backend-ip:port/health手动验证健康端点，确保它稳定返回 2xx 且响应时间 ping_timeout
