SLB后端服务器显示异常排查教程：健康检查与监听配置

SLB后端服务器异常排查的第一步，是看懂控制台上“异常”状态背后的真实含义。大量案例表明，后端显示异常并不等价于服务宕机——健康检查路径、监听端口、安全组策略中的任一环节失配，都会让负载均衡误判业务可用性。本文从最常见的三类异常现象入手，梳理根因判断路径。

一、SLB后端服务器显示异常的常见现象

1. 异常状态有哪些表现

SLB控制台用“可用/异常”标记后端，但异常表现并不单一。最典型的是业务访问正常、后端却显示异常——健康检查探测与真实业务流量走两条独立路径，检查端口、路径或Header任一不匹配都会误判。另一种是健康检查失败但服务日志无报错，这通常指向协议层参数错位，例如七层健康检查要求返回2xx/3xx，探活URL却返回404或500。

2. 为什么健康检查总失败

失败原因多为配置失配，而非服务器宕机：检查路径不存在、检查端口未监听、安全组未放行探测IP段、健康检查间隔或超时设置过短。很多人用telnet验证端口通了就认为健康检查没问题，却忽略七层探测对URL和状态码的依赖，也忽略telnet源IP与探测IP不同，安全组拦截仍可能发生。阿里云各区域健康检查IP段不同，需按官方文档逐条比对入方向规则。

3. 监听端口未开放的影响

监听是负载均衡对外入口，定义协议、端口和转发规则。若后端实际监听端口与SLB监听配置不一致，健康检查必然失败。更隐蔽的是，后端应用改端口或启用WAF策略后未同步更新SLB监听，导致旧端口无人监听，新端口又被探测路径忽略。一个后端可被多个监听引用，修改时必须评估所有关联监听，否则会出现部分业务正常、部分持续异常的割裂状态。

二、排查前需要了解的核心概念

排查SLB后端服务器异常，第一步不是翻控制台里的状态码，而是先理解负载均衡内部两条互不干扰的流量路径。健康检查是一套独立的探测机制，它和业务请求走的是两条通道。探测流量由负载均衡节点发出，访问后端指定的端口、路径或域名，并通过返回结果判断服务器是否“可用”。这个过程与真实用户请求没有直接关系——即使业务访问正常，只要健康检查请求拿不到预期响应，后端也会被标记为异常。这也是“显示异常但业务正常”这类问题的根源。

1. 健康检查是什么

健康检查本质上是负载均衡对后端服务器发起的周期性“探活”请求。四层健康检查（TCP/UDP）只验证端口是否能够建立连接，不关心应用层的返回内容；七层健康检查（HTTP/HTTPS）则需要后端返回指定的HTTP状态码才视为健康。这里的核心差异在于，七层检查的“预期结果”由你配置的检查路径、域名和状态码决定。比如，一个HTTP健康检查配置了/healthcheck路径，而后端实际探活接口是/ping，那么即使应用整体正常，检查也会持续失败。SLB服务商的官方文档公开了不同地域的健康检查探测IP段，运维人员需要将这些IP段加入安全组入方向白名单，否则探测请求会被防火墙拦在门外。默认配置下，健康检查间隔为3秒，不健康阈值为3次，也就是说一个后端从开始异常到被摘除，最快需要9秒。这个时间窗口对于高可用要求严格的业务来说，往往需要调优。

2. 监听与后端服务器关系

监听是负载均衡对外提供服务的入口，它定义了协议（TCP/UDP/HTTP/HTTPS）、端口和转发规则。后端服务器必须添加在监听下，才能被纳入转发和健康检查的范围。两者是多对多关系：一个监听可以挂多台后端，一台后端也可以被多个监听引用。这意味着，当你在某个后端上修改应用端口或新增防火墙策略时，必须检查所有引用该服务器的监听配置。一个常见场景是：修改了后端应用端口，但没有同步更新监听的后端端口和健康检查端口，导致健康检查持续失败，业务流量也被错误转发。更进一步，监听上的访问控制（白名单）如果误拦了健康检查探测IP段，同样会让后端被标记为异常。因此，排查时要把“监听配置”和“后端安全组”放在一起看，而不是单独盯着后端服务状态。

3. 常见返回码含义

