CLOSE_WAIT 一直不消失，是不是代理IP 的连接没关干净

连接状态里 CLOSE_WAIT 越堆越多，关掉代理IP 客户端才消失，是不是连接没关干净？这话对了一半：CLOSE_WAIT 确实表示连接没关，但没关的是本机这一侧的应用程序，不是代理IP 那头。它说的是对端已经把连接关掉了，本机收到了结束信号，却迟迟没有执行关闭动作。

CLOSE_WAIT 是「对端先关，本机还没关」

一次正常的连接关闭要来回四次：主动关闭的一方先发 FIN，被动的一方回一个 ACK，随后进入 CLOSE_WAIT；等被动一方的应用也调用关闭，才会发出自己的 FIN，走到 LAST_ACK，最后彻底结束。CLOSE_WAIT 就卡在这中间——结束信号已经收到，应用还没做出回应。

它和 TIME_WAIT 是完全不同的两回事。TIME_WAIT 出现在主动关闭的一方，系统内核会保留一段时间再释放，时间到了自动消失；CLOSE_WAIT 出现在被动关闭的一方，内核不负责替应用收尾，只要应用不关，它就一直挂着，直到进程退出才一起清掉。

为什么走代理IP 之后更容易看到它

直连时，本机和目标站点之间只有一条连接，谁先关一目了然。走代理IP 之后变成两段：本机到转发层一段，转发层到目标站点一段。任何一端先断开，另一段都会跟着被动关闭。转发层对空闲连接设有回收时间，到点就主动断开，本机这一侧自然成了被动关闭的一方。

出口切换会带来同样的效果。换一次代理IP 出口，转发层通常会把旧连接断掉，本机上正在使用的连接集体进入被动关闭。切换越频繁，被动关闭的次数越多，回收节奏跟不上，就会在状态表里留下越来越长的名单。

怎么确认堆的是不是同一类

先看数量变化。开着的业务越多数量越高、关掉客户端立刻归零，说明堆积来自客户端这一侧；数量随着某个具体应用同步增减，说明问题在那个应用的连接管理上，和代理IP 链路的关系不大。

再看对端是谁。对端地址集中指向转发层，多半是链路侧的正常回收；对端地址指向各不相同的目标站点，说明是目标站点主动断开，本机应用没跟上。把这两点分开看，后面的处置方向完全不同。

1. 先记录当前数量，关掉代理IP 客户端后再看一次，确认堆积是否来自客户端自身
2. 把客户端升到较新版本，连接回收相关的修复多数在版本更新里
3. 降低出口切换频率，短时间内反复换线会让被动关闭集中出现
4. 长连接业务单独设置空闲超时，让应用自己先关，别等转发层来断

数量级也是判断依据。几十个 CLOSE_WAIT 在长时间运行的机器上属于常见现象，不必紧张；涨到几百上千且持续上升，才说明关闭动作确实被漏掉了。持续上升这个趋势，比某一时刻的绝对值更值得关注。

连接池是另一个高发地带。应用从池子里借出连接、用完应当归还，归还动作如果只在正常路径上执行，异常分支就会漏掉。异常越多的场景，漏掉的连接越多，CLOSE_WAIT 也就越明显。

超时设置要配套。应用的读写超时、连接池的空闲回收时间、转发层的空闲断开时间，三者最好留出先后次序：应用先回收，转发层再断开。次序反了，被动关闭就会落在应用头上。

长连接业务尤其敏感。即时通讯、实时行情、后台同步这类连接常年开着，转发层按空闲时间回收时它们最容易中招。给这类业务加上应用层心跳和主动重连，被动关闭就不会演变成堆积。

排查的顺序建议是：先确认是哪一侧被动关闭，再看是哪个应用没有收尾，最后才动参数。上来就改系统参数往往只是掩盖现象，数量暂时下去了，过一阵还会涨回来。

复查要留出间隔。改完设置后不要立刻下结论，隔一两个业务高峰再看一次状态表，趋势平了才算真正解决。代理IP 链路上的连接问题，多数要在持续观察里才能看出效果。

给连接状态留个观察习惯，比出问题再查要省事得多：定期看一眼 CLOSE_WAIT 的趋势，把它和出口切换的时间点对照，就能分清是应用没收尾还是代理IP 链路在回收。搞清楚这一点，CLOSE_WAIT 就不再是状态表里那串看不懂的字母，而是一个能定位问题的信号。