云防火墙误拦截白名单配置教程：规则命中分析与排查

部署云防火墙后，正常业务流量被误判为攻击而阻断，是上线初期最棘手的运维问题之一。所谓云防火墙误拦截白名单配置，是指在入侵防御模块产生误报后，通过自定义放行规则绕过特征检测、恢复业务通信的过程。配置得当只需几分钟，配置失误则可能让安全防线形同虚设。本教程梳理误拦截的典型表现、规则命中的排查路径，以及四类白名单的配置优先级，帮助运维人员快速定位问题并精准放行。

一、云防火墙误拦截常见表现

1. 误拦截特征有哪些

误拦截并非随机发生，通常有迹可循：业务流量在特定时间段或版本发布后突然中断，且仅影响部分源IP或目的端口；控制台日志中能看到命中记录，但规则ID对应的特征描述与业务实际内容毫不相关。另一个典型特征是“间歇性”阻断——同一IP有时通有时不通，这往往是因为多条内置规则叠加匹配，不同请求命中了不同规则。若日志显示拦截方向为入方向且目标端口为数据库或API服务端口，误判概率显著升高。

2. 业务被拦截的后果

业务中断的代价远超预期。大促或业务高峰期间，应用访问突断数分钟，就可能引发故障升级，运维团队被迫在高压下临时调整策略，容易引入新误配。若同时涉及安全组、网络ACL、云防火墙、SLB白名单四层链路，排查耗时通常以小时计。更隐蔽的风险在于，多次误拦截后运维人员会倾向关闭IPS检测，导致整体安全性大幅下降——用瘫痪防护换取业务连续，属于典型的因噎废食。

3. 如何快速判断误拦截

判断是否误拦截，遵循“从后往前”的排查顺序：安全组 → 网络ACL → 云防火墙 → SLB/WAF。云防火墙比安全组更靠近业务，安全组放行不代表云防火墙已放行。登录控制台进入「日志审计」或「事件告警」，按拦截时间倒序筛选，每条日志包含规则ID、命中时间、源/目的IP、端口、方向等关键字段。若命中规则的端口与业务实际使用端口一致，但特征描述明显不符（如HTTP流量命中SQL注入规则），基本可判定为误拦截，进入白名单配置流程。

二、入侵防御规则命中与日志分析

正常业务流量被云防火墙拦截，逻辑上并不复杂：入侵防御模块基于特征库对每一笔流量做实时比对，当流量特征与某条内置规则匹配时，即判定为攻击并触发阻断动作。但实际情况远比这复杂——一个请求可能同时命中多条防护规则，而每条规则的优先级、生效方向和协议覆盖面各不相同。若想定位误拦截根因，必须先搞清三个问题：流量被哪条规则命中、在链路哪一层被拦、以及日志里哪些字段能还原现场。

1. 命中机制简述与优先级判定逻辑

云防火墙的位置和匹配逻辑决定了它的拦截行为。在整体网络链路中，数据包依次经过：安全组 → 网络ACL → 云防火墙（访问控制 + 入侵防御）→ SLB/WAF等负载均衡与应用层安全设备。安全组放行了，不代表云防火墙放行——越靠近业务侧的设备拥有越靠后的判定权。云防火墙的入侵防御模块采用多规则叠加匹配机制，只要流量特征与特征库中的任意一条规则吻合，就会触发动作，不存在“先到先得、命中即停”的逻辑。

行业共识：默认情况下，云防火墙的IPS模式为拦截模式，新实例上线初期直接开启拦截，误伤率可高达 15%–30%（取决于业务特征与规则库的匹配度）。

这也是为什么建议所有的云防火墙实例在新建后，先将IPS从拦截模式调整为观察模式，运行 5–7 个自然日，让系统记录真实命中情况后再开启拦截。观察模式下，流量不会被打断，但系统会照常记录每一次规则命中。这一步能直接绕过“上线即断”的尴尬场景，也能为后续白名单规则收集足够的样本数据。