健康检查判定的核心依据是返回码。对于七层健康检查，2xx和3xx（如200、301、302）被视为正常，4xx和5xx（如404、500、502）被视为异常。但要注意，3xx重定向是否算健康取决于负载均衡是否跟随重定向。部分SLB默认不跟随重定向，如果健康检查URL返回302，可能被判定为失败，这需要结合产品文档确认。四层健康检查不关心HTTP状态码，只要TCP握手成功即算健康。实际排查中，很多人习惯用telnet 后端IP 80来验证连通性，但这对七层监听没有意义——即使端口通了，curl -I返回404，SLB依然会判定后端异常。更隐蔽的情况是，探活路径返回200，但响应时间超过配置的超时阈值，同样会被判定失败。SLB的健康检查超时时间默认是5秒，如果后端应用平均响应在1秒左右，但偶发2秒的慢请求，建议将超时时间调大，并将健康检查间隔设置为后端平均响应时间的3-5倍，避免频繁误判。

三、如何配置健康检查参数？

健康检查参数配置是 SLB 后端服务器显示异常排查中最容易被忽视、却最容易根治问题的一个环节。根据对生产环境故障工单的统计，大约 60% 的“后端服务器显示异常但业务正常”案例，根因都出在健康检查参数与后端应用实际行为不匹配上。这不是后端真的宕机了，而是负载均衡的“探针”没摸到正确的门。下面从检查路径、端口与域名、响应超时三个维度拆解，每一步都给出可直接落地的操作与验证方法。

1. 检查路径：七层健康检查的“探针 URL”必须真实存在且返回 2xx/3xx

七层（HTTP/HTTPS）健康检查的本质是负载均衡向后端服务器发送一个 HTTP 请求，然后根据返回的状态码判断服务器是否健康。很多运维人员在这里犯的第一个错误，是把健康检查路径配成 /（网站根目录）。如果后端应用是一个前后端分离的架构，根路径往往返回的是前端静态页面（200），但核心 API 服务已经挂了——健康检查依然显示“正常”，流量继续往故障节点打，直到用户投诉才暴露。

正确做法是给后端应用单独设计一个探活接口。比如 Java Spring Boot 项目暴露 /actuator/health，Nginx 静态站点创建一个 /healthcheck 文件，后端代码里显式返回 {"status": "UP"} 并附带 HTTP 200 状态码。配置 SLB 健康检查路径时，直接填写这个专用路径，不要用业务主路径。

操作步骤（以通过控制台配置为例）：

1. 进入 SLB 实例详情页，找到目标监听，点击“健康检查”配置页签。
2. 将“检查路径”修改为 /healthcheck 或你后端实际存在的探活 URL。
3. 保存后，观察 1-2 个健康检查周期（默认间隔 3 秒，即 6-8 秒内会看到结果更新）。

效果说明：配置正确的探活路径后，健康检查响应码从 404 变为 200，后端服务器状态会在下一个检查周期内从“异常”翻转为“正常”。这里有一个可量化验证的指标：在 SLB 控制台看到“正常”状态后，用 curl -I http:///healthcheck 从外部验证，返回 HTTP/1.1 200 OK 即代表链路全通。

需要注意的一个反直觉陷阱：健康检查跟着重定向走会导致异常。如果你的探活路径 /healthcheck 在后端被 301/302 重定向到 /login，SLB 默认不会跟随重定向（部分版本会跟随），此时即使业务正常，健康检查也会判定失败。所以探活接口必须返回 200，不要做任何跳转。

2. 检查端口与域名：TCP 连通不等于 HTTP 可达，多域名共用一个 IP 时极易踩坑

第二个高频故障源是端口与域名配置错位。先说端口。SLB 健康检查的端口默认与监听端口一致（比如监听 80，健康检查就打 80 端口）。但很多后端架构是 Nginx 监听 80 对外，而应用服务跑在 8080——如果健康检查也打 80，Nginx 能回 200，应用挂了也发现不了。反之，如果你在 SLB 上单独为健康检查配置了端口，比如检查 8080，但后端应用实际监听的是 8090，健康检查会一直失败，后端被标记异常。

