HAProxy四层负载均衡IP透传实战：Proxy Protocol、DSR与TOA全解析-代码聚汇网

HAProxy四层负载均衡IP透传实战：Proxy Protocol、DSR与TOA全解析

黄泓毅·2026-08-31·阅读 24 GEO检测（免费）

HAProxy四层负载均衡IP透传

|难度：普通|阅读约 44 分钟

上个月业务方甩过来一个工单：风控系统里所有用户流量都来自同一个内网 IP，按地域封禁完全失效。跟踪了大半天，发现流量经过我们新加的 HAProxy 四层转发后，后端的 TCP 连接上看到的源地址是负载均衡器自己的，根本不是客户端真实地址。这个现象在云原生环境里特别典型——容器网络往往自带一层 NAT，再加上 LB 的代理转发，客户端 IP 很容易被“吞”掉。

那次排障之后，我把整个链路单独拉出来做了一个实验，从零复现“客户端 -> HAProxy 四层负载均衡 -> 后端服务”的完整场景，重点验证 IP 透传的三种主流方案：Proxy Protocol、DSR 回程直返、TOA 内核模块。整个过程踩了不少坑，也把云原生网络模型的底层行为摸了一遍。

这篇文章不做概念堆砌，全部是能直接落地的实验步骤、配置文件和抓包验证，适合正在做云原生网关、微服务中间件或者四层接入层运维的同学参考。如果你也被“后端日志拿不到真实客户端 IP”这个问题困扰，看完应该能少走不少弯路。

1. 为什么四层负载均衡会“吞掉”客户端 IP：先说清楚问题本质

1.1 TCP 代理机制下的“两个连接”

要理解 IP 透传，首先得把 HAProxy 四层转发的工作原理搞明白。HAProxy 跑在 mode tcp 时，本质是一个 TCP 代理：客户端和 LB 建立一个 TCP 连接，LB 再和后端建立另一个 TCP 连接，然后把两个 socket 之间的字节流双向搬运。

这里的关键在于，这两个连接是独立的。客户端发起的连接是“客户端 IP -> HAProxy 监听地址”，而 HAProxy 向后端发起的新连接，源 IP 是 HAProxy 所在节点自己的地址。后端服务从 accept 出来的 socket 上读到的对端地址，自然就是 HAProxy 的节点 IP，而不是真正的客户端 IP。

这个“源 IP 丢失”不是 bug，而是 TCP 代理的正常行为。HTTP 七层转发可以通过 X-Forwarded-For 这样的头字段把真实 IP 带过去，但四层转发转发的是原始 TCP 字节流，没有类似的应用层头可以透传，所以必须靠其他机制。

1.2 云原生环境让问题变得更隐蔽

在传统物理机时代，如果 LB 和后端在同一个二层网络里，后端还能通过抓包看到一部分信息。但在云原生环境里，问题更复杂：

容器网络本身存在 NAT：Docker 默认 bridge 网络下，容器访问外部时会被 MASQUERADE，源 IP 变成 docker0 网桥地址。
Kubernetes 的 kube-proxy 会做 SNAT：Pod 访问 ClusterIP 时，流量经过 iptables/IPVS 规则，源 IP 可能被换成节点 IP。
Overlay 网络隧道封装：Calico、Flannel 这类 CNI 插件用 VXLAN 等方式封装报文，外层看到的源 IP 是隧道端点。

也就是说，客户端 IP 在到达后端之前，可能已经被“洗”了两三轮。我整理了一个常见的源 IP 变化链路：

流量路径	后端看到的源 IP
客户端 -> HAProxy（宿主机网络）	客户端公网/私网 IP（前提是没有 SNAT）
HAProxy -> 后端（同主机 127.0.0.1）	127.0.0.1
HAProxy -> 后端（跨容器网络）	容器网桥 IP/隧道端点 IP
K8s NodePort -> Pod（Cluster 策略）	节点 IP
K8s NodePort -> Pod（Local 策略）	客户端原始 IP

后端业务方经常抱怨“日志里全是内网 IP，根本没有分析价值”，绝大多数情况下就是上述某一环的 SNAT 导致的。

