mod_proxy_hcheck仅支持http/https等协议的主动请求探测，不支持纯tcp端口存活探测；其hcmethod参数无tcp选项，无法仅检查端口连通性，必须完成完整http事务。
mod_proxy_hcheck 不支持纯 TCP 端口存活探测（如 telnet 或 socket 连通性检测），它只支持基于 HTTP/HTTPS 协议的主动请求探测。所谓“TCP 探测”在 Apache 官方文档和实际模块行为中并不存在——hcmethod 只接受 HTTP、HTTPS、OPTIONS、HEAD、GET（2.4.55+），没有 TCP、TCP-CONNECT 或 raw socket 类型。
为什么不能用 mod_proxy_hcheck 做 TCP 探活
该模块设计目标是模拟真实业务请求，依赖 mod_watchdog 提供定时调度，并通过 HTTP 客户端发起请求、解析响应状态与内容。它不调用底层 socket connect() 或 send/recv，因此：
- 没有 hcmethod=tcp、hcmethod=connect 等参数选项
- 无法仅检查端口是否 open（比如后端进程僵死但端口仍监听）
- 所有健康检查都必须走完整 HTTP 事务：建立连接 → 发送请求 → 等待响应 → 解析状态码或 body
替代方案：用被动检查 + retry 模拟 TCP 层感知
若后端服务不提供 /health 等 HTTP 接口，但能响应基础 HTTP 请求（哪怕返回 502），可借助被动机制间接反映 TCP 可达性：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 设置 ProxySet timeout=3 retry=5：连接超时 3 秒，失败后 5 秒内不转发请求——这相当于对 TCP 建连失败做快速回避
- 配合 failonstatus=502,503,504：这些状态码通常由 mod_proxy 在无法连接后端或等待超时时生成，可触发自动重试计数
- 虽非主动 TCP 探测，但实际效果接近：连续建连失败 → 被标记为 temporarily down → 流量绕过
真要实现 TCP 端口探测，得换工具
Apache 本身不内置 TCP 心跳能力。可行路径有：
-
外部脚本 + balancer-manager API：用 curl 或 nc 定期检测端口，再调用
/balancer-manager?w=balancer://xxx&action=enable或disable手动干预节点状态 - 结合 keepalived 或 consul-template：在负载均衡前置层做 TCP check，动态更新 Apache 的 BalancerMember 列表（通过 include 或配置热重载）
- 降级使用 mod_proxy_balancer 的默认行为：不启用 hcheck，仅靠 failonstatus + retry 实现“请求级故障隔离”，对多数 Java 微服务已够用
小结：别强求 mod_proxy_hcheck 做 TCP 事
它本质是 HTTP 健康检查模块，不是网络探针。想确认端口是否存活，就暴露一个轻量 HTTP 健康接口（如 /health 返回 200）；若实在做不到，就用被动策略兜底，或把 TCP 探测交给更合适的组件完成。