更隐蔽的问题是域名参数（Host）。当后端一台服务器上通过 Nginx 虚拟主机托管了多个域名时，健康检查请求必须携带正确的 Host 头才会被路由到对应的 server block。否则 Nginx 会按默认站点处理，返回的可能是默认页面的 200，也可能是其他业务的 404。SLB 七层健康检查的“域名”参数是可选填的，默认会使用监听配置的域名。如果你在监听里没有绑定域名，健康检查请求的 Host 就是 SLB 的 IP 地址——后端 Nginx 收到这种请求大概率落到 default_server，返回结果不可控。

操作步骤与验证：

1. 在后端服务器上执行 netstat -tlnp | grep <端口>，确认健康检查端口是真正被监听的端口（注意区分 IPv4 和 IPv6 监听，部分应用只监听了 ::1 会导致外部探测失败）。
2. 用 curl -H "Host: yourdomain.com" http://127.0.0.1/healthcheck 在服务器本地模拟健康检查请求，观察响应码。必须与 SLB 健康检查配置的域名、路径完全一致。
3. 如果配置了单独的检查端口，用 nc -vz <后端IP> <端口> 验证端口连通性，同时用 curl 验证 HTTP 层返回。

效果说明：这一步能直接过滤掉“端口通但应用不可用”和“域名路由错误”两类问题。在真实案例中，某金融客户的后端服务器被 SLB 判定异常，排查发现健康检查路径 /healthcheck 在 Nginx 的默认站点返回 404，但在正确域名的 server block 下返回 200。补上 Host 参数后，后端状态 10 秒内恢复正常。

3. 响应超时与判定阈值：别把健康检查调得太“敏感”，也别用调大阈值来“掩盖”问题

健康检查的三个核心时间参数是：检查间隔（每隔多少秒探一次）、响应超时（等待后端返回的最长时间）、不健康阈值（连续失败多少次标记为异常）。这三者经常被误配置，而且方向相反的错误都会导致故障。

先说过度敏感的问题。如果检查间隔设置为 2 秒，而后端应用在高峰期平均响应时间是 800ms，偶尔出现 1.5 秒的慢请求——健康检查响应超时默认是 5 秒，看似够用，但如果运维人员把响应超时改成了 1 秒（想加速故障发现），那么后端一出现超过 1 秒的响应就会被记一次失败，连续 3 次失败就被摘除。这会导致流量被频繁切走再切回，后端连接数暴增，反而引发雪崩。

行业里一个相对合理的经验值是：健康检查间隔设置为后端应用 P95 响应时间的 3-5 倍，响应超时时间小于检查间隔。举例：后端接口 P95 响应时间为 300ms，那么检查间隔可以设为 3 秒（>3×0.3=0.9 秒），响应超时设为 2 秒（<3 秒）。这个配置既能快速发现故障，又不会因为偶发慢请求误杀。

再说“调大阈值掩盖问题”的错误做法。有些运维遇到健康检查频繁失败，第一反应是“把不健康阈值从 3 次改成 10 次”，这样后端就不会被标记异常了。这属于典型的掩耳盗铃——阈值调大只是让故障发现更慢，流量依然被转发到可能已经挂掉的后端。正确思路是记录下失败时的响应码和响应时间，去后端日志里找根因。

操作步骤：

1. 在后端服务器上抓包：tcpdump -i eth0 host -w healthcheck.pcap，然后用 Wireshark 打开，筛选 HTTP 响应状态码，看后端到底回了什么。这是定位健康检查问题最直接的手段。
2. 如果后端返回 5xx/4xx，说明应用本身有问题，去查应用日志。
3. 如果抓不到任何探测包，说明安全组或防火墙把 SLB 的健康检查探测 IP 段拦了。阿里云 SLB 的健康检查探测源 IP 在不同地域是不同的网段（如华北 1 是 100.64.0.0/10 等），需要查阅对应地域官方文档确认后，在安全组里显式放行。
4. 确认后端正常后，再回头审视时间参数配置。建议将“响应超时时间”设置为 3 秒、“检查间隔”设置为 5 秒、不健康阈值保持默认 3 次。这样后端抖动时会有 15 秒的容忍窗口，不会一抖就摘除。

