lvs不同模式下获取真实客户端ip需差异化处理：dr/tunnel模式可直接获取；nat/fullnat模式须依赖toa（tcp option）或proxy protocol透传；七层场景应优先用x-real-ip并严格校验可信源。
在 LVS 负载均衡环境下，后端服务器默认看到的是负载均衡器（Director）的 IP，而非真实客户端 IP。这个问题必须结合 LVS 的工作模式和网络路径来解决，不能一概而论。
LVS 不同模式下的源 IP 获取方式
LVS 有 NAT、DR、TUNNEL、FULLNAT 等多种模式，每种模式对源 IP 的处理逻辑完全不同：
- DR 模式：数据包直接转发，不修改源 IP，后端服务器能原样获取 client IP；但要求后端配置 VIP 并关闭 ARP 响应，回包需绕过 LVS 直达客户端。
- TUNNEL 模式：LVS 在原始 IP 包外再套一层 IP 头（IPIP 封装），后端解封装后即可拿到原始 client IP；适用于跨机房场景，但需内核支持 IPIP 模块。
- NAT 模式：请求和响应都经过 LVS，目的/源 IP 全被改写，后端看到的源 IP 是 LVS 的 DIP；此时必须依赖额外机制透传 client IP。
- FULLNAT 模式：源 IP 和目的 IP 都被替换，后端完全看不到 client IP；必须启用 TOA（TCP Option Address）或 Proxy Protocol 才能恢复。
TOA 方案：四层无侵入透传
适用于 FULLNAT 或 NAT 模式下，且后端是 Linux 系统的场景。原理是在 TCP 握手 SYN 包的 Option 字段中插入 client IP 和端口，后端通过加载 toa 内核模块自动解析并覆盖 socket 的 remote_addr。
- 负载均衡侧需启用 TOA 支持（如 DPVS 或定制 LVS-FullNAT）；
- 后端服务器需加载
toa.ko模块，并确保应用使用标准系统调用（如getpeername）获取客户端地址； - 不依赖 HTTP 协议，对 TCP 类服务（如 MySQL、Redis、自定义协议）同样有效；
- 缺点是仅限 Linux，且需内核兼容（主流发行版基本支持）。
Proxy Protocol 方案：兼容性更强的四层方案
由 HAProxy 提出并被 Nginx、云厂商 SLB 广泛支持，LVS 本身不原生支持，但可通过组合方案实现（例如在 LVS 后接 HAProxy 或使用支持 Proxy Protocol 的 DPVS）。
- 在 TCP 连接建立后、应用层数据前，插入一段二进制头部（v1 或 v2 格式），明文携带 client IP 和端口；
- 后端服务需显式启用 Proxy Protocol 解析（如 Nginx 的
proxy_protocol指令，或应用层手动读取前 12/16 字节）； - 比 TOA 更灵活，支持非 Linux 后端，也兼容 TLS 和非 HTTP 协议；
- 注意：必须确保整条链路只插入一次，避免重复或伪造（建议在最前端 LB 统一注入并校验）。
七层补充：X-Forwarded-For 与 X-Real-IP 的正确用法
如果 LVS 后还有一层七层代理（如 Nginx 或 ALB），可利用 HTTP 头传递 client IP，但务必规避常见陷阱：
- 优先使用
X-Real-IP，由负载均衡器强制覆盖写入，丢弃客户端传来的同名头； - 若必须用
X-Forwarded-For，应只取最左边第一个非私有地址（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、127.0.0.1等需过滤），防止伪造； - 日志中记录时，建议同时保留
$remote_addr（代理 IP）和$http_x_real_ip（真实 IP），便于审计与排查； - 不要在业务逻辑中盲目信任
X-Forwarded-For，风控、限流等关键环节应以X-Real-IP或 TOA/Proxy Protocol 结果为准。