1.3 业务为什么要真实 IP

可能有人会问：拿不到真实 IP 会怎样？影响面其实很大：

安全风控：异地登录检测、封禁恶意来源 IP，全依赖真实源地址。
流量分析：按地域统计用户分布，如果源 IP 都是 LB 节点，统计结果全部失真。
访问限流：四层限流往往要按 IP 维度做，拿不到源 IP 就没法做。
审计合规：某些行业要求记录完整访问日志，包括客户端真实地址。

所以，IP 透传不是可选优化，而是很多业务场景的刚需。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 实验拓扑与容器网络选型：用最小成本还原真实链路

2.1 实验目标与拓扑设计

这个实验我选在 Linux 主机上用 Docker Compose 搭建，目的是用最小代价模拟出“客户端 -> 四层 LB -> 多个后端”的完整链路，并且能清晰观察每一跳的源 IP 变化。

实验拓扑分四个角色：

client：模拟真实客户端，发起 TCP/HTTP 请求。
lb：跑 HAProxy，监听 80 端口，四层转发到后端。
backend1：监听 8081 端口，打印每个连接的对端 IP。
backend2：监听 8082 端口，打印每个连接的对端 IP。

我没有用 Kubernetes 来搭这个实验，因为 K8s 的 CNI、Service 网络会引入太多变量，干扰对 HAProxy 本身的观察。这里先用 Docker 把网络行为验证清楚，后面再单独分析 K8s 场景下的差异。

2.2 网络模式选择：为什么我用 host 网络而不是 bridge

Docker 默认的 bridge 网络模式下，容器访问外部地址时，源 IP 会被伪装成 docker0 网桥的 IP。这个行为对于实验来说是个干扰项——我希望把“LB 到后端”这一跳的 SNAT 行为和 Docker 自身的 NAT 行为分开观察。所以 LB 和后端都选择 network_mode: host，直接共享宿主机网络栈。

host 网络模式的好处是容器里的程序看到的就是宿主机的真实网卡和 IP，没有任何 NAT。这样实验链路就很干净：

client 容器（bridge 网络）访问宿主机 eth0 的 80 端口。
HAProxy 在宿主机网络里监听 80，收到请求后向 127.0.0.1:8081/8082 发起连接。
后端在宿主机网络里监听 8081/8082，直接观察到 HAProxy 发起的源 IP。

如果你用的是 macOS 上的 Docker Desktop，network_mode: host 实际是跑在虚拟机的网络栈里，表现和 Linux 略有差异。条件允许的话，建议直接用 Linux 主机或云服务器操作。

2.3 Compose 文件与基础镜像准备

我用的 Compose 文件长这样：

yaml复制version: "3.9"

services:
  lb:
    image: haproxy:2.6-alpine
    network_mode: host
    container_name: lb
    volumes:
      - ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro
    depends_on:
      - backend1
      - backend2

  backend1:
    image: python:3.11-slim
    network_mode: host
    container_name: backend1
    command: python /app/echo_server.py 8081
    volumes:
      - ./echo_server.py:/app/echo_server.py:ro

  backend2:
    image: python:3.11-slim
    network_mode: host
    container_name: backend2
    command: python /app/echo_server.py 8082
    volumes:
      - ./echo_server.py:/app/echo_server.py:ro

  client:
    image: curlimages/curl:latest
    network_mode: bridge
    container_name: client
    entrypoint: ["sleep", "infinity"]

后端验证程序我用 Python 写了一个极简 TCP 服务，每收到一个连接就打印对端地址，同时把收到的前几个字节打出来，方便验证 Proxy Protocol。这里强调一下：不要用 nginx 做后端验证，因为 nginx 对 TCP 连接的源 IP 打印在日志里不够直观，而且一旦开启 proxy_protocol 后普通 HTTP 请求会被拒掉，容易把实验步骤搞混。

python复制import socket
import threading

def handle(conn, addr):
    print(f"[BACKEND] new connection from {addr[0]}:{addr[1]}")
    conn.settimeout(3)
    try:
        data = conn.recv(16)
        print(f"[BACKEND] first 16 bytes: {data.hex()}")
        if data[:4] == b"\x0d\x0a\x0d\x0a":
            print("[BACKEND] PROXY protocol v2 signature detected")
    except socket.timeout:
        pass
    finally:
        conn.close()

