> 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).

# 负载均衡器健康检查

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

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

![健康检查状态机](/files/0sr0Y6frA9kiXUCu3970)

## 探测类型

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

| 类型           | 功能                                                                                              |
| ------------ | ----------------------------------------------------------------------------------------------- |
| `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`）。禁用后，无论可达性如何，每台后端始终被视为符合调度条件。

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.console.zenlayer.com/welcome/cn/elastic-compute/load-balancing/05-health-check.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.