什么时候需要自定义规则
通用规则集覆盖的是公认的攻击特征，覆盖不了业务特有问题：某个导出接口被批量滥用、某类参数取值在正常业务里根本不会出现、某个访问序列只可能来自脚本。这类场景只能靠按业务特征编写的自定义规则来补。
一条好维护的规则写什么
自定义规则应该写清三件事：匹配条件、动作、生效范围，再加一条备注说明它为什么存在。临时规则要设有效期，规则本身要进版本管理与配置备份，否则半年后没人说得清它为什么还在生效、能不能删。
基本信息
| 适用场景 | 业务特有问题、临时风险、合规要求 |
|---|---|
| 规则要素 | 匹配条件 + 动作 + 生效范围 |
| 管理要求 | 命名规范、备注原因、定期复核 |
| 验证方式 | 先在观察模式验证误报，再切换拦截 |
典型使用场景
- 导出接口被批量拉取，需要频率与容量约束
- 业务参数出现明显异常取值（如超长、非法字符）
- 来源 IP 或用户代理特征稳定的异常访问
- 临时封堵某个正在被利用的接口路径
- 合规要求对特定接口做访问限制
- 新接口上线但通用规则覆盖不到其业务逻辑
规则结构示意
规则结构示意
条件：请求路径匹配 /export/* 且频率超过阈值
动作：告警并限速（不直接阻断，先观察）
范围：仅生产环境，仅该业务域名
备注：防止批量导出滥用，提出人 / 日期 / 复核时间要素与风险
| 要素 | 写不好时的风险 |
|---|---|
| 匹配条件 | 条件过宽会拦正常业务，过窄则形同虚设 |
| 动作 | 直接阻断上线，一次误报即业务中断 |
| 生效范围 | 范围写错会波及无关域名或环境 |
| 备注与期限 | 无人知道来由，规则长期无人清理 |
自定义规则纳入版本管理，与配置备份一起保留：规则也是一种配置资产，丢了重建成本很高。
规则条件写太宽会拦截正常业务，必须先在观察模式验证命中与误报，再决定是否开启阻断。
临时规则设有效期并由系统提醒复核：一条没人记得的规则，比没有规则更危险。