iptables规则应按匹配频率降序排列，高频流量（如ESTABLISHED连接、HTTPS端口）置前以减少遍历；善用multiport和ipset压缩规则数量；主链精简、复杂逻辑下沉自定义链；定期监控packet计数优化实效性。
iptables规则顺序直接影响数据包匹配效率，尤其在高并发、大规模流量场景下，不合理排序会导致大量数据包遍历冗余规则，显著增加CPU开销。核心原则是：让最常匹配的规则尽量靠前，让能快速终止匹配（如ACCEPT、DROP、REJECT）的规则尽早生效。
按匹配频率降序排列规则
iptables自上而下线性匹配，一旦命中即停止后续检查。因此高频通行流量（如已建立连接的TCP回包、健康检查探针）应优先匹配。
- 将ESTABLISHED,RELATED状态规则放在链首（如
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT），可跳过90%以上双向通信流量 - Web服务中，把HTTP/HTTPS端口放前面（
-A INPUT -p tcp --dport 443 -j ACCEPT），比把SSH（22）或数据库（3306）放前面更符合实际访问分布 - 避免把小众端口或低频策略（如IPMI管理、SNMP）置于高频规则之前
用multiport和ipset减少规则数量
单条规则匹配多个目标，比多条独立规则更高效；ipset则将海量IP/端口聚合为哈希查找结构，时间复杂度从O(n)降至O(1)。
- 合并同类端口：
-A INPUT -p tcp -m multiport --dports 22,80,443,8080 -j ACCEPT - 用ipset管理黑名单：
ipset create blackips hash:ip，再通过-A INPUT -m set --match-set blackips src -j DROP一条规则替代成百上千条-s x.x.x.x -j DROP - 对CIDR频繁变动的业务网段，优先用ipset而非重复增删规则
合理使用跳转链（-j）控制逻辑深度
主链（INPUT/FORWARD/OUTPUT）保持精简，复杂判断下沉到自定义链，既提升可读性，也利于缓存局部匹配结果。
- 例如将所有HTTP相关规则归入
HTTP_FILTER链：-A INPUT -p tcp --dport 80 -j HTTP_FILTER，主链不参与具体URL或User-Agent判断 - 避免在自定义链中反复调用
-m state等开销较大的模块，可在跳转前统一判断连接状态 - 慎用
-j RETURN返回主链——它会重启匹配流程，可能破坏“早终止”优势
定期清理与监控匹配计数
规则是否真正生效？哪条成了性能瓶颈？依赖iptables -L -v -n输出的packet计数列，而非主观猜测。
- 重点关注“packets”列数值长期为0的规则，及时删除或调整位置
- 若某条DROP规则计数突增，需确认是攻击还是误配；若ACCEPT规则计数远低于预期，说明前置规则拦截过度
- 结合
watch -n 1 'iptables -L INPUT -v -n | head -20'实时观察TOP规则匹配速率