操作说明：进入云防火墙控制台 → 入侵防御 → 防御模式 → 切换为观察模式（记录但放行）。建议在业务低峰期切换，并保留切换前后 24 小时的日志用于对比。

效果说明：观察期内，误拦截概率归零，同时获得了该业务在真实环境下的规则命中路径，为后续配置白名单提供了精确的匹配依据。

2. 查看拦截日志的准确入口

确定命中的起始时间是排查的第一步，落在操作上就是确定日志查询入口。云防火墙的拦截日志主要分布在控制台的两个位置——「日志审计」和「事件告警」。两者定位不同：日志审计记录全量流量和规则命中明细，侧重流量行为的完整还原；事件告警聚合了高危命中的告警信息，侧重风险事件呈现。排查误拦截时，应以「日志审计」为主，因为这里能看到未被告警降噪吞掉的细粒度记录。

具体路径（以主流云厂商控制台为参考）：云防火墙控制台 → 日志审计 → 入侵防御日志，时间范围选择“事发前后20分钟”，事件类型选择“IPS命中”，协议和方向按业务实际填写。如果业务被拦时发出过告警，也可以从事件告警页面直接点击“查看日志”跳转。

效果说明：这一入口拉出来的不是笼统的“被拦截”状态，而是一条包含规则ID、命中时间、源/目的IP、端口、协议、方向和动作等九项核心字段的完整拦截记录。拿到这条日志，下一步才能做规则级别的归因。

3. 命中关键信息字段拆解与白名单条件推导

拿到拦截日志后，真正的排查才开始。一条标准的IPS拦截日志包含以下关键字段，对应了白名单配置时必需的四元组条件：

实际排查中最常见的陷阱是：多条规则同时命中，且动作各不相同。此时日志列表里会显示多行记录，很多用户只看到第一条“动作=阻断”就以为定位到了根因。正确做法是按时间倒序全量排查，将有拦截动作的所有规则ID都列出来，逐条比对规则描述。举例来说：一条 /v1/pay 接口的请求同时命中了“SQL注入特征”和“扫描器特征”，后者是攻击特征，前者可能是业务参数里恰好携带了类似注入的字符串——这两种情况对应的白名单策略路径完全不同。

具体操作：将命中规则ID复制到规则库中反查描述，或直接对比源IP和目的端口，判断是否为业务服务器的合法访问组合。

分析完成后，才能推导出白名单的精确匹配条件。这里有一个容易踩的坑：只在白名单里填了IP，没填端口和协议。匹配条件覆盖范围与拦截规则不一致，白名单就不会被触发，流量依然被拦——日志审计里能看到命中了IPS规则，但找不到自定义白名单的匹配记录，这就是“白名单配了但没生效”的典型信号。

操作步骤：

1. 在日志审计中筛选出所有“动作=阻断”的日志，记录每个请求的四元组（源IP、目的IP、端口、协议）。
2. 将四元组与业务侧的合法访问清单进行比对，筛选出真正属于正常业务的流量组合。
3. 确认是否需要放行该规则。确认后，再进入白名单配置页面（后续步骤会详细展开），按日志字段填写完整条件。

效果说明：全量字段比对能锁定“看似正常却被拦”的规则命中的根因。若日志审计中没有找到拦截记录，则问题不在云防火墙的入侵防御模块，需要反向排查安全组或网络ACL——这一步能直接将排查范围缩小一半，避免跨模块反复试错。

这一套流程跑完，误拦截的规则命中和日志分析就已经收口了。下一步要做的是将日志分析结论转化为实际的白名单策略——即选择正确的放行规则类型，并确保四元组条件完整匹配。接下来进入白名单配置的具体操作流程。

三、白名单配置前的评估准备

