iptables高负载性能下降主因是规则链线性匹配开销、conntrack表满及容器平台规则污染；需检查规则数超300条、nf_conntrack_count超90% max值、FORWARD链跳转嵌套过深。
iptables 在高负载下性能下降，往往不是因为“规则写错了”，而是规则链结构、内核子系统协同和运行时状态共同作用的结果。识别瓶颈的关键，在于跳过表象（比如 CPU 高），直接定位到数据包处理路径中最耗时的环节。
看规则链长度与匹配顺序
iptables 每个数据包都要从头到尾遍历规则链，线性匹配。规则越多、越靠后才命中，开销越大。
- 用 iptables -t filter -nL INPUT --line-numbers | wc -l 统计 INPUT 链规则数；FORWARD 和 OUTPUT 同理。超过 100 条就需警惕，300+ 条常导致毫秒级延迟累积
- 重点检查是否在链首插入了无意义的 LOG 或 REJECT 规则——它们会强制每个包都走完整条链，哪怕后续有 ACCEPT
- 避免“先 DROP 再 ACCEPT”式反向逻辑；应把高频放行规则（如已建立连接）放在最前面：-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
查 conntrack 表是否打满
Docker、Kubernetes 或大量短连接场景下，nf_conntrack 是隐形杀手。表项耗尽时，新连接会被阻塞等待释放，表现像“网络卡顿”，实则是连接跟踪层排队。
- 执行 cat /proc/sys/net/netfilter/nf_conntrack_count 查当前使用量
- 对比 cat /proc/sys/net/netfilter/nf_conntrack_max（默认通常为 65536）；若前者长期 >90% max，就是瓶颈
- 运行 conntrack -L | grep -E "(TIME_WAIT|UNREPLIED)" | head -15，观察是否有大量未清理的残留状态
盯住内核态 CPU 消耗来源
top 显示 CPU 高，但要分清是用户进程占的，还是内核在替 iptables 和 netfilter 卖力干活。
- 用 mpstat -P ALL 1 观察 %sy（系统态）是否持续 >25%，高 sys 往往指向 netfilter 规则匹配、conntrack 查表或 nat 转换开销
- 配合 perf top -e 'net:*' -a（需 perf 工具），可直观看到内核中 netfilter 相关函数（如 nf_iterate、ip_vs_invert_tuple）是否高频出现
- 若 %soft（软中断）也同步飙升，说明网卡收包后在内核协议栈中被大量拦截、重定向，进一步印证规则链或 conntrack 压力过大
验 FORWARD 链是否被 Docker/K8s 污染
容器平台常自动注入 DOCKER-USER、KUBE-FIREWALL 等链，且不清理旧规则，导致链深度失控、跳转嵌套过深。
- 运行 iptables -t filter -S FORWARD | grep -c '\-j' 统计跳转次数；每多一次 -j，就多一次链切换开销
- 检查 iptables -t filter -nL DOCKER-USER --line-numbers，确认是否存在重复加载、空规则或冗余跳转
- 临时清空 DOCKER-USER 并只留一条 -I DOCKER-USER -j ACCEPT，观察吞吐是否回升——若明显改善，说明原规则集已成负担
