FIN_WAIT2状态表示本端已发FIN并收到ACK，正等待对端FIN；若长期滞留，说明对端未关闭，可能因程序异常或未调用close()，会占用socket资源；Linux通过tcp_fin_timeout参数（默认60秒）控制其超时，可调小该值或从应用层确保及时close。

Linux下TCP连接处于FIN_WAIT2状态时，表示本端已发送FIN并收到对端ACK，正在等待对方发送FIN。若长时间滞留（如数分钟甚至更久），说明对端未主动关闭连接，可能因程序异常、网络中断或未正确调用close()导致。这种状态会占用socket资源，大量存在时可能耗尽本地端口或内存。

FIN_WAIT2的默认超时机制

Linux内核对FIN_WAIT2状态有隐式超时控制，但不依赖固定定时器，而是与tcp_fin_timeout参数间接相关：

• 当套接字处于FIN_WAIT2且对应连接是“无端点”的（即对端已关闭，本端为被动关闭方），内核会启动一个基于tcp_fin_timeout的定时器
• 默认值通常为60秒（可通过cat /proc/sys/net/ipv4/tcp_fin_timeout查看）
• 注意：该超时仅对半关闭后未收到FIN的连接生效；若连接仍被用户进程持有（如socket未close或设置了SO_LINGER为0），则不会触发此超时

主动缩短FIN_WAIT2超时时间

可通过调整内核参数加快清理：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 修改/proc/sys/net/ipv4/tcp_fin_timeout，例如设为30：
  echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
• 永久生效可写入/etc/sysctl.conf：
  net.ipv4.tcp_fin_timeout = 30，然后运行sysctl -p
• 注意：该设置影响所有处于该状态的连接，不能按端口或应用单独配置

应用层规避FIN_WAIT2堆积的关键做法

根本解决需从程序设计入手：

• 服务端避免“只recv不close”：收到客户端FIN后，应尽快调用close()或shutdown(SHUT_WR)，触发自身FIN发送
• 客户端主动关闭时，调用close()前确保数据发完；必要时用SO_LINGER控制行为（设linger时间为0可强制RST终止）
• 使用epoll/kqueue等IO多路复用时，监听到对端关闭（read返回0）后必须及时close对应fd
• 检查是否有连接泄漏：如忘记close()、异常路径未释放socket、长连接管理逻辑缺陷等

排查与监控建议

定位问题连接和确认状态分布：

• 统计当前FIN_WAIT2数量：
  ss -ant | grep FIN_WAIT2 | wc -l
• 查看具体连接及对应PID（需root）：
  ss -antp | grep FIN_WAIT2
• 结合netstat（较慢）或/proc/net/tcp分析端口、inode、计时器剩余时间（需解析hex）
• 在业务日志中记录连接建立/关闭事件，辅助判断是否应用逻辑未执行close