上海阿里云代理商：阿里云SLB健康检查异常排查：端口、网络、应用状态一步到位

当你负责的web服务因一台ECS异常离线，用户端的报错往往不是“某台服务器故障”，而是成片的502/504。这种大面积业务中断的背后，大概率是负载均衡的健康检查机制在起作用。快速定位并修复阿里云SLB健康检查异常排查中的关键节点，是恢复服务的第一道门槛。

一、认识SLB健康检查：原理与异常影响

SLB健康检查本质上是负载均衡对后端ECS服务可用性的自动化验证。它通过内网地址定期发送探测请求，源IP固定来自100.64.0.0/10网段，根据后端返回的响应码或连接状态，判断服务器是否正常服务。一旦探测失败，SLB会立即停止向该节点分发流量，避免请求积压和雪崩效应。

这个机制看似简单，但在实际运维中却常常成为排障盲区。多数人理解健康检查只是“看看机器死没死”，事实上TCP、HTTP、HTTPS三种探测方式的判定逻辑差异很大——TCP只看三次握手是否完成，HTTP要求返回2xx/3xx状态码，HTTPS则还需校验证书有效性。一个应用层返回401的URL，就能让整台ECS被踢出集群。

1. 异常表现如何穿透到用户侧

健康检查异常的直接后果是用户请求被转发到剩余健康节点。如果集群规模小或者异常ECS比例过高，流量倾斜会瞬间压垮其他服务器，用户在浏览器端看到的典型表现就是502 Bad Gateway或504 Gateway Timeout错误。

很多时候运维人员的第一反应是排查应用日志，但忽略了SLB控制台的后端服务器健康状态。事实上，阿里云控制台会明确标示每个监听下哪台ECS处于异常状态，以及最后一次健康检查失败的原因简述。这个信息入口比盲查应用日志高效得多，可惜不少团队没养成先看控制台的习惯。

2. 业务连续性在几秒内被打破

当健康检查阈值设置得过于激进，比如连续2次失败就摘除节点，配合3秒一次的探测间隔，意味着一个瞬时网络抖动只需6秒就能让ECS离线。对于每天处理数十万订单的电商系统，6秒的中断足以造成直接营收损失。

这还不是最麻烦的。中小团队通常缺少专职运维，从发现问题、定位到恢复，动辄半小时以上。云服务器、数据库、CDN等多套资源分散在不同厂商，排查时需要来回切换控制台、核对配置，沟通成本极高。缺少专职运维的中小团队，想要云服务器、数据库、CDN资源统一搭建落地，可以参考聚搜云这类一站式云服务方案，减少多厂商对接的繁琐成本，把精力真正聚焦在应用层的健康检查策略调优上。

二、健康检查异常快速诊断流程

大多数业务中断告警的背后，第一落点往往是 SLB 健康检查异常。对运维资源有限的团队来说，即便知道问题出在“端口→网络→应用”这条链路上，也容易在阿里云控制台、安全组、系统防火墙、应用日志之间反复横跳，拉长排障时间。缺少专职运维的中小团队，想要云服务器、数据库、CDN 资源统一搭建落地，可以参考聚搜云这类一站式云服务方案，减少多厂商对接的繁琐成本，让健康检查这类高频问题不再依赖个人经验，而是有一套可复用的排查基线。

1. 如何查看健康检查状态

健康检查的“异常”并不是一个模糊的结论，阿里云 SLB 控制台实际上给出了分层信号，关键在于会看、会串起来。

• 监听维度：在实例详情的监听页，直接可见每个监听的健康检查状态概览，正常/异常以绿色/红色标识。点进监听后，“后端服务器”页会精确到每台 ECS 的健康检查失败次数和原因提示，例如“超时”“连接失败”“HTTP 码不匹配”等。

• 云监控联动：在“云监控”中为“七层监听健康检查异常”和“四层监听健康检查异常”设置报警规则，能第一时间收到异常后端服务器数量变化的通知，而不是等到用户报障。

• 快速定位异常范围：如果某监听下所有后端一起变红，优先检查 SLB 监听配置（端口、健康检查 URL、超时时间）是否与后端一致；仅单台异常，则几乎可以压到那台 ECS 自身上。

很多工程师到这一步就急着去重启应用，实际还有一个关键动作：先记录异常出现时间点，与 ECS 系统日志、应用日志做时间对齐，再动手，否则证据链容易断掉。

2. 必备排查工具介绍

