Apache mod_proxy_hcheck仅支持HTTP/HTTPS协议探测，不支持TCP、gRPC、Dubbo等自定义协议；需通过后端暴露HTTP健康端点、外部探测同步状态或前置协议适配网关实现兼容。
apache mod_proxy_hcheck **不支持自定义协议**的健康检查探测。
它只工作在 HTTP/HTTPS 协议栈上
该模块设计目标明确：专用于 HTTP 反向代理场景下的后端节点主动探测。所有健康检查请求都基于标准 HTTP 方法（GET、HEAD）发起，依赖完整的 HTTP 解析流程——包括状态行、响应头、可选响应体，以及 TLS 握手（当后端为 HTTPS 时）。它无法发送原始 TCP 数据包、gRPC 请求、Dubbo 协议帧、Redis PING 命令或任何非 HTTP 的二进制/文本协议载荷。
遇到非 HTTP 后端怎么办
若后端服务使用自定义协议（如 Thrift、MQTT、私有 TCP 长连接服务等），不能直接用 mod_proxy_hcheck 探测。可行路径是：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
让后端暴露一个轻量 HTTP 健康端点：例如
/health-protocol，由业务代码主动检测底层协议连通性与核心逻辑（如能否成功发起一次 mock RPC 调用、能否订阅到 MQTT 主题、能否执行 Redis PING 并收到PONG），再统一返回200 OK或结构化 JSON；Apache 通过hcmethod=GET hcuri=/health-protocol探测这个桥接接口即可。 -
禁用
mod_proxy_hcheck，改用外部探测 + 状态同步：用独立脚本（如 Python +socket/paho-mqtt/thrift客户端）定期探测自定义协议，并将结果写入本地文件或 Redis；再通过 Apache 的mod_rewrite+mod_proxy_balancer的status=+H或status=-H手动标记节点健康状态。 -
前置一层协议适配网关：在自定义协议服务前加一个轻量网关（如 Envoy、Nginx Stream + Lua、或自研 Go 代理），该网关对外提供标准 HTTP
/health接口，并对内完成协议转换与连通性验证；Apache 则只和这个网关通信。
为什么不能扩展支持自定义协议
mod_proxy_hcheck 深度耦合于 Apache 的 HTTP 处理管线（ap_process_http_connection）、连接池管理（proxy_conn_rec）及响应解析器（ap_rgetline 等）。它没有抽象出“协议插件”机制，也不提供 C API 允许第三方注入自定义探针逻辑。其配置项（如 hcmethod、hcuri、ProxyHCExpr）全部围绕 HTTP 语义定义，无字段可指定序列化格式、超时单位、握手步骤或 payload 内容。
不复杂但容易忽略：健康检查不是越底层越好，而是要和业务可用性对齐。HTTP 桥接层看似多一跳，实则把协议细节收口、可观测性拉齐、故障归因更清晰。
