在高并发场景下，如果 iptables 规则数量庞大，最直接的优化方向是减少规则匹配次数，通常建议引入 ipset 集合管理 IP 或迁移到 nftables 架构，适用于规则数超过数百条且 CPU 软中断占用较高的场景。

命令速用版

# 查看当前规则行数
iptables -L -n | wc -l
# 查看各链包计数和字节数
iptables -L -v -n
# 查看连接跟踪表使用情况
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

为什么会这样

iptables 的规则匹配机制本质上是线性遍历。数据包进入网络栈时，内核需要从头到尾逐条比对规则，直到命中或结束。当规则数量较少时，这种开销可以忽略不计；但在高并发场景下，每秒数据包数量巨大，线性匹配会消耗大量 CPU 周期，导致软中断（softirq）升高，进而增加网络延迟。

此外，如果开启了连接跟踪（conntrack），状态表过大也会加剧锁竞争，进一步拖慢处理速度。公开资料中没有看到可靠的量化数据说明具体多少条规则会产生瓶颈，这取决于 CPU 性能和规则复杂度，但经验上单链超过数百条复杂规则就值得关注。

分步处理

1. 清理无效规则

检查是否有重复或不再使用的规则。备份当前规则后，删除冗余条目。

iptables-save > /root/iptables.backup

2. 引入 ipset 优化 IP 匹配

如果需要封禁或放行大量 IP，不要每条写一个规则。使用 ipset 将 IP 存入集合，规则只需匹配集合名，查找复杂度降为 O(1)。

# 创建集合
ipset create blacklist hash:ip
# 添加 IP
ipset add blacklist 1.2.3.4
# 应用规则（注意使用 -j 参数）
iptables -A INPUT -m set `--match-set` blacklist src -j DROP

重要：ipset 规则持久化

ipset 规则默认内存存储，重启失效。必须保存配置并设置开机加载，否则重启后防护失效。

# 保存当前集合
ipset save > /etc/ipset.conf
# 设置开机恢复（根据发行版不同，可写入 rc.local 或 systemd 服务）
echo "ipset restore < /etc/ipset.conf" >> /etc/rc.local
chmod +x /etc/rc.local

3. 调整连接跟踪表大小

如果 conntrack 表满，新连接会被丢弃。根据内存情况适当调大最大值。

# 注意：每 10000 条约消耗 1MB 内存，盲目调大可能导致 OOM
sysctl -w net.netfilter.nf_conntrack_max=1000000

4. 评估迁移 nftables

nftables 是 iptables 的继任者，底层使用集合和树状结构，匹配效率更高。如果内核版本支持（3.13+），可考虑迁移。

5. 性能基准测试与对比

优化前后需使用压测工具量化效果，避免凭感觉判断。

# 使用 wrk 进行 HTTP 压测（示例）
wrk -t12 -c400 -d30s http://your-server-ip
# 或使用 iperf3 测试网络吞吐
iperf3 -c your-server-ip

怎么验证是否生效

使用 watch -n 1 'iptables -L -v -n' 观察规则匹配计数增长情况。使用 top 查看 si（软中断）CPU 使用率是否下降。通过压测工具对比优化前后的延迟（Latency）和吞吐量（Throughput）。

# 查看软中断占比
top -Hi

常见坑

1. 规则顺序错误：iptables 从上到下匹配，高频命中的规则应放在前面。
2. 锁竞争：高并发下 conntrack 表操作可能引发锁竞争，必要时可针对特定流量关闭连接跟踪。
3. 迁移风险：nftables 语法与 iptables 不同，迁移前需在测试环境验证，避免生产环境网络中断。
4. 持久化缺失：修改 iptables 或 ipset 后记得保存规则，重启失效会导致问题复发或防护失效。
5. 内存风险：调整 nf_conntrack_max 需评估内存剩余，防止内存溢出导致系统崩溃。