我之前也碰到过类似的情况——TIME_WAIT属于TCP连接关闭后的“收尾”状态，这时候发起连接的进程可能已经关闭了套接字甚至直接退出了，所以TCPView经常没法关联到对应的进程。结合你工作机有150个、家里Win11只有20个的差异，给你几个亲测有效的排查方法：

• 用Process Monitor（ProcMon）抓历史连接记录
  打开ProcMon后，先设置过滤条件：点击顶部的“Filter”按钮，选择“Event Class”等于“Network”，再添加“Operation”包含“TCP Connect”或“TCP Disconnect”的规则。让它后台运行一段时间（覆盖你观察到TIME_WAIT增长的时段），之后你可以通过日志里的目标IP/端口，反向查找对应的进程ID（PID）和进程名，哪怕连接后来进入TIME_WAIT，也能查到是谁发起的。

• 用netsh命令生成网络追踪日志
  以管理员身份打开命令提示符，先运行netsh trace start capture=yes tracefile=NetTrace.etl，让它捕获一段时间的网络活动；等你觉得够了，再运行netsh trace stop。接着把etl文件转成易读的文本格式：netsh trace convert input=NetTrace.etl output=NetTrace.txt。打开生成的NetTrace.txt，搜索那些TIME_WAIT连接的IP和端口，就能找到对应的进程信息了。

• 用Process Explorer实时监控进程网络活动
  打开Process Explorer，点击顶部菜单栏的「View」→「Lower Pane View」→「Network Connections」，这样下方面板会显示每个进程当前的所有网络连接。如果某个进程频繁建立短连接，你能实时看到它的连接变化；就算连接后来进入TIME_WAIT，只要进程还在运行，也能通过之前的连接记录关联上。另外，你也可以在Process Explorer里按PID或进程名过滤，快速定位连接数异常多的程序。

• 检查系统TCP参数的差异
  工作机和家里机器的TIME_WAIT数量差这么大，也可能是系统TCP配置不同。你可以用命令reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v TcpTimedWaitDelay查看这个参数——它控制TIME_WAIT状态的持续时间，默认是240秒。如果工作机这个值设得偏大，连接就会更容易积累。不过这个是辅助排查，核心还是找到发起连接的进程。

• 排查工作机上的企业级应用
  一般家里机器的软件比较简单，而工作机可能有办公套件、VPN客户端、文件同步工具、企业级通讯软件这些，它们经常会频繁建立短连接，导致大量TIME_WAIT。你可以先检查后台运行的企业应用，看看有没有最近新安装或更新的程序，这类程序大概率是“元凶”。

备注：内容来源于stack exchange，提问作者Boppity Bop