def main(port):
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind(("0.0.0.0", port))
    s.listen(128)
    print(f"[BACKEND] listening on 0.0.0.0:{port}")
    while True:
        conn, addr = s.accept()
        threading.Thread(target=handle, args=(conn, addr), daemon=True).start()

if __name__ == "__main__":
    import sys
    main(int(sys.argv[1]))

启动后登录 client 容器，执行：

bash复制docker exec -it client sh
curl http://<宿主机IP>:80/

此时 backend1 的控制台输出会显示类似：

code复制[BACKEND] new connection from 127.0.0.1:43210

源 IP 是 127.0.0.1，因为 HAProxy 在本机向后端发起了新连接。这直观地说明了问题。

3. HAProxy 四层转发最少必要配置：从裸转发到日志可观测

3.1 先跑通最基础的 mode tcp 配置

HAProxy 的四层转发配置非常精简。我实验里用的第一版配置如下：

haproxy复制global
    log stdout format raw local0 info
    maxconn 4096

defaults
    mode tcp
    timeout connect 5s
    timeout client  30s
    timeout server  30s
    option tcplog

frontend fe_http
    bind :80
    default_backend be_web

backend be_web
    balance roundrobin
    server web1 127.0.0.1:8081 check
    server web2 127.0.0.1:8082 check

这里几个关键点需要解释：

mode tcp：表示 HAProxy 只做四层 TCP 转发，不解析应用层协议。这意味着它不关心后面跑的是 HTTP、HTTPS、MySQL 还是 Redis，只要能建立 TCP 连接就能转发。
option tcplog：在日志里记录 TCP 连接的四元组、连接时长、字节数等信息。比默认日志格式信息量丰富很多，排查问题必备。
balance roundrobin：轮询分发，两个后端服务轮流接请求。
check：启用健康检查。四层模式下默认是 TCP 连通性检查，HAProxy 每 2 秒向后端端口发起一次 TCP 连接。

启动方式：

bash复制docker compose up -d lb
docker logs -f lb

从 client 里连续 curl 两次，两个后端会各收到一次连接。

3.2 观察 HAProxy 日志理解转发细节

打开 HAProxy 的日志，能看到每一条 TCP 连接的完整记录：

code复制haproxy[1]: 172.17.0.2:53212 [07/Feb/2026:10:24:33.128] fe_http be_web/web1 0/0/1/12/13 200 187 - - --VN 1/1/0/0/0 0/0

这条日志拆开来看：

172.17.0.2:53212：客户端的真实 IP 和源端口。HAProxy 确实拿到了，但它没有传给后端。
be_web/web1：请求被转发到了 web1。
200：后端返回的 HTTP 状态码。虽然 HAProxy 不解析 HTTP，但它能看到 TCP 连接正常关闭。

日志很清楚地告诉我们：HAProxy 自己知道客户端 IP，只是没用任何机制把它带给后端。

3.3 为什么生产配置里还要加这些参数

基础配置能跑通，但要用于生产，建议补充以下参数：

haproxy复制global
    log stdout format raw local0 info
    maxconn 4096
    nbproc 1
    nbthread 4

defaults
    mode tcp
    timeout connect 3s
    timeout client  60s
    timeout server  60s
    timeout check   2s
    option tcplog
    option tcp-smart-accept
    option tcp-smart-connect

backend be_web
    balance roundrobin
    option retries 3
    server web1 127.0.0.1:8081 check inter 2s rise 2 fall 3
    server web2 127.0.0.1:8082 check inter 2s rise 2 fall 3

几个参数的经验值：

nbthread 4：多线程模式，提高并发处理能力。注意 nbproc 和 nbthread 在新版本中不建议同时配置。
timeout check 2s：健康检查超时时间，和 inter 2s 配合，保证故障节点 6 秒内被摘除。
option tcp-smart-accept/connect：减少 TCP 半连接状态的资源占用，对高并发场景有明显帮助。

