连接失败时最显眼的数字未必是原因。TIME_WAIT多可能只是短连接频繁CLOSE_WAIT持续增长则需要沿着进程和文件描述符找应用的关闭路径。把两者都塞进“连接堆积”告警再让 Agent 自动调参会丢掉最关键的区别。三种状态三条调查路径Linux IP sysctl 文档对tcp_fin_timeout的定义很具体它约束的是已经成为 orphan 的FIN_WAIT_2连接。它不是缩短TIME_WAIT的开关也不会替应用执行close()。tcp_tw_reuse也有独立语义和适用前提不能看见状态计数高就全局打开。我会先问四个问题失败发生在出向连接还是入向连接错误是否包括EADDRNOTAVAIL连接集中在哪些目的地址相同业务量下连接创建速率和连接池命中率是否变化临时端口的可用性与四元组、源地址选择和连接行为有关不能把端口范围宽度当成整台机器的并发上限。图中的三条通道互不替代。尤其是CLOSE_WAIT它说明对端已开始关闭、本地尚未完成关闭值得排查但单次快照不足以断言“百分之百泄漏”。有意延迟关闭、请求仍在处理和真正的资源泄漏要靠持续时间与持有者证据区分。让第一版 Agent 只生成调查建议下面是可直接运行的 Python 3 示例。输入全部是教学数据程序不读取真实主机更不写 sysctl。用错误码约束建议比给每种高计数配一条修改命令更有用。from collections import Counter def advise(states, errors): counts Counter(states) result [] if counts[TIME_WAIT]: result.append(measure_connection_rate_and_destination_skew) if EADDRNOTAVAIL in errors: result.append(inspect_source_addresses_and_ephemeral_ports) if counts[CLOSE_WAIT]: result.append(trace_socket_owner_and_application_close_path) if counts[FIN_WAIT_2]: result.append(verify_orphan_status_before_fin_timeout_review) return result normal advise([TIME_WAIT] * 20, []) assert inspect_source_addresses_and_ephemeral_ports not in normal assert len(advise([CLOSE_WAIT], [])) 1 failure advise([TIME_WAIT, FIN_WAIT_2], [EADDRNOTAVAIL]) assert inspect_source_addresses_and_ephemeral_ports in failure assert all(apply not in item for item in failure) print(normal) print(failure)计数阈值在这里刻意没有出现。它必须来自业务基线、采样窗口和失败比例而不是从文章里复制一个“超过一万就自愈”。下一步接入真实采集时还应附上 network namespace、内核版本、进程标识和时间范围没有这些字段两次查询可能根本不是同一个观察对象。修改发生在诊断之后连接池、超时和重试也可能制造短连接风暴。先在隔离环境验证应用侧改变比较请求成功率、连接建立耗时和目的端负载再决定是否需要系统参数变更。一次参数实验至少要有原值、目标节点范围、回滚条件和观察窗口。这个例子只验证建议分流逻辑没有验证真实套接字采集、端口耗尽复现或内核调参效果。TCP 诊断 Agent 的第一份成绩单应是“少给错误命令、把证据指向正确负责人”而不是没有实验记录的秒级自愈。