# 

有个服务做过一次全量发布，五台后端在十分钟内陆续变成「异常」，负载均衡把流量全部摘掉，用户看到 503。

值班的人第一反应是回滚，回滚之后还是异常。第二反应是查日志，干净得很：没有报错，没有重启，QPS 正常。第三反应是上机器 curl，200，40 毫秒。

服务是好的，健康检查说它死了。这两件事同时成立，说明问题不在服务，在健康检查的判据。

## 默认值到底有多严？

腾讯云负载均衡的健康检查有一组默认值，藏在「高级选项」里。文档原文是这样的：

> 响应超时：健康检查响应的最大超时时间。如果后端云服务器在超时时间内没有正确响应，则判定为健康检查异常。可配置范围：2 - 60秒。默认值：2秒
>
> 检测间隔：负载均衡进行健康检查的时间间隔。可配置范围：2 - 300秒。默认值：5秒
>
> 不健康阈值：如果连续 n 次（n 为填写的数值）收到的健康检查结果失败，则识别为不健康，控制台显示为异常。可配置范围：2 - 10次。默认值：3次
>
> 健康阈值：如果连续 n 次（n 为填写的数值）收到的健康检查结果为成功，则识别为健康，控制台显示为健康。可配置范围：2 - 10次。默认值：3次

把这四个数放在一起看，能得到一个具体的结论：**一个接口只要有三次连续超过 2 秒，这台机器就会被摘掉**。

按默认值算一下时间线：第一次探测超时 2 秒，等 5 秒，第二次超时 2 秒，等 5 秒，第三次超时 2 秒。从第一次探测开始到判定异常，大约 16 秒。

16 秒。这个数字很多人没概念。一次 Full GC、一次连接池冷启动、一次磁盘 IO 抖动、一次慢查询——任何持续十几秒的事情，都足够让一台健康的机器被摘出去。

## 服务是好的，为什么健康检查会失败？

三个原因，都不在服务本身。

**第一个：健康检查路径太重。**

默认检查路径是「/」，也就是首页。如果首页会查数据库、拼推荐位、渲染模板，那它天然就是一个慢接口。用「/」做健康检查，等于要求首页在 2 秒内稳定返回，这个要求比业务 SLA 还高。

文档里其实给了提示：

> 检查路径：默认为 /，且必须以 / 开头。不支持正则表达式，建议指定某个固定 URL 路径（静态页面）进行健康检查。

「建议指定某个固定 URL 路径（静态页面）」这句话，直译就是「别用首页，用一个静态的、不查任何东西的路径」。

**第二个：探测源 IP 不在白名单里。**

文档写得很明确：

> 健康探测源 IP：健康检查探测包的源 IP，默认为 100.64.0.0/10 网段，使用该网段可以有效避免地址冲突。

注意这个网段。它不是负载均衡的 VIP，也不是你的内网网段，是一个专门的保留网段。

如果后端机器的安全组只放行了「负载均衡 VIP」，或者只放行业务网段，那探测包会被直接丢掉。表现是「所有后端同时异常」，而且服务日志里一条记录都没有——请求根本没进来。

这类故障特别有迷惑性：一次安全组收紧，业务端口放行得好好的，唯独忘了这个探测网段。改完之后页面还能通过内网 IP 访问，只有负载均衡说全部异常。

**第三个：HTTP 版本和 Host 头对不上。**

文档里有一段容易被跳过的说明：

> 当选择 HTTP /1.1 版本时，此时若未配置检查域名，按照 HTTP 标准协议，后端服务器会返回 400 错误码，提示健康检查异常，建议勾选正常状态码 http_4xx。

逻辑很直白：HTTP/1.1 要求带 Host 头，没配检查域名就没有 Host，后端按标准返回 400，健康检查把 400 当失败，于是判异常。

而这个「400 算不算健康」是可以配的：

> 正常状态码：当状态码为所选状态码时，认为后端服务器存活，即健康检查正常。可选：http_1xx、http_2xx、http_3xx、http_4xx 和 http_5xx。

也就是说，健康检查不是只能认 200。一个需要鉴权的内部接口返回 401、一个不存在的路径返回 404，都可以被声明成「健康」。

## 服务正常却被判死，通常卡在哪三处？

把上面三个原因和排查方法放在一起，就是一张值班时能直接用的表：

| 现象 | 可能原因 | 怎么确认 |
| --- | --- | --- |
| 全部后端同时异常，服务日志无请求 | 探测源 IP 被安全组拦了 | 看安全组是否放行 100.64.0.0/10 |
| 部分后端异常，异常的时间点分散 | 响应超时 2 秒太紧 | 在后端手动计时健康检查路径 |
| 异常状态一直不恢复，curl 却正常 | HTTP 版本与 Host 头不匹配，返回 400 | 看后端访问日志里的 400 与健康检查来源 |
| 刚发布就异常，几分钟后自愈 | 冷启动期间首次探测超时 | 对照发布时间与异常时间 |

这张表里最值得记住的是第一行。因为它的特征太干净了：**所有后端同时异常，而且服务端一条请求日志都没有**。

如果所有后端同时异常，但日志里能看到探测请求，那是判据问题（超时、状态码）。如果连日志都没有，那是包没到（安全组、网络 ACL）。这两条分岔口，能省掉很多时间。

## 在后端怎么验证健康检查到底慢在哪？

不要靠猜。在机器上把健康检查路径单独跑一遍，加上耗时：