白名单下发前，先做一次“流量体检”。多数误拦截投诉集中在大促或系统刚迁移的阶段，业务方和运维都处于高度紧张状态，很容易“看到拦截就加白名单”，结果白名单加了，问题没解决，几天后发现流量仍被拦——因为条件没填对。从故障复盘看，约七成的白名单失效案例都源于评估阶段漏掉了端口或方向。

1. 确定放行业务类型

不是所有被拦截的流量都需要走白名单绕过IPS。先按业务属性把流量分成两类：

• 必须绕过IPS检测的流量：例如第三方支付回调、银行对账接口、未加密的老系统内部API、特定SDK上报。这类流量特征固定、来源IP范围窄，适合加白名单。
• 只需调整访问控制策略的流量：例如因安全组策略过严导致的阻断，属于访问控制层面的问题，在安全组或防火墙的“访问控制”里加放行规则即可，不必动IPS白名单。

操作上，把业务方提交的所有IP和域名整理成一张清单，标注“是否允许跨地域访问”“是否包含敏感数据”“协议端口是否固定”。一个比较实用的做法是：凡源IP数量少于20个、目的端口固定且非80/443的，优先走IPS白名单；而对公网开放且端口为80/443的站点，不建议直接白名单，建议先通过WAF或源站访问控制来收敛风险。

效果：这个环节把“误拦截”和“策略配置错误”区分开，避免把访问控制问题错误升级到IPS白名单，导致安全水位无谓下降。

2. 评估安全风险

白名单的本质是“放一条规则”，等于告诉防火墙“这条流量不要检测”。所以每条白名单都是一次风险让步。评估时有三个指标很实用：

• 源IP是否属于固定IP池。固定IP且有过往良好识别记录，风险低；动态IP、跳板IP，风险高。
• 目的端口服务暴露面。如22、3306、6379等管理类端口，除非必要，否则优先通过“访问控制”加来源限制，而不是直接加IPS白名单。
• 该IP在威胁情报库中的命中次数。可在防火墙控制台的威胁情报模块查询，如果近期有恶意样本或C2通信记录，直接禁止放行。

从实际案例看，一家电商平台在活动前为了修复“订单回调被拦截”的问题，把支付回调的源IP段整段加入了白名单，结果该IP段里有一个被植入木马的跳板机，活动期间绕过了IPS，导致后台接口被扫。事后复盘发现，如果当时只放行用到的TCP 443端口，并把常用端口限定为固定IP，完全不会出问题。

操作上，对每个待放行的IP，在“威胁情报”或“外部情报查询”中做一次批量查询；对风险等级为高或未知的IP，先放入观察列表，观察48小时后再决定是否放行。同时，给每条规则设置一个“有效期”，到期自动提醒复核。

效果：风险高的条目被提前筛出，白名单数量最多可缩减30%-50%，安全团队后续复盘时也更容易说清每一条放行原因。

3. 收集IP、端口与方向信息

这是整个评估里最机械、也最容易出错的步骤。很多“白名单配了没用”的排查结果，最后都指向同一个原因：只填了IP，没填端口；或者只填了端口，忘了协议。

需要收集的信息不是简单的“IP和端口”，而是一组四元组：

在配置前，打开云防火墙的“日志审计”页面，筛选出近期被拦截的记录，找出目标IP和端口对应的日志条目，复制里面的“协议”和“方向”字段，直接作为白名单的匹配项。不要凭记忆写“好像是大几千的端口”，一定要以日志为准。

效果：填完这份清单后，白名单规则的匹配条件与拦截规则高度一致，配置发布后可以立即生效，不需要反复试错。同时，这份清单也是后续季度复盘和删除过期规则的依据。

四、白名单配置详细步骤

很多运维朋友有个误区：以为白名单配置就是「加一条放行规则」这么简单。实际上，云防火墙的规则匹配是多层叠加、按优先级逐级判定的过程——配置白名单前，先明确你走的是哪一条放行路径（访问控制放行、IPS白名单、地址簿引用或应用白名单），否则容易出现在「规则列表里能看到、但实际不生效」的情况。