排查不是靠猜，而是分层验证工具的组合。常用的 ping、telnet、curl、strace 各有明确的分工，对应着“端口→网络→应用”三层。

• 端口层验证：从同一 VPC 内其他 ECS 上执行 telnet<健康检查端口>，能快速判断目标端口是否可通。不通时，典型需核对两个地方：阿里云安全组入方向是否允许 100.64.0.0/10 源地址访问该端口，以及 ECS 内部的系统防火墙（iptables/firewalld）是否也放行。经验上，端口不通的案例里，几乎一半是只查了安全组忘了系统防火墙。

• 应用层验证：curl -Iv http://<内网ip>:<端口>/<健康检查路径> 是模拟 SLB HTTP 探测的最直接手段。重点看返回值：2xx/3xx 才是健康检查认可的状态码，401/403 往往意味着健康检查 URL 要求登录鉴权，需要调整路径。如果返回 504 或者连接被拒，说明应用处理卡顿或未监听在正确地址（0.0.0.0 而非 127.0.0.1）。

• 超时原因深挖：当异常提示“响应超时”，但 curl 偶尔能通或响应慢，可以用 strace -p <进程pid> 跟踪业务进程的系统调用堆栈，观察是卡在磁盘 I/O、外部数据库连接还是锁等待。这一步能避免盲目调大超时阈值掩盖底层瓶颈。

把这三类工具配合使用，可以覆盖九成以上的健康检查异常场景，且不需要进入生产环境瞎试。记录指令结果、截图存档，逐渐形成自己团队的标准排查操作卡，下次告警来临时，一线同事就能按步骤独立定位。

三、端口配置排查：从监听端口到安全组

健康检查异常的根因中，端口不通是最直接、占比最高的故障点。工程师容易陷入一个误区——看到后端ECS标记为“异常”就下意识认为是应用宕机，实际上多数情况只是某个网络节点没有放行健康检查流量。这里的排查不需要复杂的抓包分析，但必须严格遵循“监听端口 → 安全组 → 系统防火墙”的链路，逐层确认每一跳的连通性。

1. 监听端口配置自检

先用一笔简单事实对齐认知：SLB健康检查报文全部走内网，源地址属于 100.64.0.0/10 网段，探测目标就是后端ECS上配置的健康检查端口。因此，第一步不是查安全组，而是确认这个端口到底有没有在监听正确的地址。

• 排查命令：登录ECS执行 ss -tlnp | grep <健康检查端口> 或 netstat -tlnp，重点观察 Local Address 列。如果显示为 127.0.0.1:端口，意味着服务只绑定了回环地址，SLB的内网探测包会被直接丢弃。必须调整为 0.0.0.0 或具体的内网IP。

• TCP与HTTP检查的差别：TCP健康检查只需完成三次握手，端口监听就视为成功；HTTP/HTTPS检查则要求返回 2xx/3xx 状态码。很多排查者发现端口已监听就认为配置无误，却忽略了HTTP检查下健康检查URL的响应码。如果应用对该URL启用了登录鉴权、拦截器，返回 401/403，SLB同样判定为异常。建议为健康检查单独设计一个无需认证的探活路径（如 /health），返回 200 OK 即可。

• UDP检查的特殊性：UDP无连接特性使得端口监听无法直接验证。UD P监听的健康检查依赖ICMP或自定义UDP报文，此时务必确认应用能够处理SLB发送的特定探测字符串，否则会被误判为失败。

2. 安全组规则精细核查要点

确认端口在正确地址上监听后，下一步锁定安全组。阿里云SLB健康检查流量首先经过安全组过滤，这是云上最容易被遗漏的地方。

• 方向决定成败：很多人只查了ECS出方向（Egress）规则，但健康检查流量是入方向（Ingress）。在安全组规则界面，务必切换到“入方向”，并确认健康检查端口已在允许列表中。

• 源地址必须精确匹配：允许的源IP不能随手填一个内网段，而必须覆盖 100.64.0.0/10。实践中更稳妥的做法是直接引用SLB所属的安全组作为授权对象，但这种配置只有同地域内网互通时可行；跨地域或混合云架构下，必须显式填入 100.64.0.0/10 网段，并开放健康检查端口。

• 快速验证技巧：利用同一VPC内另一台ECS执行 telnet <目标ecs内网ip> <健康检查端口>。假如telnet成功，说明链路是通的；不通则几乎可以定位为安全组或系统防火墙问题。切忌从办公网直接telnet云上ECS，因为公有云边界策略通常会拦截这类直接探测。

