外部负载均衡器无法接收请求：私有子网路由规则冲突排查求助

嘿，我来帮你拆解这个头疼的问题——核心根源在于你只考虑了入站流量的路径，却完全忽略了回程流量的逻辑，这才导致负载均衡器（LB）直接罢工，连tcpdump都抓不到流量。

为什么会出现这种矛盾？ #

我给你一步步捋清楚你的场景逻辑：

1. 你的公网LB在两个可用区部署，带着公网ENI，它要把流量转发到私有子网里的应用服务器。客户端发起请求时，流量路径是：客户端公网IP → LB公网ENI → LB内网ENI → 应用服务器。
2. 但你给应用子网配置了默认路由（0.0.0.0/0）指向防火墙，这意味着应用服务器的所有出站流量（包括对客户端的响应）都会先往防火墙走，而不是直接回LB或者公网。
3. 这直接触发了两个致命问题：
   • TCP连接根本建立不起来：服务器响应包的源IP是私有子网的内网IP，目标是客户端的公网IP。如果防火墙没配置正确的SNAT（源地址转换）把内网IP换成防火墙的公网IP，客户端根本收不到这个响应——毕竟私有IP不能在公网上路由。LB收不到服务器的ACK，就会判定服务器不可达，直接停止向它转发流量，这就是你后来用tcpdump完全看不到流量的原因，因为LB已经把你的服务器标记成“不健康”了。
   • LB的流量校验机制卡了你：很多云厂商的公网LB会校验流量的往返路径是否一致。如果LB从内网ENI发出去的请求，收到的响应是从防火墙的公网IP回来的（哪怕防火墙做了SNAT），LB会认为这是非法流量直接丢弃，同样会导致连接中断。

怎么同时满足两个需求？ #

你需要做的是给LB相关的流量开个“绿色通道”，让服务器对LB的回程流量不走防火墙，直接回到VPC内部的LB，具体操作步骤如下：

1. 拿到LB的内网IP信息：找到你的LB对应的内网ENI的IP地址，或者云厂商提供的LB服务专属IP段（比如部分云厂商的LB有对应的前缀列表可以直接用）。
2. 给应用子网的路由表加静态路由：新增一条路由规则，目标地址设为LB的内网IP/IP段，下一跳选择VPC本地路由（或者云厂商对应的“本地网关”选项）。这条静态路由的优先级比默认路由高，所以只有LB相关的流量会走这条路径，其他外部流量依然会走防火墙。
3. 保留原有默认路由：你原来的需求（外部流量转发到防火墙）完全不受影响，两者可以共存。

举个实际例子，假设你的LB内网IP是10.0.1.10和10.0.2.10，那就在应用子网的路由表里新增两条静态路由规则：

目标地址: 10.0.1.10/32 → 下一跳: VPC本地
目标地址: 10.0.2.10/32 → 下一跳: VPC本地

这样调整后，LB的流量能正常和服务器建立双向连接，同时其他外部流量依然会通过防火墙转发，完美解决你的矛盾需求。

内容的提问来源于stack exchange，提问作者Krrish Raj