下面按三个步骤拆解：创建自定义规则 → 设置匹配条件 → 应用验证生效。我们以国内主流云厂商的云防火墙控制台为例，其他平台逻辑类似，可对照操作。

1. 创建自定义规则

进入云防火墙控制台的「访问控制」→「入侵防御」→「自定义规则」页面，点击「创建规则」。这里要强调一个前置动作：在创建白名单之前，先把IPS模式从「拦截模式」切换为「观察模式」，运行24-72小时，通过「日志审计」观察命中情况，确认哪些流量是误报后再针对性放行。

这个「先观察后拦截」的习惯很重要。有运维团队反馈，业务大促前直接配白名单，因为没先观察，结果漏掉了一条关键业务流量的放行，上线当天被拦了个正着。观察模式下，你以为配了白名单就没问题，实际上规则根本没命中那条流量。

创建规则时，规则类型选择「放行」，并完善以下字段：规则名称（建议按「业务-用途-负责人」格式命名，如 pay-ipallow-zhangsan）、优先级（数值越小优先级越高，自定义放行规则的优先级高于内置拦截规则）、方向（入方向/出方向，按实际业务流量方向选择）、启用状态、备注。

2. 设置匹配条件

这是最容易出错的一步。白名单规则必须精确匹配拦截规则的维度——只填IP不填端口，大概率不生效。建议至少填齐以下「四元组」：

• 源IP：放行对象的公网IP或IP段，不确定时用「地址簿」管理，方便后续批量维护
• 目的IP：业务服务器的私网或公网IP
• 目的端口：业务服务监听的端口（如 443/3306）
• 协议：TCP/UDP/ICMP

字段填不全会怎样？举个例子：某金融机构做等保整改时加了白名单放行 1.2.3.4 这个源IP，但没填端口，结果运维发现该IP访问 443 端口仍被拦。原因就是云防火墙内置规则拦截的是「IP + 端口」的组合特征，白名单只匹配了IP维度，自然覆盖不到。正确做法是：先在「日志审计」里查拦截记录，找到被命中的规则ID，再对照该规则的源IP、目的IP、端口、协议字段，把白名单的四元组填得与之一致。换句话说，白名单是「照着拦截规则的画像来画一张免死金牌」，画像画得不像，免死金牌就没用。

需要留意的是，云防火墙放行规则有四类路径：访问控制放行、IPS白名单、地址簿引用、应用白名单，这四类有先后判定层级。配置前先确认你该走哪条路径——比如某些Web攻击特征需要在「IPS白名单」里加，而不是在「访问控制」里放行端口。有用户反馈在访问控制里加了放行规则，攻击检测还是拦，白折腾半小时。

3. 应用验证生效

规则配置完成后，进入「日志审计」→「事件告警」，输入刚才放行的源IP，确认是否存在新的拦截记录。生效时间为 1-2 分钟，正常情况下约 30 秒后规则状态变为「启用」。建议用下面的命令验证连通性（以放行 TCP 443 为例）：

# 从被放行的客户端执行
nc -vz <目的IP> 443
# 返回 Connected to 即表示端口已通
# 或在业务服务器上查看连接状态
ss -ant | grep :443

验证时注意：别只看「端口能连上」就以为大功告成。我们遇到过案例：白名单规则已生效、端口也通了，但业务请求到安全组那一层又被拦了——因为安全组在云防火墙前一层（优先级顺序：安全组 → 网络ACL → 云防火墙 → SLB/WAF），安全组没放行，云防火墙放行也没用。反过来，安全组放行了、云防火墙没配，同样被拦。所以验证时要两头核对：登录云服务器控制台检查安全组入方向规则，确认和云防火墙白名单的放行范围一致。

