代理随时间变慢：检查 conntrack 与资源上限

代理在重启后能正常响应。几个小时后，新连接开始停滞。再重启一次又能换来一段安静期。这种模式说明有状态在累积，但并不能指出是哪种状态造成的。

在使用连接跟踪的 Linux 路径上，一个候选对象是 conntrack 表。请在机器上以及处理流量的网络命名空间中查看这些已有数值：

/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_max

前者报告已分配的流表项，后者限制其上限。它们不是 Squid 用户数或 HTTP 请求数的计数。内核的流状态可能比应用的活跃工作存活得更久。

要找关系，而不只是一个大数字

把占用率随时间的变化与新连接故障出现的时间点以及相关内核消息对照起来。数值很高但没有相应故障证据，与请求开始超时时表反复达到上限，是两回事。

这张表服务的对象可能不止代理。其他本地服务、被转发的流量或另一条繁忙的网络路径都可能有所贡献。重启代理改变了症状，并不能证明是 Squid 的对象缓存造成的。

要把相互竞争的解释放在视野里：文件描述符、认证辅助进程队列、DNS 延迟、内存压力以及文件系统写满，同样会随时间恶化。记录哪项资源在增长、哪些操作最先失效。长连接存活而新连接失败是有用的证据，但本身不是诊断。

提高上限要付出内存代价。改动之前，先确定工作负载、命名空间和可用容量。不加区分地缩短超时可能破坏有用的空闲会话；清空全部连接状态可能干扰无关流量。