防火墙规则过长导致吞吐下降，核心是数据包需线性遍历规则链，规则超80–100条即入高风险区；应通过iptables/nftables查规则数、trace定位匹配路径、监控si软中断及NET_RX计数，并结构化筛查冗余规则。
防火墙规则过长直接导致吞吐下降，核心原因是每个数据包必须从头到尾线性遍历规则链，规则越多，平均匹配跳数越高，延迟上升、CPU软中断（si）升高、小包吞吐锐减。排查不靠猜，要抓准路径和指标。
看规则数量与链长度
先确认是否真“过长”：单条链超过80–100条规则就已进入高风险区间。
- 查当前规则总数：
sudo iptables -L INPUT --line-numbers | wc -l（含标题行，减2即实际条目） - 对比各链规模：
sudo iptables -L INPUT FORWARD OUTPUT -n --line-numbers | grep "^[0-9]" | wc -l，重点盯 FORWARD 链（网关/多网卡场景最易堆积） - nftables 用户用：
sudo nft list chain inet filter input | grep 'iif' | wc -l，注意 sets 和 maps 不计入行数但影响匹配效率
抓包+匹配路径验证
规则再多，真正拖慢的是高频流量的匹配路径。用 tcpdump + iptables trace 定位“谁在慢路上”：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 开启 trace（临时）：
sudo iptables -t raw -A PREROUTING -s 192.168.10.5 -j TRACE（替换为典型客户端IP） - 同时抓包：
sudo tcpdump -i any port 22 -n -c 3 - 查看内核日志：
sudo dmesg -T | tail -20，观察是否出现“rule 42”“rule 78”等深层匹配记录——若高频连接总落到后半段规则，说明顺序不合理
监控软中断与CPU分布
规则遍历是内核软中断（softirq）密集型操作，不是用户态CPU问题：
- 运行
top，按 1 显示所有CPU核心，观察 si（softirq）列是否持续 >15%；若 sy（system）也高，可能叠加 conntrack 压力 - 细分查看：
cat /proc/softirqs | grep -E "(NET|TIMER)"，重点关注 NET_RX 和 NET_TX 计数突增 - 对比有无防火墙时的吞吐：用
iperf3测试同一网段直连吞吐，再开防火墙跑一次，下降超15%且 si 明显升高，基本可锁定规则链瓶颈
快速定位冗余与低效规则
不用逐条读，用结构化方法筛出“可疑分子”：
- 找重复协议+端口组合：
sudo iptables -L INPUT -n | awk '{print $5,$6,$7}' | sort | uniq -c | sort -nr | head -5（例：tcp dpt:22 出现23次，大概率该聚合） - 找孤立源IP规则：
sudo iptables -L INPUT -n | awk '$4 ~ /^([0-9]{1,3}\.){3}[0-9]{1,3}(\/[0-9]+)?$/ {print $4}' | sort | uniq -c | awk '$1==1'（只出现1次的IP，优先考虑移入 ipset） - 检查默认策略是否为 DROP 且无显式放行 established：
sudo iptables -L INPUT -n | grep "state RELATED,ESTABLISHED"—— 若缺失，每条新连接都要走完整链，开销翻倍