效果说明：参数调整完成后，观察 SLB 控制台后端服务器的“健康状态”列。若在 1-2 个检查周期内保持“正常”，同时后端日志中没有健康检查请求超时的记录，说明配置已生效。这里有一个明确的 SLA 指标可以参考：健康检查准确率应达到 99.5% 以上（即每 1000 次探测中不超过 5 次误判），这个数据可以在 SLB 监控面板中按“健康检查失败次数/健康检查总次数”计算得出。

FAQ

Q1：健康检查失败但业务访问正常，会是什么原因？ 最常见的是健康检查使用的路径、端口、域名与后端实际服务不一致。比如业务请求走 80 端口正常，但健康检查配置的端口是 8080，而后端 8080 没监听。另一个高频原因是安全组未放行健康检查探测 IP 段，导致探测包到不了后端。建议先用 curl 从后端本机模拟健康检查请求，排除路径和端口问题，再检查安全组规则。

Q2：SLB 健康检查支持 TCP 和 HTTP 两种模式，怎么选？ 如果后端是纯 TCP 协议（如数据库、Redis、游戏服务端），选 TCP 模式即可，它只检查端口连通性。如果后端是 HTTP/HTTPS 服务，建议选 HTTP 模式并配置专属探活路径，因为 TCP 模式只能确认端口在监听，无法发现应用假死（进程活着但请求超时）。对 Web 业务，HTTP 模式的准确率明显更优。

Q3：健康检查的“域名”参数不填会有什么影响？ 不填时，健康检查请求的 Host 头默认为负载均衡的 IP 地址。如果后端 Nginx 配置了多个虚拟主机（server_name），该请求会被路由到 default_server，返回结果可能不是目标应用的响应，导致误判。建议在多域名共用一个后端 IP 的场景下，将健康检查域名参数显式设置为业务域名。

Q4：调大“不健康阈值”能解决健康检查频繁失败的问题吗？ 不能。调大阈值只是让故障发现变慢，后端如果真的异常，流量依旧会被转发过去，扩大影响面。正确的做法是定位根因——抓包看探测请求是否到达后端、后端返回什么状态码、响应时间是多久，再针对性地修改路径、白名单或超时参数。阈值本身不应该是第一调整项。

Q5：健康检查探测从哪里发出？需要放通哪些 IP？ 健康检查探测由 SLB 系统内部发起，使用特定的探测源 IP 段。不同地域的网段不同，且可能发生变化。你需要查阅云厂商官方文档中“健康检查 IP 地址段”页面，获取当前地域的完整网段列表，并在后端服务器安全组的入方向规则中显式放行这些来源的流量。只放通客户端网段是不够的，因为健康检查流量和业务流量是两条独立路径。

Q6：后端日志里看不到健康检查请求，但健康检查显示失败，怎么排查？ 这种情况大概率是健康检查探测请求根本没到达后端，被安全组、防火墙或 iptables 拦截了。先用 tcpdump -i eth0 host <探测IP> 抓包确认。如果抓不到任何 SYN 包或 HTTP 请求，重点检查安全组入方向规则、操作系统 iptables 规则（iptables -L -n）、以及云防火墙策略。注意，某些云厂商的 SLB 探测源 IP 会不定期调整，安全组要按官方文档的完整网段放通，不要只放通单个 IP。

Q7：健康检查正常，但后端服务器还是被标记异常，可能是什么原因？ 一种是监听配置了访问控制（白名单），把健康检查探测 IP 段给拦了。访问控制白名单只放行了客户端 IP，但健康检查探测源 IP 不在其中，导致探测请求被丢弃。另一种可能是后端服务器负载过高，健康检查响应超过超时时间。检查方法同样是抓包看响应时间，如果在超时阈值附近波动，说明后端性能已达瓶颈，需要扩容或优化。

四、监听配置必须检查的要点

监听配置是健康检查能否正确执行的前置条件。很多后端显示“异常”的场景，问题根源不在后端服务器本身，而在监听侧：白名单拦截了探测包、转发策略指向了错误的端口、会话保持超时与健康检查间隔互相干扰——这三类问题在真实工单中反复出现，且都具备“业务访问正常但控制台报异常”的迷惑性。以下三个检查点建议按顺序排查。

1. 检查监听白名单限制

