BGP的“聪明选路”遇上了TCP的“路径洁癖”，需人工调和

在路由器R1上有两条外网，WAN1和WAN2。

R1上做了域名分流功能，全局网址分到WAN1，指定域名分到WAN2（优先级更高）。

症状是用户反馈部分网页无法打开。

于是各种检查尝试......  2天过去了......

最终结论是：即使SYN请求通过R1发出，服务器响应的目标IP（R1的公网地址）可能被BGP策略判定为“通过R2更优”，导致响应包从R2进入用户网络。

分析过程：

对TCP三次握手的影响：路径不对称导致连接失败

TCP协议要求连接路径​​双向一致​​（对称性），否则会破坏传输层的可靠性机制。以下是具体冲突点：

​​1.TCP序列号（Sequence Number）校验失败​​ ​​

请求阶段​​：客户端通过R1发送SYN包（序列号Seq=X），服务器记录此序列号。 ​​

响应阶段​​：若SYN-ACK通过R2返回，客户端预期确认号为Ack=X+1，但R2转发的包可能因路径延迟或修改导致序列号不匹配。 ​​

结果​​：客户端丢弃SYN-ACK包，重传SYN请求（Wireshark显示TCP Retransmission） 。 ​​

2.NAT会话表失效

路由器在转发SYN请求时执行​​SNAT​​（源地址转换），将客户端内网IP替换为R1的公网IP，并记录会话表。

当SYN-ACK从R2进入时，路由器发现此包不匹配R1的会话表条目，可能丢弃或错误转发。

3.实际现象​​

Chrome开发者工具显示ERR_CONNECTION_RESET或超时。

TCP状态机因路径不一致进入死锁（客户端等待SYN-ACK，服务器等待ACK确认）

NAT会话表失效​​

路由器在转发SYN请求时执行​​SNAT​​（源地址转换），将客户端内网IP替换为R1的公网IP，并记录会话表。 当SYN-ACK从R2进入时，路由器发现此包不匹配R1的会话表条目，可能丢弃或错误转发 。 ​​实际现象​​ Chrome开发者工具显示ERR_CONNECTION_RESET或超时。 TCP状态机因路径不一致进入死锁（客户端等待SYN-ACK，服务器等待ACK确认）

以下是BGP的逐包独立选路特性，​​ BGP路由器对每个数据包的转发决策是独立的，基于以下优先级顺序 ：

​​本地优先级​​：若R2所在路径的优先级更高（如运营商策略优化），则优先选择；

AS路径长度（AS Path）​​：若通过R2的路径经过的AS数量更少（如AS Path更短），则优选； ​​

MED值（多出口鉴别器）​​：若R2所在入口的MED值更小（如成本更低），则流量被导向R2；

​​其他规则​​：如权重（Weight）、下一跳IGP开销等。