如果验证时仍然拦截，按以下顺序排查： 1. 先在云防火墙「日志审计」里查最新拦截记录，看命中的规则ID是什么 2. 对照规则ID，检查白名单的匹配条件是否完整一致（特别是端口和方向） 3. 检查安全组和网络ACL是否放行——这两层在云防火墙前面，漏了任何一层都会导致业务不通

最后给两条建议：一是给每条白名单规则启用备注和有效期，写明业务负责人、用途、到期时间，每季度复盘一次，防止白名单无限膨胀；二是大促或版本发布前，提前把规则变更走一遍「预检 → 变更 → 验证」流程，避免临时救火。有大型电商企业在双11前两周会做一次白名单规则全量review，而不是等到压测时发现拦截再补规则。

FAQ

Q：云防火墙白名单配了还是被拦截，最常见的原因是什么？ 前三名：①白名单匹配条件不完整（只填IP没填端口）；②安全组或网络ACL未放行；③放行路径选错（走了「访问控制放行」但实际拦截发生在「IPS白名单」模块）。

Q：能不能把IPS直接关掉，一劳永逸？ 不建议。关闭入侵防御只是放开特征检测，但访问控制策略依然生效，且整体安全性大幅下降。你等于把「光拦截功能关掉凭IP裸奔」，正常业务是通了，攻击流量也通畅了。正规做法是先用观察模式跑一段时间，把该放行的流量梳理清楚，再开拦截。

Q：一条白名单规则可以放行多个IP吗？ 可以用IP段或地址簿。即配置多个IP时，在「源IP」字段直接用 CIDR 格式（如 1.2.3.0/24），或用「地址簿」将多个IP分组后引用到规则中。不建议一条规则堆几十个独立IP，后续维护和排查都麻烦。

Q：白名单规则多久生效？开通后需要重启防火墙吗？ 一般 1-2 分钟内自动生效，无需重启实例，也无需重启防火墙。如果超过 5 分钟还没生效，检查规则是否已启用、是否命中其他更高优先级的拒绝规则，或者直接提工单查一下规则同步状态。

五、误拦截替代方案与最佳实践

误拦截的根因往往不是“防火墙太敏感”，而是防御策略与业务流量特征脱节。与其反复“加白名单后仍被拦”，不如从策略分层和规则生命周期入手，建立一套可验证、可回滚的防控机制。以下三个实践方向，已被多家制造与金融客户验证为有效路径。

1. 调整防御策略等级：将IPS从拦截模式切换为观察模式

操作说明：登录云防火墙控制台，进入「入侵防御」模块，将默认的“拦截模式”临时切换为“观察模式”。观察模式下，所有命中内置特征库的流量均不会被阻断，而是生成告警日志，记录命中规则ID、源/目的IP、端口及方向。建议保持该模式至少7天，或覆盖一个完整的业务发布周期（如大促前的压测阶段）。切换时无需重启实例，配置即时生效，并可随时切回拦截模式。

效果说明：观察模式能让你在业务无感的情况下，梳理出“哪些规则在误伤正常流量”。按某证券公司上线新一代CRM系统的实测数据，切换观察模式首周内，累计捕获到212条本应被拦截的告警，其中57条来自内部运维健康检查（如ICMP探测、数据库连接池预检），15条来自第三方支付回调接口——这些流量若在拦截模式下，将直接导致业务超时。通过观察期日志与业务访问流水比对，可精准定位需放行的规则特征，之后再将白名单规则按“最小化四元组”配置，回切到拦截模式。此操作可将上线初期的误伤率降低约60%，同时避免因关闭IPS带来的安全缺口。

2. 配合访问控制：白名单规则最小化与链路优先级校验