```bash
# 连跑 20 次，看最慢的那几次有多慢
for i in $(seq 1 20); do
  curl -s -o /dev/null -w '%{http_code} %{time_total}\n' \
    -H 'Host: your.domain.com' http://127.0.0.1/healthz
done | sort -k2 -n | tail -5
```

如果最慢的几次超过了 2 秒，而中位数只有几十毫秒，那就是「偶发慢」把它拖死的典型形态。这种接口在压测里完全看不出来，因为压测看的是平均值和 p99，而健康检查看的是「连续三次」。

再看一眼后端是谁在访问健康检查：

```bash
# nginx 侧：把健康检查的请求单独挑出来看状态码和耗时
awk '$9 >= 400 {print}' /var/log/nginx/access.log | tail -20

# 只看探测来源网段的请求（如果日志里记了 $remote_addr）
grep -E '^100\.(6[4-9]|[7-9][0-9]|1[01][0-9]|12[0-7])\.' /var/log/nginx/access.log | tail -5
```

第二段的正则对应 100.64.0.0/10 这个网段。如果在日志里能看到这个来源的请求，说明探测包进来了，问题在响应；如果一条都没有，问题在包被拦。

## 健康检查到底该检查什么？

这是整件事最核心的判断：**健康检查检查的是「这台机器能不能接流量」，不是「这个业务是否完全正常」**。

两者的差别在于，前者只依赖本机，后者会依赖数据库、缓存、下游服务。

如果数据库写进健康检查会怎样：数据库抖一下，所有后端同时判异常，流量被全部摘掉，用户从「部分慢」变成「全部 503」。一个下游的小故障被放大成了全站故障。

我现在的写法是三层分开：

| 层次 | 检查什么 | 失败后的动作 |
| --- | --- | --- |
| 健康检查 | 进程活着、端口能连、返回 200 | 摘流量，让别的机器接 |
| 就绪判断 | 依赖是否可用（DB、缓存） | 不摘流量，只告警 |
| 业务监控 | 错误率、延迟、成功率 | 告警，人工介入 |

第一层要极轻，最好是「不查任何外部依赖，直接返回 200」。第二层放在应用内部做熔断和降级，不要交给负载均衡。第三层交给监控系统。

这个分工的理由很简单：摘流量是很重的动作，只该由「这台机器坏了」触发，不该由「共享依赖抖了」触发——依赖抖的时候，摘掉所有机器没有帮助。

## 参数要不要调？

默认的 2 秒超时对大部分 Web 服务是合适的，因为它能快速发现真故障。但如果你的服务有明显的冷启动、有明显的 GC 停顿，调参数是合理的。

调的时候注意两件事：

第一，**响应超时要和检测间隔一起看**。文档给的默认是 2 秒超时、5 秒间隔，也就是每 7 秒一轮探测。把超时调到 5 秒，一轮就变成 10 秒，判定异常的最坏时间从 16 秒变成 30 秒。能不能接受，取决于业务对故障切换的要求。

第二，**不健康阈值调高，等于延长故障机器的服务时间**。从 3 次调到 5 次，一台真挂了的机器会多接几十秒的流量。对无状态服务问题不大，对有状态或者写操作重的服务，这几十秒可能产生脏数据。

所以调参的正确顺序是：先把健康检查路径做轻，再看要不要动参数。大部分「健康检查误判」其实是路径太重，不是参数太严。

## 发布前该确认哪四件事？

这几项不复杂，但漏一项就可能出现「服务好好的，负载均衡说全挂」：

| 检查项 | 具体看什么 |
| --- | --- |
| 探测源网段 | 安全组是否放行 100.64.0.0/10，或已切换为自定义源 IP 并放行 |
| 检查路径 | 是否是静态轻量路径，是否会被鉴权/重定向拦截 |
| 正常状态码 | 后端返回 3xx 或 401 时，是否已勾选对应状态码 |
| HTTP 版本与域名 | 用 1.1 时是否配了检查域名，避免稳定返回 400 |

再加一条：发布之后的头两分钟，盯着健康检查的状态变化，而不是只看业务指标。异常出现的顺序往往能说明问题——全部同时异常，先怀疑包没到；逐台陆续异常，先怀疑超时。

我把这几项写成了一份上线前检查表，和网络策略、快照恢复那几项放在一起。表是用 AI墨衍 把几次故障复盘的记录归拢成文档的，判据还是逐条对着官方文档核过，因为这类默认值一旦记错，排查方向会整个偏掉。

顺便问一句：你们的健康检查路径，返回 200 之前查了几个依赖？超过一个，它其实已经不是健康检查了。


有个服务做过一次全量发布，五台后端在十分钟内陆续变成「异常」，负载均衡把流量全部摘掉，用户看到 503。

健康检查超时默认只有 2 秒：一批后端同时被判死，不一定是服务真挂了

编程语言

**负载均衡健康检查误判致服务下线：默认2秒超时+3次失败即摘除，16秒内误杀正常节点。常见诱因：探测路径过重、安全组未放行100.64.0.0/10源IP、HTTP/1.1缺失Host致400。建议采用轻量静态路径，分层检查依赖，发布前核对四项配置。**

云服务器

负载均衡

代码解释

数据库

服务器

Nginx

热销域名限时优惠，新客首年免费！


domain

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

健康检查超时默认只有 2 秒：一批后端同时被判死，不一定是服务真挂了-腾讯云开发者社区-腾讯云

健康检查超时默认只有 2 秒：一批后端同时被判死，不一定是服务真挂了

健康检查超时默认只有 2 秒：一批后端同时被判死，不一定是服务真挂了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