关于本文
本文采用生成式 AI 辅助的自动化流程创建。我们参考了 RFC 9293 以及 Microsoft Learn 的 Get-NetTCPConnection，将其整理为在 Windows 上以只读方式观察 TCP 状态的形式。验证状态：📘 已确认 RFC 及微软官方规范・Windows 实机未验证
TCP 连接在通信结束的瞬间并不一定会立即从列表中消失。通过 PowerShell 统计当前状态，ESTABLISHED 和 TIME_WAIT 可以直观地确认它们是“连接状态机”的一部分。
首次尝试
无需管理员权限，按状态统计当前可见的 TCP 连接。
Get-NetTCPConnection |
Group-Object State |
Sort-Object Count -Descending |
Select-Object Count, Name
状态和数量因环境而异。TIME_WAIT 即使为 0 件也不是失败。
关注重点
例如，存在以下状态：
Listen: 等待连接Established: TCP 连接已建立TimeWait: 关闭后保持该状态一段时间
TIME-WAIT 是 RFC 9293 中的标准 TCP 状态。“存在 TIME-WAIT ＝ 故障”这种说法并不绝对。
仅查看 TIME_WAIT
Get-NetTCPConnection -State TimeWait -ErrorAction SilentlyContinue |
Select-Object -First 10 LocalAddress, LocalPort, RemoteAddress, RemotePort, State
如果为 0 件，则结果意味着“此时此刻未能观察到”。由于状态随时间变化，请勿期望获得固定值。
stateDiagram-v2
[*] --> ESTABLISHED: 接続成立
ESTABLISHED --> FIN_WAIT: active close側の例
FIN_WAIT --> TIME_WAIT: close処理が進む
TIME_WAIT --> [*]: 待機後に終了
该图并非涵盖所有状态，而是对本次观察流程的简化。
尝试更改一处
使用浏览器或 curl 等工具进行几次 HTTPS 通信后，再次执行相同的统计。
1..3 | ForEach-Object {
curl.exe -sS -o NUL https://example.com/
}
Get-NetTCPConnection |
Group-Object State |
Sort-Object Count -Descending |
Select-Object Count, Name
受连接复用或操作系统时机的影响，增长方式不一定完全相同。重要的是，在通信前后观察状态分布这一点。
为什么会残留 TIME_WAIT
由于 TCP 提供可靠的字节流（byte stream），因此在关闭（close）时也存在状态转换。TIME-WAIT 的作用包括处理延迟到达的报文段（segment）等。
因此，在产生“连接关闭了怎么还残留 TIME_WAIT，得强制清除它”的想法之前，请先区分它是正常的状态转换，还是短时间内产生了大量连接。
失败与边界条件
切勿仅凭单次观察就断定存在端口耗尽（port exhaustion）
切勿仅凭 TIME_WAIT 的数量断定应用程序异常
使用此命令无法看到 NAT、代理（proxy）或负载均衡器（load balancer）背后的状态
短暂的通信可能会错过观察的时机
如果在工作中长效使用
在遇到“Web 偶尔无法连接”、“仅在大量处理后连接出现异常”等咨询时，可以在盲目修改设置之前先记录状态。
Get-NetTCPConnection |
Group-Object State |
Select-Object Name, Count |
Sort-Object Name
将其与时间戳一同保存并对比正常时与故障时的状态，即可作为初步排查咨询的依据。这并非为了让业务人员自行修复，而是将其作为向 IT 部门或厂商传达“哪种状态增加了”的观测手段来使用。