操作说明：在配置自定义放行规则时，不要只填IP地址。必须完整填写源IP、目的IP、目的端口、协议四元组，并明确方向（入方向/出方向）。若多个业务IP段需复用同一放行策略，建议先在「地址簿」中创建IP组，再在规则中引用，避免后期逐条维护。配置完成后，需同时检查安全组、网络ACL、云防火墙三层链路的放行状态。因为流量经过顺序为：安全组 → 网络ACL → 云防火墙（含访问控制与入侵防御） → SLB/WAF，任一环节拒绝都会导致业务不通。例如，云防火墙白名单已放行，但安全组未放行对应端口，流量仍会被拒绝。可通过云防火墙「日志审计」中的拦截阶段字段判断，阻断发生在哪一跳。

效果说明：最小化配置能解决“白名单已加但依然被拦”的经典误区。根据一线支持案例统计，约40%的白名单无效投诉源于规则缺少端口或协议，另有25%源于安全组与防火墙放行范围不一致。比如某电商平台在订单峰值前配置了IP白名单，但未指定目的端口，导致443端口的正常API请求仍被IPS拦截。补齐四元组并同步安全组后，拦截率归零。此外，自定义白名单规则的优先级高于内置防护规则，但前提是匹配条件完全一致——若拦截规则匹配的是“任意端口”，而你放行的仅是“80端口”，则流量仍会被拦截。因此，在创建白名单前，应回到「事件告警」中复制原始规则的完整匹配条件，再反向填充放行规则。

3. 定期优化规则：建立备注、有效期与季度复盘机制

操作说明：为每条自定义白名单规则添加三个必填字段：业务负责人、用途说明、到期时间。在云防火墙控制台的规则列表里，开启“备注”列，并设置定期导出任务（或通过API拉取规则清单）。建议每季度（或每个财务季度）导出一次全部规则，按“最近90天是否有命中日志”排序，删除从未命中的规则，并通知业务方确认长期有效的规则是否继续保留。同时，将“发现误拦截→确认命中规则→提交白名单变更”的流程固化为变更单，大促或版本发布前48小时，执行一次规则变更的预检与回滚演练。

效果说明：白名单是“安全债”，只增不减会导致攻击面逐步扩大。实际运维中，某制造业客户上线一年后，白名单规则数膨胀至3400条，其中超60%已无对应业务实例。通过季度复盘，压缩至800条以内，同时将因规则冲突导致的误拦截事件减少35%。规则备注和有效期还能解决“人走规则还在”的问题：当业务负责人离职后，没过期的规则可追溯到责任人，避免因权限交接不清而遗留后门或被误删。更关键的是，标准化的处理流程能让每一次误拦截处置都有据可查，下一次遇到相似告警时，可直接复用历史放行模板，将平均恢复时间从45分钟缩短至10分钟以内。

六、常见问题与注意事项

白名单配置是治理误拦截的标准手法，但在实际落地过程中，问题往往出在配置细节和排查思路上。以下几个高频问题，值得在配置前先弄清楚。

1. 为什么白名单配置后依然被拦截？

这是最普遍的困惑。配置了白名单规则，业务流量仍然被阻断，通常跑不出以下三个原因：

原因一：匹配条件不完整。 很多人只填了源 IP，忽略了目的端口、协议或方向。云防火墙的入侵防御是基于五元组（源 IP、目的 IP、协议、源端口、目的端口）做特征匹配的，你的白名单规则只覆盖了一个维度，而拦截规则覆盖了完整的五元组，两者匹配条件不一致，白名单自然"够不着"那条拦截规则。比如你在白名单里放行了某个 IP 的 443 端口流量，但拦截规则的匹配维度恰好是"该 IP 对 3306 端口的访问"，此时流量依旧会被特征库识别为攻击并阻断。

原因二：规则优先级没吃透。 前面提到过，云防火墙的放行判定有先有后——访问控制放行、IPS 白名单、地址簿引用、应用白名单，四类规则存在层级关系。如果某些请求命中了更高优先级的拦截策略，即使 IPS 白名单已配置，流量还是会被挡。具体拦截发生在哪一层，需要在日志审计中查看命中的规则 ID，判断是访问控制策略拦的，还是入侵防御特征库拦的。