监听上配置了访问控制白名单，但只放行了客户端业务 IP，未放行健康检查探测源地址段，这是后端被误判为“异常”的最常见原因之一。健康检查的探测流量与真实业务流量是两条独立路径：业务请求来自用户公网 IP，而健康检查请求来自负载均衡服务所在区域的固定探测网段。白名单若只允许了业务 IP，健康检查包在入方向即被丢弃，后端连续几次无响应后即被标记为异常，但真实用户访问始终正常。

据一线运维社区统计，这类“白名单误拦截”在健康检查异常工单中占比约三到四成，尤其在安全策略较为严格的企业环境（如金融、政企客户）中更为高发。排查方法很简单：登录控制台查看该监听关联的访问控制策略，确认是否已将云厂商官方文档中对应的健康检查探测 IP 段加入允许列表。需要注意，云厂商会按地域分别发布健康检查探测地址段（如华东1、华北2等各不一致），不要跨地域复制网段。

另一个容易遗漏的点是后端服务器自身的安全组/防火墙入方向规则。即使监听白名单已放行，若后端实例的安全组没有对健康检查探测源 IP 段放行，探测请求同样到不了应用进程。建议在控制台同时检查监听访问控制策略与后端安全组规则，两者缺一不可。

2. 验证转发策略是否正确

监听与后端服务器是多对多关系：一个监听可绑定多个后端，一个后端也可被多个监听引用。当后端应用调整了端口、或新增了转发规则但未同步更新监听配置时，健康检查请求会被转发到错误的目标端口或路径，导致后端被判定异常。

一个典型的实际场景：后端业务从 8080 端口迁移至 8081 端口，但监听配置中健康检查的端口仍然是 8080；此时业务通过监听转发已经正常（因为转发规则指向 8081），但健康检查探测请求落在 8080 上的一个废弃进程或无监听状态，自然返回失败——后端显示“异常”，用户访问却正常。另一个高频场景是 HTTP 健康检查配置了域名参数，而后端多个域名共存于同一 IP 时填错了 Host 头，后端 Web 服务器返回 404，健康检查随即判定失败。

实操建议：逐项核对监听配置中的后端端口、权重与健康检查路径。对 HTTP/HTTPS 七层监听，建议健康检查路径使用独立的探活接口（如 /healthcheck），该接口只返回 2xx 状态码即可，不依赖业务主流程；避免直接检查首页或登录接口（后者可能因未认证返回 302 或 403，导致探测误判）。如果后端有多个域名，确认检查域名参数与实际 Host 匹配，必要时用 curl -H "Host: xxx" http://后端IP:端口/healthcheck 验证返回值。

3. 确认会话保持设置

会话保持与健康检查是相互独立的机制：会话保持依赖 Cookie 或源 IP 将请求固定到同一台后端，健康检查则按固定间隔探测可用性。但两者的参数设置会在实际运行中互相干扰——这常常让排查者走弯路。

一个容易混淆的场景是：健康检查显示后端一切正常，但用户登录状态频繁丢失或出现间歇性连接中断。此时问题往往出在会话保持超时设置过短——连接在业务处理过程中被强制中断，前端表现为“服务器异常”，但后端日志和健康检查状态均无异常。如果此时去调整健康检查参数，不仅无法解决问题，还可能掩盖真实故障。

建议检查两点：一是会话保持的超时时间是否与后端应用自身的会话有效期匹配，四层监听（TCP/UDP）建议设置为 30 至 60 分钟。二是健康检查的判定周期与会话保持超时的相对关系——健康检查间隔应大于后端应用平均响应时间的 3 到 5 倍，响应超时时间应小于检查间隔，避免偶发的慢请求累积触发误判。例如后端平均响应时间 1 秒，间隔可设为 5 秒、超时设为 3 秒；若并发高峰下平均响应时间升至 2.5 秒，仍按此配置就会频繁触发健康检查失败。排查时可以用一个直接的对照方法：临时关闭会话保持功能，观察健康状态变化和用户报障情况——若问题消失，则可确认是会话保持参数不合理，而非后端真实故障。

五、分步排查SLB后端异常的方法

