TCP 健康检查怎么做
TCP 健康检查只需与检查端口成功建立连接即判定健康，后端进程挂掉时连接被拒、检查立即失败。它适合不解析应用协议的纯四层服务，判断简单也不增加应用侧改动。需要注意的是每次探测都会在后端留下一次短连接记录，数据库代理这类对连接数敏感的后端要评估探测频率带来的开销。
基本信息
| 检查逻辑 | 与检查端口完成 TCP 连接即视为健康 |
|---|---|
| 检查端口 | 默认与后端端口一致，也可以单独指定 |
| 探测开销 | 每次探测都会在后端留下短连接记录（连接数、访问日志） |
| 放通要求 | 安全组与主机防火墙需允许来自负载均衡的探测流量 |
| 局限性 | 进程假死但端口仍监听时，TCP 探测无法发现问题 |
| 适用层次 | 四层监听；七层监听建议使用 HTTP 探测 |
典型使用场景
- 数据库代理、消息队列等非 HTTP 服务的基础可用性判断
- 以进程是否监听端口为唯一健康标准的简单服务
- 后端不方便提供探活接口时的替代方案
- 需要快速确认后端整体不可用（如进程退出）的场景
- 与 HTTP 探测配合：四层监听用 TCP、七层监听用 HTTP
观察后端被探测的连接
观察后端被探测的连接
ss -tan | awk '$4 ~ /:8080$/ {print}' | head
# 统计来源地址：负载均衡的探测会以固定内网网段出现
sudo tcpdump -ni any 'tcp[tcpflags] & tcp-syn != 0 and port 8080' -c 10
# 用于确认探测频率与来源，避免把健康检查流量当作异常流量处置探测结果与判断
| 现象 | 含义 |
|---|---|
| 连接成功 | 判定健康，正常参与流量分配 |
| connection refused | 进程未监听或被防火墙拒绝，判定异常 |
| 连接超时 | 安全组或网络未放通探测来源，判定异常 |
| 连接成功但业务报错 | TCP 探测无法发现，需要改用 HTTP 探测 |
应用日志中出现大量来源为负载均衡网段的短连接通常是健康检查流量，排查时不要当作异常流量处置或加黑名单。
TCP 探测只能确认端口可连，无法识别「进程在但请求处理异常」的假死状态；对可用性要求高的 HTTP 服务建议使用带状态码校验的探测方式。