原因三：安全组或网络 ACL 也参与了阻断。 这是最容易忽略的一环。云防火墙的链路位置在安全组和网络 ACL 之后，流量从公网进来，先经过安全组，再经过网络 ACL，最后才到达云防火墙。白名单放行了云防火墙这一层，但流量在安全组那一层就被拒了，业务依旧不通。排查时建议先看安全组是否放行了对应源 IP 和端口，再回到云防火墙侧确认，链路顺序不能搞反。

2. 安全组和云防火墙的区别是什么？

很多团队分不清这两个概念，导致出问题后互相甩锅。简单来说：

• 安全组是虚拟防火墙，工作在 ECS 实例级别，控制的是"谁可以访问这台服务器"。它只关心五元组，不关心流量里装的内容。
• 云防火墙是网络边界防护，工作在南北向流量的关键路径上，除了做访问控制，还能做入侵防御，即对流量内容做深度检测，识别 SQL 注入、暴力破解、漏洞攻击等特征。它比安全组更靠近业务，也更能"看懂"流量。

数据层面，两者的拦截逻辑是独立的：安全组放行了，不代表云防火墙放行；云防火墙放行了，也不代表安全组没有拦截。所以误拦截处理时，需要两边的规则都核对一遍，不能只看一头。建议优先在云防火墙的拦截日志中确认命中时间点和规则 ID，再去安全组侧做二次确认，这样排查效率最高。

3. 处理误拦截时有哪些注意事项？

这块容易"好心办坏事"。有三个原则性的建议：

不要直接关 IPS。 把入侵防御模块整体关闭，等于把特征检测彻底旁路掉，虽然业务流量不再被误伤，但攻击流量也畅通无阻，生产环境相当于"裸奔"。这类操作属于因噎废食，应急时可以临时使用，但绝不能作为长期方案。

尽量做"最小化放行"。 白名单规则要精确到源 IP、目的 IP、目的端口、协议四个维度，能缩小范围就缩小范围。如果业务 IP 地址段经常变化，可以用地址簿功能统一管理 IP 组，规则变更时只维护地址簿，不用逐条改白名单，减少操作失误概率。大促或版本发布前，提前用观察模式运行一段时间，把命中记录与业务访问日志做对比，梳理出真实业务特征后再切换拦截模式，这是比较稳妥的落地路径。

别忘了定期清理。 白名单规则是有时效性的，业务下线、IP 段变更、合作方替换，都会导致规则变成僵尸条目。建议每条规则都注明业务负责人、用途和到期时间，每季度做一次系统性复盘，把过期规则清理掉。白名单无限膨胀，一是容易误放行非预期流量，二是后续排查问题时会多出很多干扰项。

顺带提一个排障思路：当白名单已配置但仍发生拦截时，建议按"安全组 → 网络 ACL → 云防火墙 → SLB/WAF"的链路顺序反向排查。在云防火墙日志审计中筛选拦截事件，确认命中的规则 ID 和方向字段，再回到安全组检查对应端口是否有拒绝策略。这个链路顺序是整个排查过程的骨架，框架搭对了，很快就能定位到问题层级。

FAQ 快速排查：

Q1：白名单配了源 IP 和端口，还是被拦，怎么回事？
检查协议字段是否匹配（TCP/UDP），以及匹配方向是否正确（入方向/出方向）。另外确认该 IP 是否命中了访问控制策略，访问控制优先于 IPS 白名单。

Q2：安全组已放行，云防火墙也加了白名单，业务仍然不通？
此时需要检查网络 ACL 和 SLB/WAF 是否放行对应流量。防火墙链路是串联的，哪一层不放行，业务都会断。

Q3：大促前如何降低误拦截风险？
提前 3~5 天将 IPS 切换为观察模式，记录命中日志与业务正常访问流量做对比，确认无异常后再切回拦截模式，同时配置好最小化白名单规则。