4. IP 透传三条路线：Proxy Protocol、DSR 与真实地址下发的取舍

4.1 路线一：Proxy Protocol——云原生环境最通用的方案

Proxy Protocol 是 HAProxy 作者 Willy Tarreau 设计的一种协议，专门用于在代理和后端之间传递原始连接信息。原理很简单：HAProxy 在与后端完成 TCP 三次握手之后、转发业务数据之前，先发送一段协议头，里面包含客户端的源 IP、源端口、目标 IP、目标端口。

协议有两个版本：

V1：纯文本格式，形如 PROXY TCP4 1.2.3.4 5.6.7.8 12345 80\r\n。
V2：二进制格式，以固定签名 0D 0A 0D 0A 00 0D 0A 51 55 49 54 0A 开头，解析效率更高。

在 HAProxy 里启用只需要在 server 配置后面加一个参数：

haproxy复制backend be_web
    balance roundrobin
    server web1 127.0.0.1:8081 check send-proxy-v2
    server web2 127.0.0.1:8082 check send-proxy-v2

然后重启 HAProxy。此时再去 client 里 curl，后端程序会打印出类似这样的内容：

code复制[BACKEND] new connection from 127.0.0.1:43210
[BACKEND] first 16 bytes: 0d0a0d0a000d0a515549540a
[BACKEND] PROXY protocol v2 signature detected

注意：TCP 连接本身的源 IP 还是 127.0.0.1，但 Proxy Protocol 头里包含了真实客户端 IP。后端程序需要解析这个头才能拿到。对于常见的后端软件，配置方法如下：

nginx 需要在 listen 上加 proxy_protocol：

nginx复制server {
    listen 8081 proxy_protocol;
    set_real_ip_from 0.0.0.0/0;
    real_ip_header proxy_protocol;
}

Node.js 的 net 模块需要自己解析 PROXY 头。Go 的 github.com/pires/go-proxyproto 库可以一键解析。

优点：不依赖网络结构，跨网段、跨集群都能用；后端只要支持就能拿到真实 IP；对性能影响极小。

缺点：后端必须显式支持并解析协议头；如果后端不理解 Proxy Protocol，会把头部当成业务数据，导致协议错乱。

4.2 路线二：DSR 回程直返——高吞吐场景的进阶玩法

DSR（Direct Server Return）是另一个思路。它的核心是：负载均衡器只修改 MAC 地址，不修改 IP 地址，把原始数据包原封不动地转发给后端。后端收到请求后，回包不经过 LB，直接发给客户端。这样回程流量绕过了负载均衡器，LB 的压力减半，吞吐量大幅提升。

DSR 的工作原理是这样的：

客户端访问 VIP（虚拟 IP），请求到达 LB。
LB 通过某种调度算法选中一个后端，然后把数据帧的目的 MAC 改成后端的 MAC，原样转发出去。
后端在自己的 lo 接口上绑定 VIP，收到目的 IP 为 VIP 的数据包后正常处理。
回包时，因为目标 IP 是客户端地址，后端直接把包发出，不必经过 LB。

在传统物理网络里，DSR 需要用 keepalived + LVS 来实施。HAProxy 本身不是专门的 DSR 工具，要硬上也可以，但对网络配置要求很高。我在实验里用 ipvsadm 模拟了一遍 DSR 链路，配置大致如下：

后端节点上绑定 VIP 并调整 ARP 行为：

bash复制# 在后端节点执行
ip addr add 10.0.0.100/32 dev lo
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

LB 节点用 ipvs 配置转发规则：

bash复制# 在 LB 节点执行
ipvsadm -A -t 10.0.0.100:80 -s rr
ipvsadm -a -t 10.0.0.100:80 -r 192.168.1.11:80 -g
ipvsadm -a -t 10.0.0.100:80 -r 192.168.1.12:80 -g

这里有个关键细节：为什么后端要在 lo 上绑定 VIP？ 因为后端网卡的 IP 不是 VIP，它收到目的 IP 为 VIP 的包时，如果 lo 上没有这个地址，内核会认为这不是发给自己的包而丢弃。绑到 lo 上之后，内核才愿意接收。而 arp_ignore=1 和 arp_announce=2 是为了让后端不对外应答 VIP 的 ARP 请求，否则多个后端同时响应 ARP，网络就乱了。

