> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/cn/elastic-compute/load-balancing/05-health-check.md).

# 负载均衡器健康检查

健康检查器持续探测监听器池中的每台后端服务器，并更新各后端的健康状态。不健康的后端从调度中移除；已恢复的后端重新纳入。这正是将静态虚拟机列表转化为自愈池的机制。

健康检查按监听器独立运行。出现在两个监听器中的同一台虚拟机会被探测两次——每次使用各自监听器的配置——如果两个监听器探测不同的端口，该虚拟机可能在一个监听器中健康，在另一个中不健康。

![健康检查状态机](https://2318250923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0CBWy7DFFtkhyEC9R4kE%2Fuploads%2Fgit-blob-aa35ea2bbcc0c5cc66e068b1f49cf65dae1e473f%2Fhealth-check-flow.svg?alt=media)

## 探测类型

每个监听器可配置四种探测类型：

| 类型           | 功能                                                                                              |
| ------------ | ----------------------------------------------------------------------------------------------- |
| `TCP_CHECK`  | 向后端的检查端口建立 TCP 连接。成功 = 完成握手。探测在握手后立即关闭连接。                                                       |
| `HTTP_GET`   | 向配置的路径发送 HTTP `GET` 请求，并将响应状态码与预期值（如 `200`）进行比较。成功 = 状态码匹配。`http_protocol` 可配置，支持 HTTP 和 HTTPS。 |
| `MISC_CHECK` | 运行平台提供的自定义探测。用于 TCP 和 HTTP 探测无法满足需求的服务。请联系[支持团队](mailto:support@zenlayer.com)进行配置。              |
| `PING_CHECK` | 向后端发送 ICMP echo 请求。作为*服务*健康检查几乎没有用处——虚拟机能响应 ping 并不代表其服务正常。尽可能优先使用 `TCP_CHECK` 或 `HTTP_GET`。    |

### 如何选择探测类型

* **`TCP_CHECK`** 是任意 TCP 服务的默认选择。它验证后端能够接受连接，但*不*验证服务是否真正在处理请求——卡死的后端可能仍能接受连接而不处理它们。
* **`HTTP_GET`** 是 HTTP 或 HTTPS 服务的正确选择。指向一个专用的 `/healthz` 端点，仅在服务能够处理真实流量时返回 200。这能捕获 `TCP_CHECK` 遗漏的卡死服务情况。
* **`MISC_CHECK`** 是自定义逻辑的逃生通道——脚本可以执行任何操作，从特定协议握手到查询下游依赖。
* **`PING_CHECK`** 仅在没有其他选择时使用。它检查主机可达性，而非服务可达性。

## 探测参数

每个监听器的健康检查通过以下参数配置：

| 参数                    | 默认值    | 说明                                                   |
| --------------------- | ------ | ---------------------------------------------------- |
| **EnableHealthCheck** | 开启     | 是否为此监听器运行健康检查器。                                      |
| **CheckPort**         | `0`    | 要探测的端口。`0` 表示"与后端端口相同"。如需在与服务端口不同的端口上探测健康端点，可设置为非零值。 |
| **DelayLoop**         | `10 秒` | 探测间隔。                                                |
| **ConnectionTimeout** | `3 秒`  | 等待探测成功的最长时间，超时则计为失败。                                 |
| **RetryCount**        | `1`    | 将健康的后端标记为不健康所需的连续失败次数。                               |
| **DelayRetry**        | `3 秒`  | 初次失败后重试尝试之间的间隔。                                      |
| **HttpCheckUrl**      | —      | `HTTP_GET` 使用：请求的路径（如 `/healthz`）。                   |
| **HttpStatusCode**    | `200`  | `HTTP_GET` 使用：预期的响应状态码。                              |

### 参数选择建议

* **DelayLoop** — 更频繁的探测可以更快检测到故障，但会产生更多流量。对于启动时间较长的服务，较短的间隔能让新添加的后端更快开始接收流量（只有成功探测后才符合条件）。对大多数服务而言，`10 秒` 是合理的选择。
* **ConnectionTimeout** — 应明显高于后端的正常响应时间。过紧的超时会在负载高峰期产生误报。
* **RetryCount** — 更高的重试次数使检查器对瞬时故障更宽容，但会延迟真实故障的检测。在嘈杂环境中，两到三次是常见的折中值；对于稳定的后端，一次即可。
* **HttpCheckUrl** — 指向专用的健康端点，而非面向用户的路由。该端点应检查服务中真正重要的部分（数据库可达、依赖项正常），并仅在能够处理真实流量时返回 200。

***

## 状态转换

后端经历四种有效状态：

| 状态        | 是否接收新流量？ | 进入条件                         |
| --------- | -------- | ---------------------------- |
| 健康        | 是        | 当前探测成功，且之前的探测也成功。            |
| 探测中 / 重试中 | 是（仍视为健康） | 探测失败，但 `RetryCount` 次重试尚未耗尽。 |
| 不健康       | 否        | 失败探测 + 重试耗尽——后端从调度中移除。       |
| 恢复中       | 否（仍被排除）  | 不健康后端，下一次探测待执行。第一次成功即重新纳入。   |

**进入不健康状态。** 健康的后端在第一次失败时进入*探测中*状态。在重试运行期间（由 `DelayRetry` 分隔）保持此状态。一旦 `RetryCount` 次连续失败累积，后端被标记为*不健康*并从调度中移除。进行中的连接继续运行，但不会调度新流量。

**恢复中。** 不健康的后端继续按正常的 `DelayLoop` 间隔被探测。一次成功的探测即重新纳入——恢复侧没有"需要多次成功"的阈值。如果您希望更严格的恢复条件，可以提高 `DelayLoop`，使单次成功代表更长的稳定窗口。

## 全部失败时的回退

当监听器中的所有后端同时未通过健康检查时，可能出现两种情况：要么所有后端确实都已宕机（不太可能但可能发生），要么健康检查本身出了问题（探测目标错误、中间防火墙规则变更等）。监听器有一个可配置的响应方式：

| `HealthTreatFailure` 值 | 行为                                        |
| ---------------------- | ----------------------------------------- |
| `0`（默认——强制失败）          | 后端保持标记为不健康。不调度新流量；服务向客户端返回错误。             |
| `1`（视为健康）              | 即使探测失败，所有后端也被视为健康并参与调度。流量按正常方式分发，同时您进行排查。 |

**如何选择：**

* **强制失败**对大多数服务更安全——如果所有后端确实都已宕机，向它们发送流量也毫无用处。
* **视为健康**适用于全服务中断比提供可能有问题的响应更糟糕的场景——并确保您有告警在该条件触发时通知您，因为从服务的角度来看，症状不会很明显。

此设置仅在*所有*后端都不健康时生效。如果有任何一台后端健康，流量就会发往健康的后端，与回退值无关。

## 隔离与恢复行为

* **不健康的后端仍保持其现有连接。** 当后端未通过探测时，LB 不会中断活跃流量——它只停止调度*新*流量。现有连接继续运行，直到正常关闭或空闲超时清理。如果后端确实已宕机，这些连接将在应用层失败。
* **已恢复的后端在下一次调度决策时开始接收新流量。** 调度器在每个新流上重新评估；一旦后端健康，它就开始被选中。
* **权重和持久化与健康状态存在交互。** 在会话持久化开启时，已恢复的后端可以接收新的*可粘性*流量，但现有指向其他后端的粘性条目不会移动。使用 `wIc` 时，以权重 3 恢复的后端将从零活跃流量开始，可能短暂吸引不成比例的份额，直到计数重新平衡。

## 禁用健康检查

您可以完全禁用监听器的健康检查（`EnableHealthCheck = 0`）。禁用后，无论可达性如何，每台后端始终被视为符合调度条件。

仅在有其他机制管理后端成员资格时才禁用——例如，根据自身存活信号添加和移除后端的控制系统。否则，宕机的后端将持续接收流量，直到您察觉为止。