节点被标记为down后请求仍被拒绝，通常因下线逻辑未生效或后续请求命中异常状态，需从配置、日志、健康检查三方面排查：确认balancer-manager中节点真实状态（down/err/dis/ok），查errorlog中connection refused等proxy错误，验证failonstatus和retry是否正确配置在proxypass及balancermember行，检查是否有兜底503拦截失效。
节点被标记为 down 后请求仍被拒绝，通常不是“没下线”，而是下线逻辑未生效或后续请求仍命中了异常状态。排查要从配置、日志、健康检查三方面入手，重点确认是否真被隔离、为何隔离失败、以及有没有兜底机制。
检查 balancer-manager 界面确认节点真实状态
访问 /balancer-manager 页面（需已启用并授权），查看目标节点的当前状态：
- 状态显示为 DOWN：说明已被主动禁用，但需进一步确认是否还在 retry 冷却期内；
- 状态为 ERR 或 DIS：表示健康检查失败或手动 disable，但可能因
retry值过大导致长期不恢复； - 状态仍是 OK：说明
a=disable请求未成功执行，或 POST 参数缺失（如漏掉lf=1导致新状态无法激活）； - 节点条目存在但灰显/无响应计数：可能是后端进程已僵死，但 Apache 还未触发超时判定。
查 ErrorLog 中 proxy 模块报错线索
在 Apache 错误日志中搜索与该节点 IP/端口相关的错误，重点关注以下关键词：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
Connection refused或Connection reset by peer：后端进程已退出或端口未监听； -
proxy: error reading status line from remote server：JVM OOM 后卡死，能接受连接但无法返回完整响应头； -
failonstatus=503触发记录：说明后端返回了预设错误码，但需核对ProxyPass行是否真带了该参数； - 反复出现
retrying on another node：说明负载均衡器正在重试，但所有节点都不可用，最终返回 503。
验证 failonstatus 和 retry 配置是否生效
这两个参数决定节点是否及时下线及下线后能否恢复。常见疏漏点：
-
failonstatus必须写在ProxyPass行末尾，且仅对balancer://协议有效，例如：ProxyPass / balancer://mycluster/ failonstatus=503,500； -
retry=60是每个节点独立设置的，应加在BalancerMember行里，如：BalancerMember http://10.0.1.5:8080 retry=60； - 若
retry设为 0，节点一旦失败将永久标记为 DOWN，不会自动恢复； - 未配
timeout或keepalive，JVM 全局停顿（如 GC）可能导致请求堆积，Apache 误判为连接失败而非响应延迟。
确认是否有兜底路径拦截 503
当所有节点都处于 DOWN 或 retry 状态时，mod_proxy_balancer 默认返回 503。如果用户看到的是连接拒绝（如 curl 报 Connection refused），说明问题不在 balancer 层，而是：
- Apache 自身未监听对应端口（
netstat -tlnp | grep :80验证）； - 防火墙或 SELinux 阻断了代理出向连接（
ausearch -m avc -ts recent查看）； - 你用了
ErrorDocument 503 /maintenance.html，但没开ProxyErrorOverride On，导致页面仍走代理而非本地返回； - 想跳转维护页却用了
RewriteCond %{REQUEST_STATUS} ^503$——这个变量在 mod_rewrite 中不可用，正确做法是用RewriteCond %{ENV:balancer_worker_route} ^$或直接靠ErrorDocument。