DSR 的核心优势是回程流量不经过 LB，非常适合“下载大文件”这类响应流量远大于请求流量的场景。但它的限制也很明显：

要求 LB 和后端在同一个二层网络里，跨网段做 DSR 需要额外隧道。
云原生容器网络基本是 Overlay 的，二层逻辑隔离，DSR 很难直接落地。
后端服务必须支持 VIP 监听，有些应用会做 IP 校验，直接拒绝目的地址不是本机网卡 IP 的请求。

所以我的结论是：在云原生环境里，DSR 更适合作为一个方案去理解，实战中优先用 Proxy Protocol。

4.3 路线三：TOA 内核模块——特定场景的偏方

TOA（TCP Option Address）的做法是：在 TCP 的 Options 字段里塞入客户端真实 IP 和端口，后端通过加载特殊的内核模块来解析。

具体流程是：

客户端正常发起 TCP 连接。
LB 在转发时，把原始四元组写入 TCP 头的 Options 字段。
后端内核里有 TOA 模块，它会在 TCP 握手时解析 Options，把真实客户端地址覆盖到 socket 的源地址信息里。

TOA 的优势是后端应用完全无感知，不需要改代码，直接 getpeername() 就能拿到真实 IP。但它需要后端内核支持对应模块，在云原生容器场景里，你很难给每个节点动态加载内核模块，而且 TOA 对内核版本敏感，维护成本高。

4.4 三条路线的横向对比

我把三种方案放在一起对比：

方案	后端需要改造	网络要求	性能开销	云原生适配度
Proxy Protocol	需要支持解析	无特殊要求，三层可达即可	极低	好，Nginx/HAProxy/主流框架均支持
DSR	后端需绑定 VIP	LB 与后端二层可达	最低，回程绕过 LB	差，Overlay 网络难以直接使用
TOA	无需改造，但需加载内核模块	无特殊要求	极低	差，容器环境加载内核模块困难

对绝大多数团队来说，云原生环境下的 IP 透传，无脑选 Proxy Protocol 就对了。

5. 端到端验证与抓包复盘：怎么确认源 IP 真的穿透了三层链路

5.1 分阶段验证：每一跳都单独确认

一次性把整个链路配通后直接验证，出了问题很难定位。我的习惯是分阶段验证：

第一阶段，先验证 client 到 HAProxy 这一跳。在 HAProxy 的日志里确认能看到客户端的真实 IP。如果这一步都没有，说明前面还有 NAT 环节，需要先解决。

第二阶段，验证 HAProxy 到后端的裸转发。后端程序打印出来的对端 IP 应该是 127.0.0.1，证明 LB 是新发起了一个 TCP 连接。

第三阶段，启用 Proxy Protocol 后，在后端抓包确认协议头存在，并且后端解析出来的 IP 和 HAProxy 日志里的 IP 一致。

三个阶段全部通过，才能确认 IP 透传真正生效。

5.2 tcpdump 抓包确认 Proxy Protocol 协议头

在后端容器里抓包是最直观的验证方式。启用 send-proxy-v2 后，在宿主机上执行：

bash复制tcpdump -i lo -nn -s 0 -A port 8081

会看到类似下面的内容：

code复制12:00:00.123456 IP 127.0.0.1.43210 > 127.0.0.1.8081: Flags [P.], seq 1:41, ack 1, win 512, length 40
E..T..@.@.z.7.............K..A0........V.......z.
..DR..0d0a0d0a000d0a515549540a0200020f

重点看十六进制部分：0d0a0d0a000d0a515549540a 就是 Proxy Protocol V2 的 12 字节签名。签名后面的内容就是二进制编码的源地址、目标地址和端口。

我一开始犯过一个错误：直接用 strings 去看抓包结果，发现 Proxy Protocol 头里的 IP 是乱码。这是因为 V2 是二进制格式，V1 才是纯文本。排查的时候先确认用的哪个版本，然后用十六进制视图看，不要凭 V1 的经验去解析 V2 的内容。

