看看是不是通过其他策略匹配的

防火墙安全策略 595、596 日志异常问题解答

现象：

• rule‑id 595：地址段，日志完整，443、ICMP 均有日志
• rule‑id 596：单台明细主机 IP（被 595 地址段包含），只看到 ICMP 日志，TCP 443 等端口没有日志；外部设备确认该主机确实存在 443 等业务访问流量。

核心原理：V7 防火墙安全策略是按 rule‑id 从小到大顺序匹配，匹配即停止；会话首包命中哪条策略，这条会话就归属该策略，后续报文不再重新匹配策略。

根因分析

规则编号：595 ＜ 596

1. TCP 业务访问（443）首包过来，先匹配到编号更小的595（大地址段），直接命中 595，建立会话，流量全部归属 595 策略，不会走到 596，所以 596 看不到 TCP 端口日志，全部记在 595 下面。
2. ICMP 大部分是独立报文，每一次 ping 都相当于独立首包。部分 ICMP 报文刚好匹配到 596，所以 596 能看到少量 ICMP 日志；ping 报文有的也会命中 595，两条策略都会出现 ICMP 日志。

这就是现象：596 只有零星 ICMP 日志，TCP 业务流量全部被前面 595 拦截匹配走了，根本没有触发 596 规则。

⚠️注意：防火墙安全策略不是深度优先，是按 rule‑id 编号从小到大依次匹配，匹配就终止，和 ACL auto 模式不一样，不会自动优先匹配更精细的主机条目H3C。

验证手段（命令行确认命中哪条策略）

1. 看会话表，确认业务会话归属哪条策略：

输出中Policy: rule‑595，证明 TCP 业务全部命中 595，没有走到 596。 2. 看策略命中统计计数：

观察：595 的 TCP 计数持续上涨，596 的 TCP 计数几乎为 0，ICMP 有少量计数。

修复方案（二选一，推荐方案 1）

方案 1：调整规则顺序，细粒度主机策略放前面（最优）

把明细主机 596 移动到 595 前面，让单主机规则优先匹配。

移动完成后，该主机所有流量优先匹配 596；网段内其他 IP 继续匹配 595。

移动规则后，需要清空旧的老化会话，旧存量会话仍然会沿用老策略：

清空该主机的旧会话，新的访问会话才会命中 596，产生对应日志。

方案 2：保留现有顺序，595 排除该主机 IP（不推荐，配置繁琐）

在 595 的源地址对象里面把这个主机做排除，网段剔除该 IP，这样主机流量才会往下匹配到 596。

其他排查点（排除次要因素）

1. 两条策略都已经开启logging enable，确认全局信息中心允许输出安全策略日志；
2. 确认硬盘正常，日志没有因为磁盘满丢失；
3. 防火墙本地时间准确，查询日志时时间筛选范围正确，避免日志存在但是查询条件过滤看不到。

简短总结

1. V7 安全策略按 rule‑id 从小到大匹配，匹配即停止，不会自动优先匹配精细主机；595 编号更小，TCP 业务首包直接命中 595，不会走到 596，所以 596 看不到 TCP 端口日志；ICMP 报文有部分命中 596，所以能看到 ICMP 日志。
2. 处理：move rule 596 before 595，将细粒度主机策略移动到网段策略前面；再 reset 该主机旧会话，新流量就会在 596 产生完整日志。
3. 验证：display session table verbose看会话归属哪条策略，display security‑policy statistics看策略命中计数。

你遇到的这个现象，根本原因在于H3C V7防火墙安全策略的匹配顺序：策略规则按 rule-id 从小到大依次匹配，一旦某条报文命中某条规则，匹配即停止，后续所有同类流量都会沿用这条策略。你的策略 595 的编号更小，所以它抢在 596 前面，把绝大部分业务流量“截走”了。

 为什么 596 只有 ICMP 日志？

TCP 443 等业务流量全部被 595 拦截匹配。
当内网主机发起 TCP 443 连接时，首包到达防火墙，系统从 rule-id 最小的策略开始扫描。由于 595 < 596，首包直接命中 595（地址段策略），成功建立会话。会话一旦建立，后续所有该连接的报文都不会再重新匹配策略，因此全程都归属于 595，596 根本没有机会被触发。

ICMP 之所以有零星记录，是因为它比较特殊。
ICMP 报文大多是无连接的独立报文，每一次 ping 都相当于一个全新的“首包”。在这些首包中，部分恰好命中了 596（可能因为策略匹配时的某些瞬时条件），所以 596 上能看到少量 ICMP 日志；而另一部分 ICMP 首包仍然被 595 抢走，所以两条策略都可能出现 ICMP 记录。

简单说：596 并非“不记录日志”，而是它的 TCP 业务流量根本没有走到它面前。

 验证方法

在命令行下执行以下操作，确认实际命中情况：

查看该主机的会话归属哪条策略：

在输出中找到 Policy 字段。如果显示 rule-595，就证实 TCP 业务全部被 595 匹配了。

查看两条策略的命中计数对比：

如果 595 的 TCP 计数持续上涨，而 596 的 TCP 计数几乎为 0（只有少量 ICMP），即可确认问题。

 修复方案（推荐方案 1）

将明细主机策略 596 调整到地址段策略 595 之前，让更精确的规则优先匹配：

关键补充：必须清除旧会话。
调整顺序后，已经建立的旧会话仍然会沿用原来的 595 策略，新配置不会对存量会话生效。因此需要手动清除该主机的旧会话：

清除后，该主机的新访问才会重新匹配策略，此时会优先命中 596，完整的 TCP 443 等日志就会在 596 下产生。

调整后，网段内其他 IP 的流量仍然会正常匹配 595，不受影响。规则顺序变为“先精确、后模糊”，这是符合防火墙最佳实践的配置方式。