3. 系统防火墙排查：往往被忽略的最后一关

安全组放行后流量到达ECS内部，还要面对系统自带的包过滤——如iptables、firewalld或Windows防火墙。这是典型的“只查安全组不查系统防火墙”的疏漏区。

• Linux环境：直接执行 iptables -L -n 查看INPUT链规则，关注是否有针对健康检查端口的REJECT或DROP。常见错误是早期运维添加了临时规则未清除。如果使用firewalld，则通过 firewall-cmd --list-all 检查当前zone服务或端口放行策略。对于已配置的规则，可以通过插入临时日志命令来确认是否有健康检查来源的包被丢弃，例如：iptables -I INPUT 1 -s 100.64.0.0/10 -j LOG --log-prefix "SLB_CHECK: "，然后查看 dmesg 或 /var/log/messages。

• Windows Server环境：进入“高级安全Windows Defender防火墙”，验证入站规则中是否有一条允许 100.64.0.0/10 网段访问健康检查端口的规则，且规则优先级未被其他拒绝规则覆盖。

• 三层检查清单中的端口级闭环：完成以上排查后，端口层的三个节点就形成了闭环。此时若问题依旧，就有底气将疑点转向网络路由或应用健康检查逻辑，而不是在端口层反复徘徊。快速排障的纪律永远是：先证明端口可达，再质疑应用状态。

四、网络连通性检查：确保SLB至ECS链路顺畅

健康检查异常的一大类根因并不在ECS本机，而是在中间的网络上。即使后端服务器上的应用正常监听了端口，安全组规则也已放行，依然可能因为VPC路由、子网网关或跨域链路的问题，导致SLB探活报文无法送达。排查网络层时，必须明确一个前提：阿里云SLB的健康检查探测报文全部通过内网发出，源IP来自100.64.0.0/10网段，这意味着所有测试都必须基于后端服务器的内网地址进行，公网连通性与此无关。

1. 用ping与telnet做端口与连通性的快速分诊

网络层排查的第一步永远是验证“可达性”。从同一VPC内的任意一台ECS上执行ping <目标ecs内网ip>，可以快速判断两台机器间的三层路由是否正常。但仅有ICMP畅通还不够，健康检查大概率使用TCP或HTTP协议，必须进一步验证四层端口。用telnet <目标内网ip> <健康检查端口>是最直接的手段——如果连接立即建立（Connected），说明端口可达且路径上安全组和系统防火墙均未阻断；如果长时间无响应或直接Connection refused，则大概率存在防火墙阻拦或服务未监听。

需要注意，Connection refused通常意味着端口根本没有在监听，而连接超时（timeout）则更多指向网络中间设备丢弃了SYN包。如果telnet测试通但健康检查仍异常，往往需要怀疑安全组的规则方向：SLB发出的探测地址是100.64.0.0/10，很多团队在安全组入方向只放行了业务客户端IP段或办公出口IP，忽略了这一内网探测源，导致流量直接被丢弃。因此，排查时应将100.64.0.0/10显式加入安全组白名单，并确认规则优先级未被其他DENY规则覆盖。

2. VPC路由表、对端网关与跨地域链路备忘

当端口层和安全组确认无误，但健康检查依然间歇性或持续失败时，需要进入路由层面的排查。对于单VPC内部的简单部署，通常默认路由即可投递，但如果使用了VPC对等连接、云企业网（CEN）或专线，将有至后端服务器的自定义路由条目，就必须检查路由表的下一跳是否指向正确的目标。典型故障包括：路由目标网段未包含健康检查源IP所在的100.64.0.0/10，导致回程报文走默认路由被丢弃；或者对端VPC的网关设备做了源地址过滤，未放行该预留网段。

跨地域的场景更值得警惕。例如SLB实例在华北地域，后端部分ECS位于华东，通过云企业网打通。此时健康检查报文需要穿越跨地域链路，延迟和丢包率都会上升。如果健康检查超时时间设置得过于严格（如2秒），而跨域RTT已接近阈值，就会产生假异常。实际处置中，我们建议将跨地域后端服务器的健康检查超时时间至少调整为5秒以上，并适当提高不健康阈值，避免因网络抖动造成频繁剔除与加入。

