在/proc我有两个条目nf_conntrack_max：
的/ proc / SYS /网/ netfilter的/ nf_conntrack_max 的/ proc / SYS /网/ nf_conntrack_max
似乎指向相同的价值作为改变一个也改变另一个。 将这两个设置在/etc/sysctl.conf ：
net.netfilter.nf_conntrack_max = 65528 net.ipv4.netfilter.ip_conntrack_max = 65535
重新启动后，该值仍为32764，因此更改无效。 有没有人遇到过这个？ 我的猜测是，这些值是在相关的模块加载之前应用的，但希望也许有人已经知道解决scheme。
这是因为/proc/sys/net/nf_conntrack_max依赖于模块nf_conntrack 。 但是系统启动时这个模块默认不会被加载。
但如果你跑步
iptables -t nat -L
要么
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
这个模块会自动加载并设置为你系统支持的最大数量（如果你的RAM大于4G，最大数量是65536，但是在不同的系统中会有所不同）。你可以在/etc/sysctl.conf设置一个更大的数字（比如6553600） /etc/sysctl.conf ）。
解答 ：
在文件/etc/modules的末尾添加一行：
nf_conntrack
这个模块会在执行sysctl之前在系统启动时加载。
我不使用Ubuntu，但是在我的CentOS思路中想到了这一点，我提出了同样的假设 – 系统pipe理已经被应用得太早了。 一些seaching显示这是自2006年以来的一个存档错误 。
它看起来像把另一个符号链接在优先> S40再次运行procps初始化脚本可能会做你所需要的。 根据bug总结，看起来像是对Ubuntu的sysctl方法进行了一些重新devise（有趣的是，这个bug被分配给了一个不知道它被分配的人，并且不能帮助它）。
因为它应该是：
net.netfilter.nf_conntrack_max = 65535
现在，您可以在不使用以下命令重新启动的情况下进行设置： sysctl -p /etc/sysctl.conf