防火墙不直接降低网卡吞吐，但通过静默丢包、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 和响应延迟变化