CLOSE_WAIT状态是TCP连接关闭过程中的一个中间状态。当对端主动发送FIN报文请求关闭连接，而本端没有立即调用close()或shutdown()进行响应时，连接就会停留在CLOSE_WAIT状态。在Apache反向代理缓存架构中，Apache作为代理服务器既接受客户端连接，也向后端服务器发起连接。如果后端服务器率先关闭连接，Apache却因为某些原因没有关闭对应的套接字，就会在后端连接侧产生CLOSE_WAIT堆积。长期堆积会导致文件描述符耗尽、连接表占满，最终使缓存服务不可用。
一、CLOSE_WAIT状态在Apache代理缓存中的形成机制
要理解CLOSE_WAIT的产生，需要回顾TCP四次挥手。主动关闭方发送FIN，被动关闭方回复ACK，此时被动关闭方进入CLOSE_WAIT，然后等待应用层调用close()，发送最后一个FIN完成关闭。如果应用层由于代码缺陷、资源泄漏或阻塞没有调用close()，连接就永远停留在CLOSE_WAIT。
在Apache反向代理缓存场景中，Apache使用mod_proxy模块与后端服务器通信。根据配置不同，Apache与后端可能使用持久连接（KeepAlive）或者短连接。当后端服务器因为超时、错误或主动断开连接时，Apache需要及时关闭对应的后端连接。如果Apache的工作进程处于繁忙状态、代码存在bug或者配置不当导致连接没有被正确回收，CLOSE_WAIT就会逐渐累积。尤其是当缓存命中率较低，大量请求穿透到后端，连接频繁创建和销毁时，问题更容易暴露。
此外，PHP-FPM、Tomcat等后端应用如果在处理请求后没有正确关闭连接，或者Apache与后端之间的负载均衡器、防火墙提前断开连接，也可能造成Apache侧出现CLOSE_WAIT。因此排查时需要同时关注Apache本身和后端服务的连接管理行为。
二、排查Apache代理缓存CLOSE_WAIT堆积的详细步骤
第一步是确认CLOSE_WAIT连接的数量和归属进程。使用ss -tan state close-wait可以列出所有处于CLOSE_WAIT状态的TCP连接，包括本地地址、对端地址和关联的进程号。如果连接数较多，可以配合awk统计各进程的CLOSE_WAIT数量。
# 查看所有CLOSE_WAIT连接
ss -tan state close-wait
# 统计各进程的CLOSE_WAIT数量
ss -tanp | grep CLOSE_WAIT | awk '{print $7}' | sort | uniq -c | sort -nr
第二步是定位Apache进程。Apache使用多进程或线程模型，ss -tanp的输出中会包含进程名和PID。找到CLOSE_WAIT连接对应的PID后，使用lsof -p PID查看该进程打开的所有文件描述符，确认哪些连接没有释放。也可以使用strace -p PID -e trace=network追踪该进程的网络系统调用，观察它是否在接收到FIN后没有执行close()。
# 查看指定进程的网络连接 lsof -p 12345 -i # 追踪进程的网络系统调用 strace -p 12345 -e trace=network -f
第三步是抓包分析TCP挥手过程。使用tcpdump捕获Apache与后端服务器之间的流量，过滤特定IP和端口，观察FIN、ACK报文的顺序。如果后端发送FIN后Apache迟迟没有回复最后一个FIN，说明应用层没有关闭套接字。
# 抓取Apache与后端192.168.0.1:8080的TCP流量 tcpdump -i any host 192.168.0.1 and port 8080 -w /tmp/close_wait.pcap
通过以上步骤，可以确定CLOSE_WAIT是集中出现在Apache进程，还是某些特定后端地址，从而缩小问题范围。
三、解决CLOSE_WAIT问题的配置调整与代码修复
根据排查结果，解决方案从Apache配置和后端服务两方面入手。如果是因为Apache与后端使用KeepAlive但后端提前断开，可以在ProxyPass指令中调整连接池参数，设置适当的timeout和ttl，让Apache主动回收空闲连接。
# 配置ProxyPass连接池，设置timeout和ttl
<Proxy balancer://backendcluster>
BalancerMember http://192.168.0.1:8080 timeout=5 ttl=60
ProxySet lbmethod=byrequests
</Proxy>
ProxyPass / balancer://backendcluster/
ProxyPassReverse / balancer://backendcluster/
需要说明，这里timeout表示Apache等待后端响应的超时时间，ttl表示后端连接的存活时间。合理设置这两个值可以避免连接被长时间占用。同时检查Apache主配置中的KeepAliveTimeout和MaxKeepAliveRequests，确保与后端服务的KeepAlive设置匹配。
# Apache与客户端侧的KeepAlive配置 KeepAlive On KeepAliveTimeout 5 MaxKeepAliveRequests 100
如果问题源于后端应用（如PHP-FPM、Tomcat）没有正确关闭连接，需要检查后端服务的连接管理配置。例如PHP-FPM的pm.max_requests设置过大会导致工作进程长时间运行，积累未关闭的连接；Tomcat的连接器需要设置合适的keepAliveTimeout和maxKeepAliveRequests。同时，确保应用程序在异常处理路径中正确执行close()或使用连接池的release()方法。
还可以调整操作系统内核参数，缩短TCP的TIME_WAIT和CLOSE_WAIT的清理周期。但需要谨慎，CLOSE_WAIT本身不是内核可以直接清除的，必须由应用关闭。不过可以通过net.ipv4.tcp_keepalive_time等参数让内核更快探测失效连接。
# 调整TCP keepalive参数 sysctl -w net.ipv4.tcp_keepalive_time=600 sysctl -w net.ipv4.tcp_keepalive_intvl=30 sysctl -w net.ipv4.tcp_keepalive_probes=3
四、监控与预防措施
为了避免CLOSE_WAIT问题再次发生，建议建立连接状态监控。可以使用Zabbix、Prometheus配合node_exporter采集ss -tan的输出，对CLOSE_WAIT连接数设置阈值告警。当数量超过一定值时及时介入。
同时定期审查Apache配置和后端服务日志，关注连接超时和重置相关的错误。在部署新版本后，进行压力测试，观察连接数变化曲线，提前发现连接泄漏问题。
最后，如果Apache进程频繁出现CLOSE_WAIT且无法通过配置解决，可以考虑升级Apache版本或更换代理模块（如使用mod_proxy_http2），旧版本可能存在连接管理bug。保持系统和软件更新是防止此类问题的有效手段。
Apache代理缓存CLOSE_WAIT连接排查修改时间：2026-08-21 06:45:54