防火墙不直接降低网卡吞吐，但通过静默丢包、conntrack耗尽或规则匹配开销间接导致吞吐异常；需检查iptables/nftables DROP/REJECT规则计数增长、conntrack表满（dmesg查nf_conntrack.full）、tcpdump验证SYN有入无出，并排查xt_hashlimit等高开销模块。
防火墙本身不直接导致网卡吞吐下降，但它可能通过静默丢包、连接跟踪耗尽或规则匹配开销间接引发吞吐异常。排查需聚焦 iptables/nftables 规则行为、conntrack 状态及内核日志，而非网卡硬件统计。
检查 iptables/nftables 是否存在 DROP/REJECT 规则
运行以下命令查看所有链的规则及其匹配计数：
- iptables -L -n -v：重点观察 INPUT、FORWARD、OUTPUT 链中 target 为 DROP 或 REJECT 的行，右侧的 pkts 列是否持续增长
- iptables -t nat -L -n -v：NAT 表规则也可能影响连接建立（如 SNAT/DNAT 失败）
-
nft list ruleset（若使用 nftables）：查找带有
drop、reject或未显式accept的链末尾默认策略
确认 conntrack 表是否满载
连接跟踪表溢出会导致新建连接的 SYN 包被丢弃，表现为“能 ping 通但端口不可达”，且吞吐在高并发时骤降：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 执行 dmesg | grep -i "nf_conntrack.*full"，出现
table full, dropping packet即确认问题 - 查看当前状态：conntrack -S，关注
insert_failed是否非零 - 检查当前连接数：conntrack -C，对比 sysctl net.netfilter.nf_conntrack_max
验证丢包是否发生在防火墙路径
仅靠 netstat 或 /proc/net/dev 无法体现防火墙丢包——它发生在 netfilter 框架，不计入 Rx-DRP/Rx-OVR：
- 抓包位置要选对：tcpdump -i eth0 'port 8080' -w firewall-test.pcap，再用 Wireshark 查看是否有 SYN 进来但无 SYN-ACK 发出
- 若 eth0 能抓到客户端 SYN，但服务进程（如 netstat -tlnp）没看到对应监听连接，且 dmesg 有 conntrack 满提示，基本锁定防火墙层
- 临时绕过测试：iptables -P INPUT ACCEPT && iptables -F（生产环境慎用，建议先备份
iptables-save > backup.ipt）
排查 nf_tables 或 xt_recent 等扩展模块开销
某些高级匹配模块（如 IP 限速、黑名单、地域过滤）在高流量下会显著增加 CPU 开销，拖慢整个 netfilter 流程：
- 检查规则中是否含
xt_hashlimit、xt_recent、ipset大集合匹配等高成本动作 - 用 top -H 或 perf top 观察软中断线程（如 ksoftirqd/0）CPU 占用是否异常偏高
- 对比开启/关闭某条复杂规则前后的 cat /proc/net/nf_conntrack | wc -l 和响应延迟变化
