Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working on scaling up a front-end proxy server, and up until yesterday I was using Squid as the reverse-proxy (even though basically nothing was being cached, i.e. Squid was proxying only). Today I tried changing to nginx and I've noticed that I'm hitting ip_conntrack limits a lot more quickly.

As a short-term workaround I'm just raising the ip_conntrack limits (as per but I was wondering if anyone here knows why nginx is hitting these limits so much more quickly, and if anything can be done to rectify it? (i.e. have connections ejected from the tracking tables more quickly).

Things in use are an up-to-date Centos 5.5 box, nginx 0.8.53, and Squid 2.6. Everything is installed from RPMs (either core or the EPEL ones).

Thanks in advance for any advice or enlightening discussion.

For my own reference, this other thread was useful on this topic: Determine nginx reverse-proxy load limits

share|improve this question
up vote 0 down vote accepted

I can't find documentation directly tied to conntrack, but look at this snippet from Nginx documentation:

In a reverse proxy situation, max_clients becomes

max_clients = worker_processes * worker_connections/4

Since a browser opens 2 connections by default to a server and nginx uses the fds (file descriptors) from the same pool to connect to the upstream backend

Nginx behavior with a default browser is to receive the two connections from it and open two connections to the backends (reverse proxying), so generating 4 total connections. That may be the reason why the conntrack is filling faster. Of course, this is just a semi-informed guess based on the nginx worker behavior.

share|improve this answer
That seems like a pretty reasonable explanation. I actually raised all the conntrack limits / hashsize by a x4 multiplier, so this should be about right if your theory is correct. – glenc Mar 29 '11 at 20:20

Using ip_conntrack for port 80 is a waste of resources. Mark these packets as NOTRACK and use ip_conntrack for other ports.

share|improve this answer
Thanks, man! I needed to avoid the tracking the connections of belonging to my NAT gateway and you just provided the solution. – lvella Apr 9 '12 at 4:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.