我正在扩展前端代理服务器，直到昨天我还在使用 Squid 作为反向代理（尽管基本上没有缓存任何内容，即 Squid 仅用于代理）。今天我尝试更改为 nginx，我注意到我更快地达到 ip_conntrack 限制。
作为一个短期的解决方法，我只是提高了 ip_conntrack 限制（按照http://rackerhacker.com/2008/01/24/ip_conntrack-table-full-dropping-packet）但我想知道这里是否有人知道为什么 nginx 会如此迅速地达到这些限制，以及是否可以采取什么措施来纠正它？（即更快地从跟踪表中弹出连接）。
使用的内容是最新的 Centos 5.5 盒、nginx 0.8.53 和 Squid 2.6。所有内容都是通过 RPM 安装的（核心或 EPEL）。
提前感谢任何建议或启发性的讨论。
就我自己的参考而言，这个其他线程对这个主题很有用：确定 nginx 反向代理负载限制
答案1
我找不到与 conntrack 直接相关的文档，但请看一下 Nginx 的这个代码片段文档：
在反向代理情况下，max_clients 变为
最大客户端数 = worker_processes * worker_connections/4
由于浏览器默认打开 2 个到服务器的连接，并且 nginx 使用来自同一池的 fds（文件描述符）连接到上游后端
Nginx 使用默认浏览器的行为是从浏览器接收两个连接并打开两个到后端的连接（反向代理），因此总共生成 4 个连接。这可能是 conntrack 填充速度更快的原因。当然，这只是基于 nginx 工作器行为的半知情猜测。
答案2
对端口 80 使用 ip_conntrack 会浪费资源。将这些数据包标记为 NOTRACK，对其他端口使用 ip_conntrack。