LVS+Keepalived作四层高可用入口，分发流量至Nginx/HAProxy七层集群，兼顾性能与HTTP级调度能力；LVS无法解析HTTP内容，故Web业务必须依赖七层代理实现URL路由、HTTPS卸载等功能。
Keepalived 结合 LVS 构建四层与七层混合负载均衡架构，核心思路是：用 LVS（+Keepalived）做前端四层高可用入口，再把流量分发给后端七层代理（如 Nginx 或 HAProxy），由它们完成基于 HTTP/HTTPS 的精细调度（URL、Header、Cookie 等）。这种分层设计兼顾了四层的高性能和七层的灵活性，也规避了单点瓶颈。
为什么必须分层：LVS 不替代 Nginx
LVS 工作在内核态，只处理 TCP/UDP 连接转发（IP+Port），无法解析 HTTP 请求内容；Nginx 或 HAProxy 运行在用户态，能读取并分析完整 HTTP 报文。因此：
- 纯 LVS + Keepalived 只能实现四层负载，适合透传、长连接、非 Web 类服务（如数据库代理、游戏网关）
- Web 业务需要 URL 路由、动静分离、HTTPS 卸载、限流鉴权等功能，必须依赖七层代理
- 若只用 Keepalived + Nginx 主备，Nginx 成为单点瓶颈，且无法横向扩展对外 IP
- LVS 做 VIP 入口 + 多台 Nginx 横向集群，才是可伸缩的生产级方案
LVS 层：配置 DR 模式 + Keepalived 高可用
两台 LVS 服务器（master/backup）共用一个 VIP（如 192.168.11.218），采用 DR（Direct Routing）模式——性能最优，响应包不经过 LVS，直接由后端 Nginx 返回客户端。
- 确保所有节点（LVS、Nginx、Web）在同一二层网络，Nginx 必须配置 VIP 的 lo 接口别名，并禁用 ARP 响应（arp_ignore=1, arp_announce=2）
- Keepalived 配置中 state MASTER/BACKUP、priority、virtual_router_id 主备需一致，VIP 写在
virtual_ipaddress块 -
virtual_server定义 VIP:Port（如 192.168.11.218:80），real_server指向 Nginx 服务器真实 IP（如 192.168.11.213:80），权重按实际负载能力设置 - 健康检查建议用
TCP_CHECK（快速）或自定义HTTP_GET（更准），避免仅靠端口存活误判服务状态
Nginx 层：作为七层负载均衡器集群
每台 Nginx 接收来自 LVS 的请求，再根据业务规则将流量分发到后端 Web 应用（如 PHP、Java、静态资源）。
- 启用
upstream模块，定义多个 Web 节点（如 web1:8080、web2:8080），支持轮询、ip_hash、least_conn、weight 等策略 - 在
server块中使用proxy_pass转发，注意设置proxy_set_header Host $host等关键头，避免后端丢失原始信息 - 可开启
proxy_cache缓存静态资源，减轻后端压力；配合proxy_next_upstream实现自动故障转移 - 若需 HTTPS，推荐在 Nginx 层统一卸载 SSL，LVS 仍走纯 TCP（443 端口），简化 LVS 配置并提升性能
关键细节与避坑提示
混合架构看似清晰，实操中几个细节极易出错：
-
ARP 配置遗漏：Nginx 节点未配置
lo:0绑定 VIP 或未调优内核参数，导致响应包被网关丢弃或回包路径异常 -
会话保持错位：LVS 层设了
persistence_timeout（如 300 秒），但 Nginx 层又用ip_hash，可能造成双重绑定，建议只在 Nginx 层做会话控制 -
健康检查粒度不足：LVS 默认只检查端口通不通，若 Nginx 进程活着但 upstream 全挂，流量仍会进来。应在 Nginx 层加
health_check或用外部探针联动 -
日志溯源困难：LVS 后的 Nginx 日志中，
$remote_addr显示的是 LVS 的 IP，需在 LVS 配置中开启forward（DR 模式下默认已保留客户端源 IP）并确保 Nginx 启用set_real_ip_from和real_ip_header X-Forwarded-For
