iptables规则链匹配顺序决定性能，应让90%以上流量在前3条规则内完成匹配：首条为established/related放行，次条https，再http等按访问量降序排列；ssh、数据库等低频端口靠后；用multiport合并端口、ipset聚合ip；主链仅作快速决策，复杂逻辑下沉至自定义链；禁用-j return；通过计数器验证规则实效性。

高性能服务器上，iptables规则链的匹配顺序直接决定每毫秒能处理多少数据包。关键不是堆砌规则，而是让最常经过的数据包在最少步数内完成匹配——理想情况是前3条规则覆盖90%以上流量。

高频流量规则必须置顶

INPUT链首条规则应始终是状态跟踪放行：

• -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT（比旧版-m state更高效）
• 紧随其后放业务主端口，如HTTPS：-A INPUT -p tcp --dport 443 -j ACCEPT
• 再接HTTP、健康检查端口（如80、8080、/health），按实际访问量从高到低排
• 把SSH（22）、数据库（3306）等管理或低频端口放在靠后位置

合并端口与聚合IP，压缩规则行数

避免为每个端口写一条规则，也别为每个黑名单IP单独加DROP：

• 用multiport一次匹配多个服务端口：-A INPUT -p tcp -m multiport --dports 22,80,443,8080 -j ACCEPT
• 用ipset管理动态IP集合：先创建ipset create adminips hash:ip，再用-A INPUT -m set --match-set adminips src -j ACCEPT
• 对CDN回源、监控探针等固定来源网段，优先用ipset而非重复添加-s x.x.x.x/24

主链精简，逻辑下沉到自定义链

INPUT/FORWARD链只做“要不要进”“要不要转”的快速决策，具体判断交给子链：

• 把所有Web相关规则移入HTTP_FILTER链：-A INPUT -p tcp --dport 80 -j HTTP_FILTER
• 在HTTP_FILTER中统一处理User-Agent、URL路径、速率限制等，避免主链反复加载模块
• 慎用-j RETURN——它会让数据包重新从链头开始匹配，破坏早终止优势

用计数器验证实效性，不凭感觉调优

运行iptables -L INPUT -v -n --line-numbers，重点看packet列：

• 长期为0的规则，说明前置规则已拦截全部匹配流量，可删除或调整位置
• 某条ACCEPT规则计数远低于预期，说明它被前面的DROP/REJECT提前截断
• DROP规则突增且来源集中，需确认是真实攻击还是误配了过于宽泛的-s匹配