mod_proxy_hcheck不支持自定义健康检查请求头，因其探测请求由内部硬编码构造且未暴露配置指令；替代方案为外部脚本调用balancer-manager接口动态标记节点状态，或后端适配无头健康端点。
apache mod_proxy_hcheck 本身不支持直接为健康检查请求添加自定义 http 请求头（如 x-health-check: true 或 authorization）。这是该模块的明确限制——它发起的探测请求（get、head、options）由内部硬编码构造，**无法通过配置项注入额外 header**。
为什么不能配自定义请求头？
这是设计使然：mod_proxy_hcheck 的健康探测逻辑聚焦于轻量、快速、无副作用的连接层或应用层可达性验证。所有请求头均由模块内部生成（如 User-Agent: Apache-HTTP-Client/2.4、Host 等必要字段），未暴露 hcheader 或类似指令。试图在 BalancerMember 行中加 headers="..." 或用 RequestHeader 指令干预，均无效——那些指令只影响业务代理请求，不作用于健康检查探针。
替代方案：用外部探测 + 手动标记（推荐）
当后端健康端点要求特定请求头（如 API 密钥、租户标识、Bypass 认证）才能返回有效响应时，必须绕过 mod_proxy_hcheck 的原生探测，改用外部脚本完成检查，并通过 balancer-manager 接口动态标记节点状态：
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 写一个轻量 shell/Python 脚本，用
curl -H "X-API-Key: abc123" http://10.0.1.10:8080/health发起带头请求，解析响应并判断是否健康 - 脚本根据结果调用 Apache 的
balancer-managerHTTP 接口（需启用且受保护）：curl -X POST "http://localhost/balancer-manager?b=api&w=http://10.0.1.10:8080&status=+H"（标记为健康）curl -X POST "http://localhost/balancer-manager?b=api&w=http://10.0.1.10:8080&status=-H"（标记为不健康） - 用
cron或 systemd timer 每 5–10 秒运行一次脚本，实现准实时同步
替代方案：后端适配（更简单）
如果可修改后端服务，建议在健康端点层面兼容无头访问：
- 让
/healthz接口对缺失认证头的请求也返回200 OK（仅用于基础设施探活），而将带认证的健康检查留给更严格的/readyz或运维接口 - 或在反向代理层（如 Apache 前再加一层 Nginx）先注入所需 header，再把请求转给 Apache；但此时 Apache 的
hcheck实际探测的是中间层，非真实后端，监控链路变长
注意 ProxyPass 中的 RequestHeader 不起作用
常见误区是以为在 <Location> 或全局配置里加：RequestHeader set X-Health-Check "true" early
这只会作用于被 ProxyPass 转发的用户请求，完全不影响 mod_proxy_hcheck 自动发出的探测请求。两者走的是完全不同的请求处理路径。
