iptables 规则过多导致延迟时，优先通过 ipset 集合匹配减少遍历次数，或调整规则顺序将高频命中规则前置。适用场景为规则数量达到数千条以上且 CPU 软中断占比高的情况。修改防火墙规则存在中断网络连接的风险，操作前必须保留恢复通道。

命令速用版

# 统计规则总数
iptables -L -n -v | wc -l

# 查看规则命中计数（关注 packets 列）
iptables -L -n -v

# 查看连接跟踪表大小
cat /proc/net/nf_conntrack | wc -l

# 临时清空计数器以便观察新流量
iptables -Z

为什么会这样

iptables 规则匹配采用线性遍历机制，数据包会按顺序逐条比对直到命中或到达链尾。当规则数量增加时，每个数据包需要执行的指令周期随之增加，导致 CPU 处理开销变大。公开资料中没有看到可靠的量化数据说明具体多少条规则会产生明显延迟，这取决于 CPU 性能、网卡中断处理能力及流量并发模型。此外，连接跟踪表（conntrack）满也会导致新连接建立变慢或丢包，常被误判为规则过多问题。

分步处理

步骤 1：统计规则规模与命中率
适用场景：怀疑规则过多影响性能。
操作动作：执行iptables -L -n -v，观察 rules 数量及 packets 列。
验证结果：若规则数超过数千条且多条规则 packets 计数增长缓慢，说明存在无效遍历。
风险边界：只读命令，无风险。

步骤 2：使用 ipset 合并 IP 规则
适用场景：存在大量针对单个 IP 或网段的允许/拒绝规则。
操作动作：安装 ipset，创建集合，将 IP 加入集合，修改 iptables 规则匹配集合。
验证结果：规则条数显著减少，匹配时间复杂度从 O(N) 降为 O(1)。
风险边界：配置错误可能导致合法 IP 被误拦，需先测试后生效。

步骤 3：调整规则顺序
适用场景：高频业务规则位于链尾。
操作动作：使用-I参数将高频规则插入链首，或删除旧规则后重新添加。
验证结果：高频规则 packets 计数增长快，且位于列表上方。
风险边界：顺序错误可能绕过安全限制，需严格测试业务逻辑。

步骤 4：检查连接跟踪表
适用场景：网络间歇性卡顿或新连接建立慢。
操作动作：检查/proc/sys/net/netfilter/nf_conntrack_count与max值。
验证结果：若 count 接近 max，需调大最大值或缩短超时时间。
风险边界：调大最大值会增加内存占用。

怎么验证是否生效

使用ping命令测试延迟波动，观察top命令中si（软中断）CPU 使用率是否下降。再次执行iptables -L -n -v，确认高频规则命中计数正常增长且规则总数减少。若业务有监控面板，查看请求响应时间（RT）曲线是否平稳。

常见坑

• 规则顺序错误：iptables 按顺序匹配，第一条命中即停止，把拒绝规则放在允许规则之后会导致允许规则失效。
• 远程操作风险：直接修改远程服务器的防火墙规则可能导致 SSH 连接断开，务必先设置定时恢复或使用 screen 会话。
• 忽略 conntrack：有时延迟来自连接跟踪表满而非规则多，需区分排查。
• 持久化遗漏：修改后未保存规则，重启后失效，需使用iptables-save或对应发行版工具保存。

常见问题

iptables 和 nftables 性能差距大吗？

nftables 是 iptables 的继任者，底层使用更高效的数据结构，规则数量极大时性能更好。如果规则集非常庞大且需要复杂逻辑，建议迁移到 nftables，但迁移成本较高。

删除 unused 规则会影响业务吗？

删除长期命中计数为 0 的规则通常安全，但需确认是否为防御性规则（如拦截特定攻击 IP）。建议先置为日志记录观察一段时间再删除。

规则优化后需要重启服务器吗？

不需要。iptables 规则修改立即生效，但需确保当前会话不被新规则阻断，且修改后需保存配置以防重启丢失。