新手看iptables统计数据，重点是发现“不该有却很多”和“该有却为零”的异常：pkts和bytes突增或长期为0，chain默认策略兜底丢包量上升，drop规则短时飙升、accept规则零命中、icmp的bytes/pkts比值异常偏高，均提示潜在攻击或配置错误；结合log规则与日志可快速定位源头，需注意计数器可被iptables -z清零，且云环境内网ip（如10.0.0.0/8）的drop多为健康检查流量，不可盲目封锁。

新手看iptables统计数据，重点不是记数字，而是盯住“不该有却很多”和“该有却为零”的地方。它不直接报错，但包计数、丢弃量、规则命中顺序这些细节，会悄悄暴露异常。

看懂iptables -L -v 输出里的关键字段

执行 iptables -L -v 时，每条规则前两列是核心：

• Pkts：这条规则匹配并处理过的数据包总数。突然飙升或长期归零都值得查
• Bytes：对应的数据流量字节数。和Pkts一起看，能判断是高频小包（如扫描）还是大流量传输（如下载或攻击）
• 注意 Chain DEFAULT POLICY 后面的计数——那是默认策略（比如 DROP）兜底拦截的包数。如果这个值持续增长，说明大量流量没被前面任何规则明确放行或拒绝，属于配置疏漏

识别三类典型异常信号

不用等服务挂了才察觉，日常扫一眼就能发现苗头：

• 某条DROP规则的Pkts在1分钟内猛增数百上千：可能是端口扫描、暴力破解（如SSH、MySQL）或CC攻击前兆。尤其关注目标端口是22、23、3306、8080这类常见服务端口的规则
• 本该放行的业务规则（如ACCEPT）Pkts长期为0：比如你写了-A INPUT -p tcp --dport 80 -j ACCEPT，但Pkts一直是0，说明要么没流量进来，要么流量根本没走到这儿——大概率是前面某条规则（比如一条过于宽泛的DROP）把它截断了
• ICMP相关规则（尤其是DROP ICMP）Bytes远高于Pkts：每个ICMP包很小，如果Bytes/Pkts比值异常高（比如超1500），可能有人在发巨帧ICMP Flood，或是网络设备误配导致回环

结合日志快速定位问题源头

光看计数不够，得知道是谁干的。给关键规则加日志再观察：

• 临时给可疑DROP规则加记录：iptables -I INPUT 1 -s 192.168.1.100 -j LOG --log-prefix "BLOCKED-SCAN: "
• 然后实时查看：tail -f /var/log/messages | grep BLOCKED-SCAN
• 日志里会显示源IP、目的端口、协议、TTL等。连续出现同一IP扫多个端口，基本可判定为扫描行为；如果是云环境内部IP（如10.x.x.x、172.16.x.x），要立刻检查是否被横向渗透

避免误判的两个实操提醒

新手容易把正常现象当异常，这两点务必留意：

• 计数清零不是重启服务器才重置——执行iptables -Z就会清空所有计数。所以对比前后变化，最好先iptables -Z打个基准，再等几分钟再看增长
• 云服务器上看到大量来自100.64.0.0/10或10.0.0.0/8的DROP记录，别急着删规则。这很可能是云厂商健康检查、VPC路由或SLB转发流量，盲目封掉会导致服务中断（参考2024年那起因封10.0.0.0/8导致负载均衡失效的事故）