Proxy Slowdowns Over Time: Check Conntrack and Resource Limits

The proxy is responsive after a restart. A few hours later, new connections stall. Restarting it buys another quiet interval. That pattern suggests accumulating state, but it does not identify which state is responsible.

On a Linux path using connection tracking, one candidate is the conntrack table. Check these existing values on the machine and in the network namespace handling the traffic:

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

The first reports allocated flow entries; the second limits them. They are not counts of Squid users or HTTP requests. Kernel flow state can outlive the application's active work.

Look for a relationship, not just a large number

Compare occupancy over time with the onset of new-connection failures and relevant kernel messages. A high count with no matching failure evidence is different from a table repeatedly reaching its limit as requests begin timing out.

The table may serve more than the proxy. Other local services, forwarded traffic or another busy network path can contribute. A proxy restart changing the symptom does not prove that Squid's object cache caused it.

Keep the competing explanations in view: file descriptors, authentication-helper queues, DNS delays, memory pressure and a full filesystem can also worsen over time. Record which resource grows and which operations stop working first. Long-lived connections surviving while new ones fail is useful evidence, not a diagnosis on its own.

Increasing a limit has a memory cost. Before changing it, establish the workload, namespace and available capacity. Shortening timeouts indiscriminately can break useful idle sessions; flushing all connection state can disrupt unrelated traffic.

The useful result is an explanation for the buildup and a capacity or lifecycle change that fits it. “Safe to increase” is not a property every proxy server shares.