5.3 用 Python 解析 Proxy Protocol 头验证正确性

为了让验证过程更可控，我在后端程序里加了解析逻辑。其实 Proxy Protocol V2 的头结构很固定：

前 12 字节是签名。
第 13 字节是高 4 位表示版本（V2 就是 0x2），低 4 位表示协议族（TCP over IPv4 是 0x1）。
第 14 字节是长度，表示后面地址信息的字节数。

解析代码可以很简单：

python复制import socket
import struct

def parse_proxy_v2(data):
    if data[:4] != b"\x0d\x0a\x0d\x0a":
        return None
    ver_cmd = data[12]
    fam = ver_cmd & 0x0F
    length = struct.unpack(">H", data[14:16])[0]
    payload = data[16:16 + length]
    if fam == 0x1:  # IPv4
        src_ip = socket.inet_ntop(socket.AF_INET, payload[0:4])
        src_port = struct.unpack(">H", payload[8:10])[0]
        return src_ip, src_port
    return None

这个验证程序跑通之后，我把得到的结果和 HAProxy 前端日志里的客户端地址做比对。一致，说明整个链路没有问题。

5.4 Kubernetes 场景下的额外验证注意点

如果你把实验迁移到 Kubernetes 里，有几个额外的验证环节：

Service 的 externalTrafficPolicy 设置为 Local，保证外层流量进 Pod 前不被 SNAT。
Pod 之间的东西向流量，如果从 Pod A 访问 ClusterIP，即使设置了 Local 策略，源 IP 还是会被 kube-proxy 处理。
CNI 插件如果启用了 eBPF 模式（如 Cilium），源 IP 保留行为又不一样。

建议在 K8s 实验里直接搭一个 HAProxy Deployment，用 hostNetwork: true 方式跑，这样能绕开大部分 kube-proxy 的干扰，专注验证 HAProxy 自身的透传能力。

6. 踩过的一些坑：SNAT、健康检查、MTU 与容器重启后的并发余波

6.1 坑一：Docker bridge 网络的 MASQUERADE 会吃掉源 IP

这应该是所有人做容器实验遇到的第一个坑。我把 client 也放在 bridge 网络里，访问宿主机的 HAProxy 端口时流量正常，但 HAProxy 日志里看到的源 IP 永远是 172.17.0.1 或者 docker0 的 IP，根本没有客户端的容器 IP。

原因是 Docker 的 bridge 网络会启用 iptables MASQUERADE 规则，容器发出的包经过宿主机时，源 IP 会被替换成宿主机在 docker0 网桥上的地址。排查方式很简单：

bash复制iptables -t nat -L -n -v | grep MASQUERADE
iptables -t nat -L POSTROUTING -n -v

解决办法有几种：

client 也用 host 网络，彻底绕过 NAT。
在 Docker 启动时加 --iptables=false（影响面大，不推荐）。
调整 MASQUERADE 规则的排除范围，只对特定目标网段做伪装。

做过几次之后我学乖了：做网络实验第一件事就是确认每个节点之间走的二层还是三层、中间有没有 NAT，再开始配置业务。

6.2 坑二：启用 Proxy Protocol 后普通 HTTP 请求直接被拒

这是做 Proxy Protocol 实验时特别容易踩的坑。后端启用了 proxy_protocol 之后，它期待每个连接的第一个包必须是 Proxy Protocol 头。如果你直接 curl http://127.0.0.1:8081/，curl 发出去的是 HTTP 请求文本，后端把 GET / HTTP/1.1\r\n... 当成协议头去解析，解析失败直接断开连接。

所以验证的时候要注意：

启用 Proxy Protocol 的后端端口，只能接收来自支持该协议的代理的连接。
如果后端是 nginx，会返回 400 Bad Request 并记录一条 broken header 错误。
灰度发布时，必须先升级后端支持 Proxy Protocol，再给 HAProxy 开启 send-proxy-v2，否则会引发大量 4xx。

6.3 坑三：健康检查和 Proxy Protocol 打架

