iptables性能观测需聚焦计数器、conntrack状态、cpu软中断及链跳转深度：规则命中数反映真实效力，conntrack表使用率超90%将引发丢包，%sy和%soft升高表明netfilter处理过载，forward链-j跳转超5次或input规则超300条会显著增加毫秒级延迟。
iptables 策略生效后，性能数据统计不是看“规则有没有加”，而是看内核在真实流量路径中如何响应——计数器、连接跟踪状态、CPU软中断和链跳转深度共同构成可观测性闭环。关键不在于总数多大，而在于数值变化是否符合业务逻辑与网络行为常识。
规则命中计数（Pkts/Bytes）反映策略实际效力
每条规则自带的 pkts 和 bytes 字段是第一手证据，但需结合匹配条件解读：
- 对 -m conntrack --ctstate ESTABLISHED,RELATED 规则，高命中属正常；若其 pkts 占 INPUT 链总量 95% 以上，说明新连接极少，可能服务未暴露或前端代理异常
- DROP/REJECT 规则突增（如 1 分钟内从 0 跳至数百），尤其目标端口为 22、3306、8080，大概率是扫描或暴力尝试
- ACCEPT 规则长期 pkts=0，不是规则无效，而是流量被前面某条更宽泛的 DROP 截断，需按行号逆序排查
- 使用 iptables -nvxL --line-numbers 查看原始数字，避免 K/M 缩写干扰趋势判断
conntrack 表使用率决定新建连接成败
nf_conntrack 不是“可选模块”，而是所有带状态匹配（如 -m state）和 NAT 的底层依赖：
- 执行 cat /proc/sys/net/netfilter/nf_conntrack_count 与 cat /proc/sys/net/netfilter/nf_conntrack_max 对比，持续高于 90% 就会丢包或延迟，现象常被误判为“网络抖动”
- conntrack -L | grep UNREPLIED | head -20 可发现大量未完成三次握手的残留条目，常见于 SYN Flood 或客户端异常中断
- Docker/K8s 环境下，DOCKER-USER 或 KUBE-FIREWALL 链若未清理旧规则，会不断插入新条目却不释放，加剧表耗尽
内核态 CPU 消耗指向真实瓶颈层级
top 显示 CPU 高，但真正要盯的是 %sy（系统态）和 %soft（软中断）：
- mpstat -P ALL 1 中 %sy > 25% 且稳定，说明 netfilter 规则匹配、NAT 转换或 conntrack 查表正在吃资源
- 同时 %soft 也高，表明网卡收包后在协议栈被反复拦截、跳转，典型于 FORWARD 链过深或 LOG 规则滥用
- perf top -e 'net:*' -a 可直接看到 nf_iterate、ip_vs_invert_tuple 等函数占用率，确认是否卡在规则遍历或连接跟踪环节
链跳转深度与规则位置影响毫秒级延迟
iptables 不做索引优化，完全线性扫描，位置即性能：
- iptables -t filter -S FORWARD | grep -c '\-j' 返回值 >5，说明存在多层自定义链嵌套，每次 -j 都增加一次上下文切换开销
- INPUT 链规则数超 300 条时，最坏情况下单包匹配耗时可达毫秒级，对高频短连接（如 API 网关）影响显著
- 高频放行规则（如已建连接、内网白名单）必须置于链首；避免“先 DROP 再 ACCEPT”式反逻辑，那等于强制每个包走完全部规则
- 用 iptables -t filter -nL INPUT --line-numbers | wc -l 快速统计链长，超 100 条就应启动精简评估
