iptables规则链匹配顺序直接影响每毫秒数据包处理量，核心是让高频流量在最少步数内匹配：首条应为状态跟踪放行established/related连接，次置业务端口（443/80/8080等按访问量降序），低频端口（22/3306）靠后；用multiport合并端口、ipset聚合ip；复杂逻辑下沉至自定义链；禁用-j return；通过iptables -l -v验证计数器实效性。
iptables规则链匹配顺序直接决定每毫秒能处理多少数据包。关键不是规则数量多，而是让最常经过的数据包在最少步数内完成匹配——理想情况是前3条规则覆盖90%以上流量。
高频规则必须置顶
INPUT链首条规则应始终是状态跟踪放行：
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
这条规则能跳过绝大多数双向通信流量（如HTTP响应、TCP ACK等），比旧版-m state更高效。紧随其后放业务主端口：HTTPS（443）、HTTP（80）、健康检查端口（如8080、/health），按实际访问量从高到低排列。SSH（22）、数据库（3306）等低频管理端口必须靠后，否则每条包都要遍历几十条规则才匹配到它们。
合并端口与聚合IP，压缩规则行数
避免为每个端口或每个黑名单IP单独写一条规则：
- 用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匹配