HAProxy 开启 send-proxy-v2 后，健康检查请求也会带上 Proxy Protocol 头。按理说这是合理的行为，因为健康检查和真实流量走的是同一个后端端口。但如果后端不支持 Proxy Protocol，健康检查就会被拒绝，HAProxy 就会认为后端宕机，把所有流量都打给另一个节点。

这个问题有两种解法：

在 HAProxy 配置中单独指定健康检查不带协议头：

haproxy复制server web1 127.0.0.1:8081 check send-proxy-v2

check 后面可以跟 no-send-proxy-v2 来禁用健康检查的协议头，但这样后端必须接受两种类型的连接，对某些软件来说比较麻烦。

更稳妥的做法是：后端统一支持 Proxy Protocol，健康检查照常带协议头，后端解析后正常响应。

我推荐第二种，因为后端的统一性比 LB 配置的灵活性更重要。

6.4 坑四：DSR 实验里的 ARP 问题

做 DSR 实验时，最容易遇到的问题是后端绑定了 VIP，但无论如何都收不到 VIP 的流量。排查下来往往是 ARP 响应问题——后端的网卡上有多个 IP，当外部发送 ARP 请求询问 VIP 的 MAC 地址时，后端可能错误地响应了自己的网卡 MAC，导致流量被直接送到后端而不是 LB。

解决办法就是前面提到的那两个 sysctl 参数：

bash复制echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

arp_ignore=1：只回答目标 IP 是本地网卡 IP 的 ARP 请求。VIP 在 lo 上，eth0 收到别的机器问 VIP 的 ARP 请求时，不响应。
arp_announce=2：只用与目标 IP 同网段的最佳本地 IP 作为 ARP 通告的源 IP。

这两个参数不设，后面会出现各种莫名其妙的“丢包”现象，实际是 ARP 抢答导致的。

6.5 坑五：容器重启后 DSR 配置全部丢失

如果用 ip addr add 在容器里绑定 VIP，重启容器后配置全部丢失。生产环境如果用 DSR 方案，必须把 VIP 绑定、ARP 参数调整放在容器 entrypoint 或者 systemd 单元里固化。

我在实验里就是这样处理的：写了一个 dsr_init.sh，在容器启动时执行：

bash复制#!/bin/bash
ip addr add 10.0.0.100/32 dev lo
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
exec "$@"

同时容器需要 --cap-add=NET_ADMIN，否则没有权限执行 ip addr add。

6.6 坑六：MTU 不一致导致奇怪的重传

四层转发一般不容易碰到 MTU 问题，但如果网络路径上叠加了 VXLAN 或 IPIP 隧道，原始数据包加上隧道头之后可能超过链路 MTU，导致大包被丢弃，表现为“连接能建立，但传输一段时间后卡死”。

排查方法：

bash复制ping -M do -s 1472 <目标IP>

1472 是 1500 减去 IP 头 20 再减去 ICMP 头 8 后的值。如果这个 ping 不通，说明路径上有 MTU 限制。

解决办法：

调整隧道接口的 MTU。
在 HAProxy 层面适当减小转发 MSS：option clitcpka 不一定管用，可以用 maxconn 以外的 mss 相关配置来限制 MSS 大小。

TCP MSS 的设置可以在 frontend 里这样写：

haproxy复制frontend fe_http
    bind :80
    maxconn 4096
    tcp-request inspect-delay 2s

不过四层模式下 MSS 改写一般要在网络设备或 sysctl 层面做，HAProxy 没有直接参数，需要注意区分。

我在实际项目里最终选型的组合是：HAProxy 四层转发 + Proxy Protocol V2 + 后端统一解析。这套方案在云原生环境里最稳定，不依赖网络结构，不要求二层互通，也不需要在后端改内核。如果你的网络环境相对简单、后端都是自研服务，可以试试 DSR，但记得先解决好 ARP 和 VIP 持久化的问题。至于 TOA，除非你有很强的内核维护能力，否则不建议作为首选。

最后留一个可以在自己环境里复现的小实验：在 client 容器里用 nc 发起一条 TCP 连接，先后端不开 Proxy Protocol，再用 tcpdump 抓包对比两次握手后的第一个数据包差异。走一遍这个流程，你对 IP 透传的理解会比看十篇文档都深刻。