文章总结： 本文复盘了一次核心交换机更换后偶发TCPFIN丢包的排查过程，指出防火墙FIN超时设置过短与ECMP路径不一致是根本原因。服务器FIN发出后客户端延迟5秒回复导致会话超时被删，ECMP加剧了丢包的偶发性。建议调长防火墙TCPFIN超时时间至30秒以上，并通过链路聚合消除ECMP以确保路径一致。 综合评分： 93 文章分类： 网络安全,应急响应,实战经验

一次诡异的TCP四次挥手丢包案：防火墙、ECMP与5秒的博弈

原创

小话安全 小话安全

小话安全

2026年3月16日 13:41 山东

一次看似平常的核心交换机更换，却引发了一场偶发的“FIN丢包”谜案。服务器发了FIN，客户端回了ACK，但5秒后客户端的最后一个FIN却神秘消失——内网核心交换机明明收到了它，可服务器核心交换机和防火墙上却毫无踪迹。防火墙配置没变，旧环境一切正常，新环境为何翻车？让我们一起抽丝剥茧，揭开真相。

 一、故障初现：连接数飙升，FIN包去哪了？

某日，网络团队完成了一项常规操作——更换内网服务器核心交换机。本以为风平浪静，却很快收到负载均衡器的告警：连接数持续攀升，远超正常水平。

直觉告诉团队，可能有TCP连接无法正常关闭，导致连接泄漏。抓包分析随即展开，聚焦在负载均衡的会话保持端口上。结果令人困惑：

• **内网核心交换机**：正常抓到了客户端发来的FIN包（四次挥手的第三步）。

• **服务器核心交换机**：却完全没抓到同一个FIN包。

• **防火墙**：同样没有该FIN的任何踪迹。

• **服务器本身**：也没有收到这个FIN。

FIN包在从内网核心到服务器核心的途中蒸发了？而且这种现象并非每次必现，而是偶发性的，这给排查增添了难度。

更细致的观察发现了一个规律：服务器发送FIN后，客户端能在很短时间内回复ACK，但客户端自己的FIN却要间隔5秒后才发出。正是这个5秒后的FIN，有时能顺利到达服务器，有时则消失在半路。

 二、网络组的初判：OSPF等价路由惹的祸

网络组同事迅速介入，排查网络层问题。他们发现：服务器核心到业务核心之间通过OSPF建立了两个邻居关系，形成了等价路由（ECMP）。这意味着数据包在去程和回程时可能走了不同的物理链路。

防火墙是状态化设备，它要求同一个连接的所有报文都必须经过它，并且顺序合规。一旦来回路径不一致，防火墙就可能因为看不到完整的会话状态而丢弃后续报文。

据此，网络组给出了解决方案：将四条上联线路捆绑成两个三层接口聚合组，与业务核心建立OSPF邻居，消除等价路由。聚合组能保证同一个数据流始终走同一条物理链路，确保路径一致。

按理说，解决了路径不一致，FIN丢包就该消失了。但问题真的这么简单吗？如果是路径不一致导致丢包，那为什么ACK和FIN都是客户端→服务器方向，路径应该相同，ACK却能顺利通过，FIN却偶发丢失？路径不一致理论无法完美解释“ACK通而FIN丢”的现象。

 三、深入剖析：为什么只有FIN会丢？

我们需要更精细地分析TCP四次挥手的过程和防火墙的行为。

1. TCP四次挥手与防火墙状态机

正常关闭流程：

• 服务器发送 FIN（主动关闭） → 客户端

• 客户端回复 ACK

• 客户端发送 FIN → 服务器

• 服务器回复 ACK

防火墙作为中间设备，会跟踪每个连接的状态。当它看到服务器发来的FIN时，会将连接从“已建立”状态转为“半关闭”状态，并启动一个专用的FIN超时定时器。这个定时器通常很短（很多设备默认2~5秒），目的是尽快回收资源。一旦超时，防火墙会直接删除会话表项。

2. 5秒间隔——正好踩在超时临界点

