序列风控使用案例¶
本文提供可展开的配置思路，帮助您按业务路径编写序列规则。字段含义与逐步操作见 使用序列风控条件。案例默认收起，单击标题可展开。上线初期请将动作先设为 仅记录不拦截，确认命中符合预期后再改为拦截或人机验证。
电商大促与秒杀¶
大促秒杀：下单前必须按序浏览加购且停留足够
电商平台在 618、双 11 等大促期间开放秒杀。正常用户会先打开秒杀商品页查看价格与规格，再加入购物车，停留数秒后提交订单。抢购脚本常跳过浏览与加购，直接请求下单接口。要求提交秒杀订单前必须按「浏览商品 → 加入购物车」的顺序访问，且从打开商品页到提交至少间隔 3 秒。先定义合法路径并放行，其余秒杀下单一律拦截。
- 放行规则（排在前面）：当前操作等于 cccccccc，前序操作严格按序 aaaaaaaa → bbbbbbbb，距端点 aaaaaaaa 上次访问大于等于 3000 ms。动作：跳过后续规则。
- 兜底规则（排在后面）：当前操作等于 cccccccc。动作：拦截。
满足顺序与停留时间的秒杀下单由规则 1 放行；乱序、跳步或停留不足的请求由规则 2 拦截。完整步骤见 使用序列风控条件。
大促多入口：只需浏览过商品详情即可下单
大促会场同时存在搜索、类目、直播间、商品详情等多种入口，用户加购前路径不固定，中间还可能穿插浏览其他商品。只要曾经打开过目标商品详情页，即视为完成关键前置，允许提交订单；未浏览过详情的下单请求拦截。适用于入口多、路径不固定的会场业务。
- 放行规则（排在前面）：当前操作等于 cccccccc，前序操作任一出现过 aaaaaaaa。动作：跳过后续规则。
- 兜底规则（排在后面）：当前操作等于 cccccccc。动作：拦截。
「任一出现过」遍历前序序列，只要商品详情出现过即为真。也可一次勾选搜索、会场、直播间等多个合法前置端点（最多 10 个，彼此为「或」关系）。复杂会场可先用本条件确认前置存在，再用「严格按序」校验最后几步。
营销领券：拦截未进活动页就直打领券接口的脚本
店铺或平台在大促期间发放优惠券。正常用户会先进入领券活动页，阅读规则后再点击领取。刷券脚本通常不加载活动页，直接调用领券接口批量领取。对前序中从未出现过活动页访问的领券请求进行拦截或人机验证。
- 当前操作等于 eeeeeeee，前序操作均未出现过 dddddddd。动作：拦截或人机验证。
若领券入口包括首页弹窗、会场楼层、商品详情等多个合法页面，请先用「任一出现过」覆盖全部合法前置端点并放行，再使用本条件做兜底。
秒杀抢购：识别打开结算页后立刻提交的机器行为
秒杀结算页上，真人需要确认收货地址、优惠券与支付方式，通常需要数秒。脚本打开结算页后往往在极短时间内提交订单。要求从打开结算页到提交至少间隔 2 秒；从未打开结算页就提交的请求一并拦截。
- 过快处置：当前操作等于 ffffffff，距端点 eeeeeeee 上次访问小于 2000 ms。动作：拦截或人机验证。
- 从未打开结算页：当前操作等于 ffffffff，前序操作均未出现过 eeeeeeee。动作：拦截。
「距端点上次访问」在从未访问过该端点时为空，「小于」与「大于等于」均不命中。因此必须用规则 2 覆盖跳过结算页的情况。毫秒阈值请略大于业务最短间隔，以兼容节点时钟精度。
大促长路径：宽松确认进过会场，严格校验详情到下单
大促浏览路径较长：用户可能先逛主会场、搜索或直播，再进入商品详情并下单。只需确认曾经进入过会场，但对最后两步「商品详情 → 提交订单」要求紧邻，中间不能插入其他受保护端点。同一条规则内多个条件为「且」关系。
- 当前操作等于 cccccccc。
- 前序操作任一出现过 aaaaaaaa。
- 最近第 0 步前序等于 bbbbbbbb（最近一次前序必须是商品详情）。动作：跳过后续规则，其后对 cccccccc 再配置一条兜底拦截规则。
这样既允许会场浏览与下单之间穿插搜索、直播，又避免脚本在打开商品详情后插入其他端点再直打下单。
大促高峰：对异常下单先做人机验证，降低误伤
大促零点开抢时流量高、误伤成本高。对缺少合法前序的秒杀下单先做人机验证，而不是直接拦截，避免把网络抖动或路径略有差异的真人抢购一并挡住。验证通过后，后续下单仍须满足顺序与间隔，避免脚本通过一次验证后反复直打接口。
- 当前操作等于 cccccccc，且前序不满足合法路径时，动作选人机验证，可替代直接拦截，降低误伤。
- 人机验证针对当前请求。验证通过后，用户的后续请求会重新走规则链，请继续保留「严格按序」或「距端点上次访问」条件，避免脚本通过一次验证后反复直打秒杀接口。
- 人机验证会话有效期为 1 小时，超时需重新验证。动作说明见 配置 HTTP DDoS 自定义规则。
被拦截的请求不会写入序列。人机验证通过后的后续请求仍携带序列 Cookie，可继续用顺序与间隔条件约束。
金融支付¶
银行转账：必须按序查询账户与余额且间隔足够
网银或支付 App 中，正常用户转账前会先查看账户列表，再查询余额，停留数秒后发起转账。脚本常跳过查询，直接调用转账接口做参数遍历或越权尝试。要求发起转账前必须按「查询账户列表 → 查询余额」的顺序访问，且从查询账户列表到转账至少间隔 5 秒。先定义合法路径并放行，其余转账请求一律拦截。
- 放行规则（排在前面）：当前操作等于 cccccccc，前序操作严格按序 aaaaaaaa → bbbbbbbb，距端点 aaaaaaaa 上次访问大于等于 5000 ms。动作：跳过后续规则。
- 兜底规则（排在后面）：当前操作等于 cccccccc。动作：拦截。
满足顺序与间隔的转账由规则 1 放行；乱序、跳步或间隔不足的转账由规则 2 拦截。逐步操作见 使用序列风控条件 中的转账配置示例。
转账前只需查过余额：宽松前置
部分网银或 App 入口不固定：用户可能从首页、账户详情或收款人列表进入转账，中间还会穿插其他查询。只要曾经查询过余额，即视为完成关键前置，允许发起转账；从未查过余额的转账请求拦截。适用于路径不固定的移动端场景。
- 放行规则（排在前面）：当前操作等于 cccccccc，前序操作任一出现过 bbbbbbbb。动作：跳过后续规则。
- 兜底规则（排在后面）：当前操作等于 cccccccc。动作：拦截。
「任一出现过」不要求与转账紧邻。也可一次勾选账户列表、余额查询等多个合法前置端点（最多 10 个，彼此为「或」关系）。对 IP 易变化的移动网络，建议优先使用本类宽松条件。
账号与表单安全¶
敏感操作前必须先登录
修改密码、提现、解绑等敏感接口在业务上要求先完成登录。自动化脚本常跳过登录页，直接请求这些接口。对前序中从未出现过登录端点的敏感请求进行拦截或人机验证。
- 当前操作等于 hhhhhhhh，前序操作均未出现过 gggggggg。动作：拦截或人机验证。
若合法入口包括密码登录、短信登录、单点登录等多个端点，请先用「任一出现过」覆盖全部登录端点并放行，再使用本条件做兜底。
表单提交前强制停留
注册、资料填写等表单页上，真人需要阅读说明并填写字段，通常需要数秒。脚本打开表单页后往往立刻提交。要求从打开表单页到提交至少间隔 2 秒；从未打开表单页就提交的请求一并拦截。
- 过快处置：当前操作等于 jjjjjjjj，距端点 iiiiiiii 上次访问小于 2000 ms。动作：拦截或人机验证。
- 从未打开表单页：当前操作等于 jjjjjjjj，前序操作均未出现过 iiiiiiii。动作：拦截。
「距端点上次访问」在从未访问过该端点时为空，「小于」与「大于等于」均不命中。因此必须用规则 2 覆盖跳过表单页的情况。毫秒阈值请略大于业务最短间隔，以兼容节点时钟精度。