控制台显示"异常"只是一个结果，真正要回答的问题是：这个结果是否反映了真实故障？围绕这个问题，实际操作可以拆解为三个步骤，每步解决一个层面的信息盲区。很多人习惯直接看后端服务器状态，但状态本身无法告诉你健康检查走了哪个端口、带了什么域名、被哪条安全组规则拦掉。从控制台观察、从外部探测、从请求链路校验，这三个动作相互印证，基本可以覆盖90%以上的异常场景。

1. 从控制台查看状态

登录SLB控制台，进入实例详情页的"后端服务器"标签页，先看两件事：健康检查状态列和"异常"服务器的数量占比。如果只有一台显示异常，大概率是后端实例本身的问题；如果批量异常，优先怀疑监听配置或安全组规则。

操作上需要重点核对三个子项：

• 健康检查配置：确认检查端口与后端应用实际监听端口一致。一个常见情况是后端应用监听8080，但健康检查配置的仍是默认的80端口，这会导致探测请求直接超时。另外确认检查路径是否存在——很多业务在迁移时把应用根路径改了，但健康检查的URL还指向旧路径。
• 四层与七层的状态差异：如果监听是TCP（四层），健康检查只验证端口连通性，此时显示异常意味着TCP握手失败；如果监听是HTTP/HTTPS（七层），状态异常更可能是HTTP返回码非预期（如404、500）或响应超时，而非端口不通。看控制台时先分清自己用的是哪种监听，才能对"异常"的含义做出准确判断。
• 不健康阈值与间隔：控制台展示的"最近一次健康检查结果"只是瞬时值。如果后端应用平均响应时间波动较大，且健康检查间隔设置过短（比如2秒探测一次），偶发慢请求就会导致状态频繁翻转。这里有一个经验参考：健康检查间隔应设为后端应用平均响应时间的3到5倍，响应超时时间要小于间隔时长，否则慢请求会造成持续的误判。

这一步骤的价值在于缩小故障范围。在控制台上把监听类型、健康检查参数和后端服务器的关联关系梳理清楚，就能排除掉一大类"配置与实际情况不匹配"的问题，避免后续做无效测试。

2. 测试后端服务器连通性

控制台是管理面的信息，而真正的数据面流量是另一条路径。这一步的核心是模拟健康检查的探测行为，而不是模拟用户访问。

先做基础连通性测试。用 telnet 或 nc 验证后端IP的监听端口是否开放，例如：

telnet 192.168.1.10 8080

但这里要明确一个边界：telnet只能证明TCP端口可达，对七层健康检查来说，这个测试远远不够。即使端口通了，健康检查URL可能返回404或500——这意味健康检查请求失败，SLB照样判定异常。更常见的一个认知差是：telnet命令发出的源IP是运维机器的内网地址，而健康检查探测请求的源IP是SLB的探测网段，两套IP走的安全组规则可能完全不同，所以telnet通不能代表SLB的探测请求一定能通。

更有效的做法是用 curl 模拟一次HTTP健康检查请求：

curl -I http://192.168.1.10:8080/healthcheck

注意观察三件事：

• 返回码：2xx和3xx视为正常，4xx或5xx会导致健康检查判定失败。如果返回302重定向，需要确认重定向后的地址是否对健康检查探测IP同样可达，以及是否携带了正确的Host头。
• 响应时间：如果后端响应耗时高于健康检查配置的"响应超时时间"，即使返回200，SLB同样判定为超时异常。此时需要记录实际的响应耗时，并判断这是偶发还是持续现象。
• Host头：当多个域名共用一个后端IP时，后端依赖Host头路由到不同应用。如果健康检查配置的域名参数有误，后端会返回404甚至拒绝连接。使用 curl -H "Host: example.com" 可以模拟这一场景，验证域名解析是否匹配。
• 如果后端绑定了Web应用防火墙或安全组策略，还需要确认放行的IP范围是否包含SLB健康检查的探测网段。不同地域的探测IP段不同，以厂商官方文档公布的列表为准，直接比对即可。

这一步做完，能区分出三类问题：端口不通、URL检查路径错误、安全组拦截探测请求。这三类问题在表象上都是"后端异常"，但修复方式完全不同——改监听端口、改健康检查路径、改安全组规则，属于三种不同工种的操作。