此外，如果后端服务器上配置了多网卡或多路由表（例如作为VPN网关或中转代理），默认路由可能不会将回程流量送回SLB探测源，此时需要配置源策略路由，确保来自100.64.0.0/10的流量原路返回。排查时可以在ECS内部抓包：tcpdump -i eth0 src net 100.64.0.0/10，观察是否收到SYN包，以及是否有RST或未回SYN-ACK的情况。若只收到SYN而无响应，则多半是系统防火墙或内核路由问题，而非单纯网络不通。

总的来说，网络连通性排查的本质是沿着SLB到ECS的报文路径逐跳验证。无论是简单的安全组遗漏，还是隐蔽的路由策略错误，都能通过从内网ping、telnet到抓包的分层手段快速定位。牢记100.64.0.0/10这个探测源网段，并把它作为固定检查项写进网络层清单，可以避免半数以上的网络层误判。

五、应用健康状态验证：服务进程与响应

应用层的健康检查失败，往往在“端口通、网络通”之后才暴露出来——这时问题焦点转移至服务进程本身是否正常、健康检查URL返回的状态码是否符合预期，以及响应时间是否超出了SLB的超时阈值。这三类原因在实际排障中占比极高，但被“端口不通”掩盖的情况也最多，务必先完成端口和网络的确认再进入应用层分析。

1. 服务进程是否运行

并不能因为ps aux | grep看到进程存在就认为服务正常。真正有效的验证是：进程正在监听的地址和端口与健康检查配置完全匹配。很多应用默认监听127.0.0.1，而SLB健康检查通过内网地址发起的请求实际上是访问ECS的私有IP，如果进程未监听0.0.0.0或ECS的内网IP，就会出现“进程活着但健康检查失败”的典型误判。

排查时优先执行netstat -tlnp | grep <端口>，确认Local Address一列是0.0.0.0:端口或内网IP:端口。若发现仅监听127.0.0.1，需修改应用配置（如Nginx的listen指令、Gunicorn的-b参数）并重启服务。对于多进程或容器化部署，可用ss -lntp确认每个工作进程的实际监听状态，避免因主进程存活但子进程已僵死导致的假正常。这一层如果查不出问题，再转向URL返回码与超时。

2. 健康检查URL返回码解读

SLB HTTP/HTTPS健康检查将2xx和3xx状态码视为成功，其余一律视为失败，这是一个刚性规则。常见误区是随意设一个首页路径，但该页面可能重定向到需要登录的地址返回302后又要求认证返回401/403，或者某些API路径只接受POST请求而SLB发包是GET，直接返回405 Method Not Allowed。此类非2xx/3xx的响应码会导致后端直接标记为不健康。

快速验证命令：从同一VPC内的另一台ECS执行curl -Iv http://<目标ecs内网ip>:<端口>/<健康检查路径>，重点关注返回的HTTP状态码及响应头。如果看到401 Unauthorized，就说明健康检查URL绑定了认证逻辑，应更换为无需鉴权的独立探活端点（如/health），该端点内部可包含轻量级的数据库/缓存连通性检查，但本身不应依赖会话。若返回404或405，需与开发团队对齐全路径和方法，确保SLB配置的路径与后端实际路由一致。

如果必须保留原有认证页面又想通过健康检查，可在Nginx中利用location对健康检查URL做剥离：将该URI直接返回200状态码并忽略后续逻辑。典型的配置片段为：

location = /health {
    access_log off;
    return 200 'ok';
}

这种对健康检查URL“旁路处理”的方式，是避免应用逻辑干扰探活的有效手段。

3. 应用响应超时分析

超时导致的健康检查异常更像一种“软故障”——端口通、进程在、URL也能最后返回200，但首包时间超过了SLB设置的健康检查超时时间。默认超时通常在5秒左右，若应用因线程池耗尽、数据库连接池满或外部API调用卡顿而响应缓慢，就很容易被SLB判定为超时并摘除后端。

排查时仍用curl -w输出时间消耗明细：curl -o /dev/null -s -w "time_namelookup:%{time_namelookup}\ntime_connect:%{time_connect}\ntime_starttransfer:%{time_starttransfer}\ntime_total:%{time_total}\n" http://内网IP:端口/健康检查路径。重点关注time_starttransfer（首字节时间），若该值持续接近或超过健康检查超时阈值，说明应用处理环节存在瓶颈。此时可用strace -p跟踪Nginx或Java进程的系统调用，看是否卡在epoll_wait或futex，也可结合应用自身的访问日志和APM工具，定位具体慢在哪一个下游依赖上。

