AWS NLB客户端源IP地址保留的实现机制与流量路径原理是什么？

你观测到的“服务器侧抓到真实客户端源IP、客户端侧仅能看到与NLB公网IP双向流量”的现象，本质是AWS VPC底层虚拟网络的流表劫持机制在生效，和IGW不存在任何联动关系。

核心认知纠偏 #

• 推导的“服务器回包会按常规路由直接走IGW出去、源IP转为服务器自身EIP2.2.2.10”的逻辑，在普通公网访问场景下是成立的，但在NLB转发的连接场景下不生效——因为EC2虚拟机内部的路由表仅作用于虚拟机自身的操作系统层，实际报文的物理转发决策是在宿主机hypervisor层面完成的，高优先级的流表规则会完全覆盖虚拟机内部的路由指向。
• IGW完全不参与这个连接的回程处理，不存在所谓的“NLB与IGW联动做SNAT”的机制，因为回程报文根本不会被送到IGW的转发路径上，自然不会触发EIP对应的源地址转换规则。

全链路报文转发拆解 #

入方向（客户端 -> NLB -> 后端EC2） #

1. 客户端出口IP1.1.1.1发起请求，目标为NLB公网IP2.2.2.2，报文经互联网到达AWS边界，转发到对应NLB的转发节点。
2. NLB节点按目标组策略选定后端EC2（私网IP192.168.0.10）为转发目标，仅修改报文的目的IP为192.168.0.10，完全保留原报文的源IP1.1.1.1。
3. 报文被送到EC2所在的宿主机，hypervisor层在交付报文给EC2操作系统的同时，插入一条高优先级反向流表：所有匹配这个连接四元组（源IP1.1.1.1、客户端随机端口、目的IP192.168.0.10、服务端口）的EC2出向报文，直接转发回对应的NLB节点，不进入宿主机默认指向IGW的转发队列。
4. 报文最终交付给EC2，服务器端通过tcpdump抓到的源IP为1.1.1.1，就是源IP保留特性的直接体现。

回方向（后端EC2 -> NLB -> 客户端） #

1. EC2操作系统收到入站报文后，按照TCP协议栈逻辑生成回包，按自身内部路由表的默认规则，把回包丢给宿主机虚拟网卡，准备走IGW转发。由于整个重定向过程发生在EC2虚拟机之外的宿主机网络层，服务器端tcpdump抓包只会看到回包正常指向客户端IP1.1.1.1，完全感知不到被重定向的过程，这也是容易产生“回包应该直接走IGW”误判的核心原因。
2. 宿主机hypervisor收到这个回包后，匹配到提前插入的反向高优先级流表，直接将报文劫回NLB节点，完全绕开IGW路径——因为没有走到IGW，所以根本不会触发EC2绑定的弹性IP2.2.2.10对应的SNAT转换逻辑。
3. NLB节点收到回包后，将报文的源IP修改为NLB自身的公网IP2.2.2.2，再按互联网路径转发回客户端1.1.1.1。
4. 客户端收到的回包源IP和当初发起请求的目标IP（2.2.2.2）完全匹配，TCP连接正常建立，因此在PC端Wireshark抓包时，完全看不到和服务器弹性IP2.2.2.10的流量交互。

机制设计逻辑 #

这套底层流表的处理逻辑，核心是平衡两个落地需求：

• 对后端服务器透明保留客户端真实源IP，不需要额外部署代理层做IP透传。
• 对客户端侧保证TCP连接的四元组一致性，避免因为回包源IP和请求目标IP不匹配，导致客户端丢弃报文、连接无法建立。

内容的提问来源于stack exchange，提问作者Difan Zhao