四层为什么拿不到真实 IP
四层转发不解析 HTTP，只按连接做地址转换，因此后端应用看到的源地址是负载均衡的地址，而不是真实客户端。需要按客户端做风控、限流、日志追溯时这个问题就必须解决。常见方案有两条：一是加载特定内核模块解析真实源地址（如腾讯云的 TOA），二是在连接前插入 Proxy Protocol 头携带客户端信息，由后端负责解析；选哪条取决于产品支持与后端内核能力。
基本信息
| 问题 | 四层转发改写源地址，应用取到的对端是负载均衡 |
|---|---|
| 方案 A | 内核模块解析真实源地址（如腾讯云 TOA） |
| 方案 B | Proxy Protocol：转发时插入客户端地址信息，后端需解析 |
| 验证 | 应用日志或连接记录中确认源地址是否为真实客户端 |
典型使用场景
- 按客户端 IP 做访问控制与限流的网关类服务
- 审计日志需要记录真实来源地址，满足合规要求
- 风控与反作弊依赖来源地址做画像与拦截
- 排查地域性访问异常时，需要区分不同来源的请求
核验后端看到的源地址
核验后端看到的源地址
curl -s http://10.0.1.30/whoami; echo
# 结果应为真实客户端地址，而不是负载均衡地址
# 同时检查应用日志中的 remote_addr 字段是否一致两种方案对比
| 维度 | 内核模块（TOA 类） | Proxy Protocol |
|---|---|---|
| 改造位置 | 后端主机内核 | 后端应用解析 |
| 应用改动 | 通常无需改动 | 需支持协议解析 |
| 适用 | 厂商生态内 | 协议兼容性更广 |
| 风险 | 内核兼容性 | 不支持的应用会解析失败 |
方案选择取决于产品与后端内核能力：无法改内核时优先考虑支持 Proxy Protocol 的组合，或接受应用层记录代理地址。
落地时的注意点
无论选哪种方案，都要先在一台非关键后端上验证再全量铺开，因为这两种机制都可能让服务直接不可用：内核模块版本不匹配可能无法加载，Proxy Protocol 开启后，后端若仍按普通 TCP 解析，会把协议头当成业务数据读到，出现难以理解的解析错误。验证通过后还要同步调整风控与限流策略——此前基于负载均衡地址做的规则，在拿到真实源地址后需要重写，否则可能把正常客户端误封。