FIN_WAIT_2/CLOSE_WAIT 120秒超时来源及修改方法

超时来源判定 #

你观测到的120秒半开连接自动回收逻辑，完全来自Windows操作系统内核的TCP/IP协议栈实现，和.NET框架、C# TcpClient类没有关联。
.NET的网络通信相关类全部是对系统底层Winsock接口的封装，本身不会实现TCP状态机的超时逻辑，也不会干预连接的生命周期回收。这个半连接回收机制从Windows Vista/Server 2008版本开始就作为默认配置存在，并非Windows 10独有，和其他主流操作系统、网络设备的半关闭连接超时设计目的一致：避免应用层异常未释放连接时，僵死的半开连接长期占用系统端口、内存、句柄资源。
当服务端主动发送FIN包进入FIN_WAIT_2状态、客户端收到FIN进入CLOSE_WAIT状态后，如果客户端始终不调用Disconnect()/Close()方法发送自身的FIN包完成四次挥手，达到超时阈值后系统会直接强制回收两端的连接资源，回收动作不会主动通知上层应用。

阈值修改方式 #

该超时阈值支持修改，配置入口为Windows系统注册表，调整后需要重启系统才能生效，修改前建议备份对应注册表项，避免配置错误引发网络异常：

1. 打开注册表编辑器，定位到路径：HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
2. 根据需要调整的状态配置对应REG_DWORD类型键值：
   • FinWait2Timeout：控制FIN_WAIT_2状态的超时时间，单位为秒，可配置范围30~300秒，系统默认值为120秒
   • TcpCloseWaitDelay：Windows 10及后续版本中控制CLOSE_WAIT状态僵死连接的超时时间，单位为秒，系统默认值为120秒，配置为0xFFFFFFFF时可禁用该状态的自动回收

实践建议 #

不建议随意调大上述超时阈值。半开连接长期不释放会持续消耗系统资源，高并发场景下极易引发端口耗尽、内存泄漏等问题。业务代码层面应当主动实现连接状态检测逻辑，在感知到对端断开后及时调用TcpClient的释放方法完成连接关闭，不要依赖系统超时机制做资源回收。

内容的提问来源于stack exchange，提问作者Tobias Knauss