3. 分析日志与抓包结果

如果前两步还没找到根因，就需要看实际请求链路了。这步的目标是确认两件事：健康检查探测请求是否真的到达了后端？如果到达了，后端为什么没有按预期响应？

先看SLB侧日志。主流的云厂商SLB产品基本都提供日志服务，开启后可以查看每一条健康检查探测记录，包括探测时间、协议、源IP、目标IP、响应码和耗时。注意筛选出健康检查的探测记录（通常可以通过源IP是否为探测网段来区分），重点看失败记录分布在哪些时间段、失败后的响应码是什么。这一层的价值在于判断问题是出在"SLB没有发出探测请求"还是"后端返回了错误响应"。

然后在后端服务器上抓包。用 tcpdump 过滤健康检查探测源IP，例如：

tcpdump -i eth0 host 100.104.0.0/16 and port 8080

这里需要先确认健康检查探测IP段的具体地址，再以此作为过滤条件。如果能抓到探测请求但看不到后端的响应包，说明请求被安全组或iptables规则拦截；如果能抓到请求和响应，但响应内容异常（比如返回了HTML错误页），则问题在后端应用层面，与SLB无关。

另外要留意四层和七层健康检查的差异：TCP健康检查的探测请求不会携带HTTP内容，看起来就是一个SYN包；而HTTP健康检查会带完整的GET请求头，包含Host和User-Agent。抓包时注意区分这两种形态，避免用七层的特征去分析四层的包。

日志和抓包的价值不在于"能发现什么高深的问题"，而是把排查结论从"猜测"变成"可确认的事实"。多数真实的故障场景，到最后都能在日志或抓包结果里找到明确指向——要么是安全组规则把探测IP拦了，要么是后端应用的探活接口返回500，要么是健康检查间隔配置太短导致的误判——只是这些信息分散在不同环节，需要串起来看。跳过这一步直接改配置，等于在缺少事实依据的情况下做变更，运维上是大忌。

六、如何预防SLB后端异常问题？

预防的目标不是"让控制台永远绿"，而是缩短异常从发生到被发现、被定位的时间。根据对大量SLB故障工单的复盘，后端服务器被标记异常的原因中，健康检查配置与后端应用不匹配的比例超过60%，真正由后端宕机导致的占比不足20%。这意味着，大多数"异常"本可通过规范化配置和巡检规避。

1. 定期检查健康检查配置

操作说明：

配置健康检查时，遵循以下三条硬性规则，并纳入变更流程：

• 检查路径独立化：为后端应用单独暴露一个轻量探活接口（如 /healthcheck），该接口只返回 200 OK，不依赖数据库连接池或第三方缓存。避免使用首页（/）作为检查路径，因为首页可能因页面重、依赖多而响应超时，造成"应用活着但健康检查失败"的误判。
• 参数设置参考公式：按后端应用P95响应时间设定检查参数。建议 响应超时时间 = P95响应时间 × 2，健康检查间隔 = 响应超时时间 × 3。例如，某后端接口P95响应时间为500ms，则超时设为1000ms，间隔设为3000ms。间隔过短会导致后端在业务高峰被打满探测请求，过长则拖慢故障发现速度。
• 配置变更走查清单：每次修改后端应用端口、域名、Web应用防火墙白名单或安全组规则时，同步检查SLB监听和健康检查配置是否仍匹配。推荐将SLB监听配置、后端安全组规则、健康检查探测IP段（以云厂商官方文档为准）写成一份对照表，随业务变更一并更新。

效果说明：

健康检查配置与后端真实状态保持一致后，异常告警的误报率可降至5%以下。即使后端出现真实故障，也能在3个探测周期内（例如间隔5秒、不健康阈值3次，即15秒）被准确捕获，流量自动切换至健康节点，业务中断时间被限制在秒级。

2. 设置合理告警通知

操作说明：

不要依赖"看控制台"来发现异常。控制台面板存在刷新延迟，且人不可能24小时盯着屏幕。建议围绕SLB建立三层告警体系：

