> 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/modify-health-check.md).

# 修改健康检查

监听器的健康检查监控其后端服务器的状态，确保负载均衡器仅将流量路由到健康且准备好处理请求的服务器。

您可以启用或禁用**配置健康检查**以激活或停用健康监控。

启用健康检查后，负载均衡器会自动将不健康的服务器从流量分发中移除，并在其恢复后重新加入。

## Fail-Open（可选）

启用 **Fail-Open**，即使所有后端服务器均未通过健康检查，也允许流量继续转发到所有服务器。此功能有助于维持服务的连续性。

{% hint style="info" %} <mark style="color:blue;">**注意**</mark>

<mark style="color:blue;">Fail-Open 仅在部分地区可用，请以实际可用情况为准。</mark>
{% endhint %}

## 健康检查协议

您可以根据应用需求选择以下协议之一进行健康检查。

### TCP

**TCP 健康检查**验证后端服务器是否能在指定端口上接受 TCP 连接。

* 不检查应用层响应
* 适用于通用 TCP 服务
* 常用于数据库、文件传输服务和自定义 TCP 应用

**适用场景：**\
您只需确认服务端口可达。

#### 检查端口

指定用于 TCP 健康检查的端口。

* 如不填写，检查端口默认为后端服务器的服务端口。
* 仅可指定一个端口。

在以下情况下使用自定义端口：

* 健康检查运行在与服务端口不同的端口上。
* 专用的健康检查端点单独暴露。

#### 更多设置

* **超时时间**\
  定义负载均衡器等待健康检查响应的最长时间。若在此时间内未收到响应，则视为检查失败。
  * 范围：**1–15 秒**
  * **示例：** `2 秒`
* **重试次数**

  将后端服务器标记为不健康所需的连续重试次数。

  * 范围：**1–5 次**
  * **示例：** `2 次`
* **重试间隔**\
  健康检查失败后，重试尝试之间的间隔。
  * 范围：**1–15 秒**
  * **示例：** `2 秒`
* **检查间隔**\
  定期健康检查尝试之间的间隔。间隔越短，故障检测越快，但探测流量也越多。
  * 范围：**3–30 秒**
  * **示例：** `3 秒`

### HTTP

**HTTP 健康检查**向后端服务器上的指定路径发送 HTTP 请求，并评估响应结果。

* 检查应用层可用性
* 支持状态码验证（如 200 OK）
* 对 Web 服务和 API 更为准确

**适用场景：**\
您需要验证应用本身是否正常运行，而不仅仅是端口是否可达。

#### 请求路径

指定用于健康检查的 HTTP 路径，例如：

```bash
/
/health
/status
```

* 该路径必须在后端服务上可访问。
* 建议使用专用于健康检查的轻量级端点。

#### 检查端口

指定用于 HTTP 健康检查的端口。

* 如不填写，检查端口默认为后端服务器的服务端口。
* 仅可指定一个端口。

在以下情况下使用自定义端口：

* 健康检查运行在与服务端口不同的端口上。
* 专用的健康检查端点单独暴露。

#### 更多设置

* **超时时间**\
  定义负载均衡器等待健康检查响应的最长时间。若在此时间内未收到响应，则视为检查失败。
  * 范围：**1–15 秒**
  * **示例：** `2 秒`
* **重试次数**

  将后端服务器标记为不健康所需的连续重试次数。

  * 范围：**1–5 次**
  * **示例：** `2 次`
* **重试间隔**\
  健康检查失败后，重试尝试之间的间隔。
  * 范围：**1–15 秒**
  * **示例：** `2 秒`
* **检查间隔**\
  定期健康检查尝试之间的间隔。间隔越短，故障检测越快，但探测流量也越多。
  * 范围：**3–30 秒**
  * **示例：** `3 秒`

#### HTTP 状态码

指定表示后端健康的预期 HTTP 响应码。

常用值：

* `200` — 标准成功响应
* `2xx` — 任何成功响应（如支持）

如果后端返回不同的状态码，则健康检查失败。

### PING

**PING 健康检查**通过发送 ICMP echo 请求验证基本的网络可达性。

* 仅测试网络层连通性
* 不验证服务或应用状态

**适用场景：**\
您希望确认后端服务器在网络层是否可达。

#### 更多设置

* **超时时间**\
  定义负载均衡器等待健康检查响应的最长时间。若在此时间内未收到响应，则视为检查失败。
  * 范围：**1–15 秒**
  * **示例：** `2 秒`
* **重试次数**

  将后端服务器标记为不健康所需的连续重试次数。

  * 范围：**1–5 次**
  * **示例：** `2 次`
* **重试间隔**\
  健康检查失败后，重试尝试之间的间隔。
  * 范围：**1–15 秒**
  * **示例：** `2 秒`
* **检查间隔**\
  定期健康检查尝试之间的间隔。间隔越短，故障检测越快，但探测流量也越多。
  * 范围：**3–30 秒**
  * **示例：** `3 秒`


---

# 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/modify-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.
