防火墙性能瓶颈主要在规则顺序、conntrack 表溢出和持久化配置：高频规则需前置，conntrack 满会导致新建连接失败，firewalld 临时规则重启失效，nftables 虽高效但语法不兼容。
iptables 规则顺序直接影响匹配速度
规则越靠前，越早被检查；一旦匹配就停止后续遍历。所以高频流量对应的规则（比如放行 ssh 或 http）必须放在前面，否则每条包都要扫完整个规则链。
- 把
-A input -p tcp --dport 22 -j ACCEPT放在拒绝所有规则之前，否则 SSH 连接会卡顿甚至超时 - 避免用
-m state --state NEW这类慢匹配模块处理大量连接，现代内核推荐用-m conntrack --ctstate NEW - 规则里带
-m String或-m iprange的，性能开销明显增大，仅在必要时启用
nftables 比 iptables 更轻量，但迁移需注意语法断层
nftables 默认使用哈希/树结构加速查找，规则数量上万时延迟更稳定；不过它不兼容 iptables 语法，直接套用会报错 unknown keyword。
- 旧命令
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080要改写为nft add rule ip nat prerouting tcp dport 80 redirect to :8080 -
nft list ruleset输出是扁平结构，没有链级缩进，排查时容易漏看跳转逻辑 - 若系统同时加载
iptable_nat和nft_nat模块，可能触发冲突，建议卸载 iptables 相关模块再启用 nftables
conntrack 表满导致新建连接失败，不是防火墙规则问题
很多“防火墙突然不通”的现象，实际是连接跟踪表（conntrack）溢出，nf_conntrack_full 计数器上升，内核开始丢弃新连接请求。
- 查当前使用量：
cat /proc/sys/net/nf_conntrack_count，上限看/proc/sys/net/nf_conntrack_max - 短连接多的场景（如爬虫、健康检查），调高
net.netFilter.nf_conntrack_max并缩短超时：net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30 - 用
nft add rule ip filter input ct state invalid drop主动丢弃非法状态包，缓解表压力
firewalld 默认启用 runtime 规则，重启后丢失
firewalld 的 firewall-cmd --add-port=8080/tcp 是运行时生效，系统重启或 firewalld 服务重载后规则消失，容易误判为“策略没生效”。
- 持久化必须加
--permanent参数：firewall-cmd --permanent --add-port=8080/tcp，之后再firewall-cmd --reload - 查看当前真正生效的规则用
firewall-cmd --list-all，别只信--list-ports，后者不显示富规则（rich rules） - 启用
ipset后，firewalld 对大 IP 列表的加载速度比原生 iptables 慢，超过 10 万条时 reload 可能卡住数秒
防火墙性能问题往往藏在 conntrack 设置、规则顺序和持久化逻辑里，而不是规则本身写得“不够高级”。调优前先确认到底是谁在拖慢连接——是匹配耗时、状态表满，还是 reload 时锁住了 netfilter 子系统。