若因业务冷启动或滚动发布导致短期内响应变慢，不应简单地调大超时时间了事，而应结合SLB的“健康阈值”与“不健康阈值”来平滑状态切换。例如将不健康阈值从默认的3次提升到5次，避免因单次瞬时抖动就剔除实例；同时避免将健康检查间隔设得太短（如小于2秒），否则高频探活会在系统负载略高时产生多米诺效应。这些参数的调优没有通用数值，需要在业务压测中验证当前配置的容错边界。

六、优化健康检查策略与长期预防

把健康检查当作一次性配置丢在一边，是运维里最隐蔽的风险——它往往在凌晨的业务低谷被触发，然后被忽略，直到下一次发布或事故时才炸开。

1. 健康检查参数怎么调，才不会反过来坑自己

健康检查参数没有标准答案，但有一条铁律：必须比应用真实的启动与优雅停机时间长，同时又能真实反映服务就绪状态。

常见的踩坑场景是：应用启动需要 20 秒，健康检查超时却只设 2 秒、间隔 3 秒，连续失败 2 次就摘除。结果每次滚动发布，还没来得及完成初始化的新节点就被 SLB 判定异常，流量直接被切断，发布窗口变得像走钢丝。正确的做法是把这些数值拉宽：超时时间至少设为应用最大启动延迟的 1.5 倍，不健康阈值不要低于 3 次，健康阈值也建议保持 3 次以上，让“上线”与“摘除”状态切换变得平滑，避免瞬时抖动导致的误剔除。

HTTP 健康检查的另一个常见坑是 URL 选择不当。很多人随便填个 “/” 就上线，结果这个首页路径依赖数据库连接或 Redis，一旦依赖抖动，健康检查也跟着失败，进而引发雪崩。健康检查路径应该是一个轻量独立的探活端点，比如 /healthz，只验证进程存活性与最基本依赖（如文件句柄），不触发外部调用，返回 200 即可。如果应用框架自带健康端点（如 Spring Boot Actuator），更要抽出一个“无副作用”的子路径来配合 SLB 的检查，避免把全量健康检查暴露给负载均衡——那会把一次 GC 停顿放大成节点被错误摘除。

2. 配置监控与告警，让异常在扩大前被发现

健康检查失败的量变到质变，通常有迹可循。云监控里可以配置“健康检查异常后端实例数”大于 0 的报警，但这只是最低保障。真正有效的策略是叠加两个维度的告警：

• 数量维度：异常实例数超过总体的 30% 且持续 1 分钟以上才告警，避免单节点短暂闪断带来的噪音。

• 时间维度：统计每分钟异常状态总计时长，超过 30 秒触发预警，提前介入。

同时，不要只盯着 SLB 面板。在后端服务器上，部署一个定时脚本，从同 VPC 内的一台 ECS 上模拟健康检查请求，把结果与 SLB 的健康检查状态做交叉验证。如果两者同时失败，就是应用层或系统层的硬伤；如果只有 SLB 判定异常而本地探测正常，问题多半卡在网络路径上（安全组、系统防火墙、路由表），这个差异能极大缩短排查定位时间。

3. 定期巡检不是“有空才做”，而是写进运维日历的强制动作

依赖告警是被动响应，依赖巡检才是主动预防。建议把以下动作固化成周级巡检清单：

第一，遍历所有 SLB 监听的后端服务器健康状态，拉出最近 7 天内异常时长超过 60 秒的节点，逐一确认异常原因是否已闭环——大量的偶发异常会因为“自动恢复”而被遗忘，但下一次可能就是持续性故障。

第二，检查安全组与系统防火墙规则的有效性。变更管理混乱时，某次临时放通测试后忘了回滚，或者防火墙规则莫名其妙被 systemd 服务覆盖，是造成“之前好好的突然不通”的头号元凶。用 iptables -L -n 或 firewall-cmd --list-all 对比基线文档，能挡住不少低级故障。

第三，做一次健康检查端口的“盲测”：从 SLB 的视角用 telnet 或 curl 验证所有后端端口，确认没有因证书过期、DNS 解析变更、应用监听地址绑定为 127.0.0.1 导致的本地可用但远端不可达。

稳健的健康检查不是调参调出来的，而是靠策略优化、持续监控和定期巡检一起撑起来的。把这三件事做成例行公事，远比每次故障后加班翻日志要划算。