应优先检查规则匹配耗时和连接跟踪压力：iptables中RELATED/ESTABLISHED命中率低、nftables中规则跳过异常、conntrack表满或insert_failed增长、大型IP列表未用ipset均会导致吞吐下降。
直接看规则匹配耗时和连接跟踪压力，而不是先查CPU或带宽——吞吐下降常因每包要扫几十甚至上百条规则，或 conntrack 表爆满卡住协议栈。
检查规则数量与命中率分布
规则越多、越靠后才命中的情况越危险。用以下命令快速评估：
-
iptables：运行
iptables -L -n -v | head -20，重点关注 INPUT/OUTPUT 链前几行的 packets 计数。如果第1条是ct state RELATED,ESTABLISHED但计数只占总流量 30%，说明大量新连接没走快速路径 -
nftables：执行
nft list ruleset -a（加-a显示句柄），再用nft monitor trace抓几个典型请求，看实际走了哪几条规则、是否跳过中间大段 - 发现某条规则 packets 为 0 或长期无增长，基本可判定是僵尸规则，应优先清理
定位 conntrack 成为瓶颈
UDP 小包、DNS、健康检查类流量若被强制进连接跟踪，会迅速拖垮性能。验证方法：
- 运行
conntrack -S，观察entries是否接近max值，insert_failed是否持续增长 - 查内核日志：
dmesg | grep -i "nf_conntrack.*full"，出现即表示跟踪表溢出丢包 - 临时降低超时值测试影响：
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=300，若吞吐回升，说明原默认 5 天超时导致表堆积
验证是否被线性匹配拖慢
当 IP 白名单/黑名单超过 200 条，还用普通 iptables -s 逐条比对，延迟会明显上升：
- 用
ipset list查是否有大型 set；若全是单条-s 1.1.1.1 -j ACCEPT规则，大概率是瓶颈点 - 对比前后性能：把离散规则导出为 ipset，例如
ipset create allow_ips hash:ip; while read ip; do ipset add allow_ips $ip; done ，再改规则为 <code>iptables -I INPUT -m set --match-set allow_ips src -j ACCEPT - nftables 用户直接用
nft add set ip filter trusted_ips { type ipv4_addr\; }，支持 timeout 和自动合并，比 ipset 更轻量
绕过非必要跟踪与日志
很多规则本身不需要状态，却被迫走 conntrack + 日志路径，白白增加开销：
- DNS 响应、负载均衡探针、内部监控上报等明确无状态的流量，加
notrack：nft add rule ip raw PREROUTING udp dport 53 notrack - 删掉所有带
-j LOG的规则，尤其在链尾；如需审计，改用nft monitor trace或内核 ftrace 按需开启 - 确认默认策略是 DROP，而不是一堆
-j REJECT放在最后——REJECT 要构造响应包，比 DROP 多一次协议栈处理
