因此，我定期运行lsof -i | wc -l，它告诉我在 420 行中，有 240 到 255 行处于CLOSE_WAIT状态。TCP 连接如何进入此状态？
我应该担心吗？我应该如何排除故障？
答案1
（我本来要编辑 mikegrb 的答案，但觉得我把它改得有点过了）
CLOSE_WAIT 的意思与字面意思完全一致——内核正在等待本地进程关闭其文件描述符，然后再删除条目。TCP 连接已完全断开，远端可能认为连接已结束，但您的一端仍在保留连接。
唯一需要担心的是，大量的 CLOSE_WAIT 条目会消耗内核内存和文件描述符表条目，如果有大量条目，这可能会成为问题。如果您正在查看的条目是瞬态的，那么可能只是您正在循环很多TCP 连接，并且您在关闭连接和关闭文件描述符之间的短暂时间内只看到一小部分。另一方面，如果它们是永久性的（端口和 IP 地址不会随时间而变化），那么就是有东西泄漏了描述符，需要修复它，以便在使用完它们后始终关闭它的 fds。正如 mikegrb 所说，较新的版本可能已经解决了该问题，因此可能需要在相关邮件列表中提问或检查变更日志。
答案2
CLOSE_WAIT 状态表示另一端发送了 FIN 段来关闭连接。连接仍然处于建立状态。您可以将其视为半双工模式，允许此端刷新任何缓冲区，在从此端关闭连接之前，将最后几位数据发送到请求关闭连接的一端。
如果有大量连接处于 CLOSE_WAIT 状态，则意味着负责的进程在套接字进入 CLOSE_WAIT 状态后不会关闭套接字。您可以使用 tcpdump 或其他网络流量捕获工具来查看数据包。
还要查看负责的进程。出于好奇，负责的进程是什么？它可能有较新的修复版本可用，或者也许是时候提交错误报告了；）
答案3
如果您在弱网络中操作，您可以调整：
ulimits通过和通过/proc（系统范围）的最大文件描述符数量- 您可以通过以下方式缩短 TCP 等待时间
/proc
答案4
您可能没有关闭服务器上正在运行的应用程序中某个地方的资源（文件句柄、网络连接）。