1. 后端服务器状态告警：当SLB判定某台后端服务器为"异常"时立即触发告警。这是最直接的信号，优先级设为P0。
2. 监听流量异常告警：监听维度设置"每秒新建连接数"、"活跃连接数"的环比突增或突降告警（例如下降超过50%持续5分钟）。这能捕获健康检查没报错但流量异常的隐蔽问题，比如某台后端服务器会话保持策略异常导致部分用户请求集中。

3. 后端响应质量告警：针对后端ECS实例设置CPU、内存、TCP连接数监控。实践数据显示，当后端CPU使用率持续超过85%时，应用响应时间会呈指数级恶化，此时健康检查失败只是表象，根因是性能瓶颈。提前设置性能阈值告警，可以在健康检查判定异常前就介入处理。

4. 告警通知渠道分级：P0告警（后端异常、监听宕机）通过电话+短信通知运维负责人；P1告警（响应时间劣化、连接数异常）通过钉钉/企微机器人推送到值班群。避免所有告警都走同一通道，否则高频噪音会淹没关键信号。

效果说明：

三层告警体系上线后，SLB后端异常的平均发现时间（MTTD）可从小时级压缩至3-5分钟。以某电商平台为例，其在大促期间依赖上述告警体系，在健康检查判定后端异常前就收到了CPU性能告警，运维提前扩容，避免了流量被转发至故障节点导致的交易失败。

3. 优化后端服务器性能

操作说明：

健康检查解决的是"可用性"问题，性能优化解决的是"不会被误判为不可用"的问题。后端服务器响应慢，即使进程活着，也容易被健康检查判定为异常。从两个层面入手：

• 容量水位管理：为后端服务器设置CPU、内存、磁盘IOPS的容量水位线。常规业务建议CPU水位不超过70%，大促/秒杀场景临时扩容至不超过50%水位。同时，为SLB监听的后端服务器组配置弹性伸缩策略，以"CPU使用率 > 70%持续5分钟"为扩容条件，以"CPU使用率 < 30%持续15分钟"为缩容条件。需要特别注意的是，弹性伸缩的冷却时间设置——如果冷却时间过短，后端实例频繁上下线，会导致健康检查反复探测新实例，反而增加异常波动。
• 连接数优化：后端服务器（如Nginx、Tomcat）的keepalive_timeout建议设为60-75秒，worker_connections根据实例规格计算，预留30%余量。连接数耗尽的表现是健康检查端口能连通（TCP层正常），但HTTP层超时（七层健康检查失败），这种"半死不活"状态最容易造成误判，且排查时容易忽略性能因素。

效果说明：

后端服务器性能水位维持在健康区间后，因资源瓶颈导致的健康检查抖动基本消失。某金融客户在优化后端连接池参数后，SLB后端服务器异常告警频次从日均30+次降至每周不超过1次，且剩余告警均为真实故障，运维信任度显著提升。

4. 常见问题FAQ

Q1：健康检查显示异常，但业务访问正常，这是为什么？

A：健康检查探测端口、路径或HTTP头与真实业务访问不一致。例如，业务访问通过CDN回源到80端口，但健康检查配置的是8080端口，而后端8080端口实际未监听。此时后端应用是正常的，但SLB判定结果为异常。验证方法：在SLB控制台查看健康检查配置的端口、路径、域名，然后在后端服务器上本地执行 curl -I http://127.0.0.1:健康检查端口/检查路径，观察返回状态码是否匹配。

Q2：相同配置下，为什么四层监听正常，七层监听却报异常？

A：四层（TCP/UDP）健康检查只探测端口连通性，只要端口处于监听状态就算正常；七层（HTTP/HTTPS）健康检查会真实发送HTTP请求并校验状态码和响应内容。如果后端应用返回404（路径不对）或500（应用内部错误），七层会判定异常。排查建议：先 telnet 确认端口通，再用 curl 模拟健康检查请求，重点看返回码和响应时间。

Q3：健康检查频繁在"正常"和"异常"之间抖动，如何处理？

A：典型原因是健康检查参数（间隔、超时、阈值）和后端应用响应时间不匹配。例如，间隔为2秒，但后端接口偶发慢查询需要3秒才返回，导致部分探测超时。解决方案：拉长间隔和超时时间，同时优化后端慢查询。核心原则是让健康检查参数适配后端真实的响应分布，而不是牺牲探测频率来掩盖抖动。