lvs本身无健康检查能力，必须依赖keepalived实现后端服务器故障自动识别、隔离与恢复；其通过tcp或http检查实时监控rs状态，失败则从ipvs规则中移除节点，恢复后自动重新纳入集群。
后端服务器突发离线时，LVS 本身不自带健康检查能力，必须依赖 Keepalived 或其他外部机制实现自动识别、隔离与恢复。关键不是等报错再处理，而是靠前置配置把“发现—剔除—验证”流程自动化。
Keepalived 是 LVS 实现故障自愈的核心
LVS 调度器只负责转发，不感知后端是否存活。一旦某台 Real Server（RS）宕机，LVS 仍会按调度算法继续发流量过去，导致用户看到 502/504 或超时。所以必须用 Keepalived 在 virtual_server 段中定义 TCP 或 HTTP 健康检查，由它来动态管理 RS 状态。
- 健康检查要真实反映业务可用性：TCP_CHECK 只确认端口通，适合简单服务；对 Spring Boot 等应用，建议配合 HTTP_CHECK 访问
/actuator/health/readiness，避免“进程在但业务卡死”的伪在线状态 - 检查参数需合理：
connect_timeout 3、retry 3、delay_before_retry 3，即单次检测超时 3 秒，失败重试 3 次，间隔 3 秒，总判定时间约 12 秒，兼顾灵敏与抗抖动 - RS 被踢出后，Keepalived 会自动从 ipvs 规则中移除该节点，
ipvsadm -ln查看时不再出现，流量实时切走
离线发生后，快速定位根因要分层排查
别只盯着 LVS 配置，问题往往不在调度层：
- 网络层：检查 RS 是否被安全组拦截、ARP 表异常、VPC 路由丢失，用
ping和telnet rs-ip port初步验证连通性 - 系统层：登录 RS 执行
df -h（磁盘满？）、free -h（内存耗尽？）、dmesg -T | grep -i "killed process"（OOM Killer 杀进程？） - 应用层：确认服务进程是否存活（
systemctl is-active your-app）、端口是否监听（ss -tuln | grep :8080）、JVM/Python/Go 是否异常退出或卡死 - 依赖层：查应用日志，看是否因数据库连接池耗尽、Redis 超时、下游接口不可用，导致健康端点持续返回 500 或超时
恢复后必须闭环验证，不能只看“上线”
RS 重启或修复后，Keepalived 默认会重新纳入集群，但需人工确认是否真正可用：
- 先查
ipvsadm -ln确认节点已加回，且权重正确 - 再 curl VIP + 端口，验证响应内容和状态码是否正常（不只是 HTTP 200，还要看业务逻辑返回）
- 最好用真实请求压测几秒，观察日志是否有 DB 连接复位、缓存重建等初始化延迟，避免灰度放量时瞬间打挂
LVS + Keepalived 的高可用，本质是“配置驱动的自动运维”。一次配置不到位，比如健康检查路径写成 /、超时设成 10 秒、没开 nopreempt 导致主备反复切换，都会让故障恢复变成人为救火。