你观察到的“客户端在5秒后才发FIN”是一个关键线索。如果防火墙的FIN超时设置为小于5秒（比如2秒），那么当服务器FIN到达后，防火墙开始倒计时，2秒一过，会话被删除。3秒后客户端FIN姗姗来迟，防火墙找不到对应会话，自然就丢弃了。

3. 那为什么ACK没丢？为什么之前正常？

• **ACK没丢**：因为ACK是在服务器FIN之后很快发出的（远小于2秒），当时会话还在，防火墙能正常转发。

• **之前环境正常**：防火墙配置没变，说明旧交换机环境下，从服务器FIN到客户端FIN的**实际间隔从未超过防火墙超时**。这可能是因为旧交换机的某些特性（比如处理速度、缓冲机制、额外的TCP Keep-Alive包）无意中“刷新”了防火墙的计时器，或者使得5秒间隔被压缩。而新交换机环境更加“精确”，让原本被掩盖的配置缺陷暴露了出来。

3. ECMP的“助攻”

虽然超时是主因，但ECMP确实起到了推波助澜的作用。如果网络中没有等价路由，即使超时已过，客户端FIN仍然会沿着原路径到达同一台防火墙（即使会话已删），防火墙可能会因为状态缺失而丢弃，但至少路径固定，问题会表现为**固定丢包**，而非偶发。

在新交换机环境中，ECMP可能导致客户端FIN有时走链路A，有时走链路B。假设防火墙集群部署方式使得只有部分防火墙有该会话，那么：

• 如果FIN走了有会话的防火墙（但会话已超时删除），还是丢。

• 如果FIN走了从未见过该会话的防火墙，更是直接丢。

ECMP的路径不确定性，加上超时临界点，共同造成了**偶发性**丢包。而且，因为内网核心交换机抓到了FIN，说明客户端发出的FIN已经到达了内网核心，但在进入防火墙或后续链路时因路径选择问题被丢弃。

四、真相大白：防火墙超时 + ECMP = 偶发丢FIN

综合以上分析，根本原因可以归纳为：

1. **防火墙FIN超时设置过短**（可能默认2秒），而服务器到客户端的FIN间隔长达5秒，导致会话在半关闭状态被提前删除。

2. **新交换机启用ECMP**，导致路径不一致，加剧了丢包的偶发性——客户端FIN可能被哈希到一条没有该会话状态的防火墙路径上，直接丢弃。

3. 旧交换机环境由于某种原因（如额外数据包刷新计时器、无ECMP、处理延迟等），使得5秒间隔从未触发超时，因此问题未显现。

五、解决方案：双管齐下

1. 调整防火墙FIN超时

登录防火墙，找到TCP相关参数，将 tcp-fin-timeout（或类似名称）从默认值（如2秒）改为**30秒以上**。确保即使在网络延迟或处理缓慢的情况下，四次挥手也能从容完成。

2. 消除ECMP，保证路径一致

采纳网络组的方案：将服务器核心到业务核心的多条链路捆绑为三层接口聚合组（如Eth-Trunk），使OSPF只建立一个邻居，消除等价路由。聚合组内部通过流哈希保证同一连接的所有报文始终走同一条物理链路。

六、启示与思考

• **防火墙是状态敏感的设备**：任何导致路径不一致的因素（ECMP、策略路由）都可能引发状态跟踪异常，必须确保双向流量经过同一防火墙。

• **变更管理的重要性**：看似无关的交换机更换，可能暴露原本隐藏的配置问题。变更前应评估对上下游设备的影响。

• **超时参数需结合实际**：TCP协议中的各种超时值（如FIN超时）应根据实际网络延迟调整，不能一味追求资源回收而牺牲可靠性。

七、结语

一次偶发的丢FIN问题，牵引出防火墙超时、ECMP、TCP状态机之间的复杂关系。网络的世界里，每一个细节都可能成为故障的导火索。希望本文的排查思路能为你处理类似问题提供参考。

如果你也遇到过类似“诡异”的网络故障，欢迎在评论区留言分享，我们一起探讨！

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：小话安全 小话安全 小话安全《一次诡异的TCP四次挥手丢包案：防火墙、ECMP与5秒的博弈》