低频CC攻击的工程难处不在于“拦不住”，而在于没有可拦的明显特征。攻击者控制每个源IP的请求速率，使其低于任何基于频率的阈值，再通过海量代理池和秒拨IP把整体并发拉到足以耗尽资源的水位。金融API场景下，单IP每秒1—3次请求完全落在正常用户区间，但数万个IP同时遍历账户查询接口，数据库I/O和连接池会在几分钟内见底。游戏登录服同理：集中打登录接口的CC流量，单看每个IP都像正常玩家，合起来却是资源耗尽型打击。
秒拨IP的底层机制决定了这条攻击路径很难用地址维度封堵。它利用家用宽带PPPoE断线重连更换IP的原理，掌握大量宽带线路资源的黑产可以在短时间内轮换出规模巨大的源地址池，少则十万、多则百万，传统按IP频率限速在地址层就失去了锚点。对抗的逻辑必须从“数请求次数”转向“判断发出请求的东西是什么”：TLS指纹、设备环境、行为节奏、业务基线偏离度，才是低频CC下仍然稳定的判定依据。
低频CC与秒拨IP叠加之后，频率阈值为什么从根上失效
传统CC防护的第一层通常是频率控制：单IP每分钟超过N次即触发限速或封禁。这套逻辑对早期集中式CC有效，但在秒拨IP面前有三个无法修补的漏洞。
第一，单IP频率被刻意压在阈值之下。攻击者不需要让任何一个IP“看起来像攻击”，只需要让每个IP看起来像低频正常用户。金融API的CC攻击典型形态就是每IP每秒1—3个请求，刚好低于大多数频率规则的触发线，而分布式并发总量可以达到数十万QPS。
第二，地址池轮换速度超过封禁生效速度。秒拨IP池的规模意味着一个IP在被封禁之前可能只发了几个请求就已经轮换掉了，封禁列表不断膨胀但对攻击整体速率的压制有限。按IP封禁在这种资源结构下更像是在追一个不断换壳的目标。
第三，业务峰值与攻击流量在频率维度上无法区分。金融交易时段、游戏开服瞬间、电商秒杀窗口，正常用户的请求频率本身就会大幅上升。静态阈值调低则峰值期误杀真实用户，调高则低频攻击直接穿过。把频率阈值作为主防线，在低频CC场景下等于把判定权交给了一个必然失效的指标。
频率层仍然需要保留，但它的定位应当降级为粗筛：拦住那些连伪装都懒得做的低水平攻击，把干净流量和可疑流量分开，真正的判定交给后面的行为与设备维度。
TLS指纹：在不解密流量的前提下把自动化工具从客户端层剥出来
低频CC的请求在HTTP层面可以伪装得和真实用户几乎一致：Header完整、Cookie正常、路径合法。但请求在到达HTTP之前，必须先完成TLS握手。握手阶段的ClientHello暴露了客户端使用的TLS库、密码套件顺序、扩展列表、椭圆曲线参数和压缩方法，这些特征组合成一个指纹，真实浏览器和移动App高度稳定且集中在有限范围内，自动化脚本、bot框架和代理池工具往往使用统一的TLS库，指纹与正常客户端存在结构性差异。
这个判定维度的工程价值在于不依赖解密。金融业务普遍使用HTTPS，传统清洗设备要识别攻击特征就必须解密，而解密引入的延迟和计算开销在交易场景下很难接受。TLS指纹在握手阶段完成提取，附加延迟控制在毫秒级，对加密流量的内容不可见但不影响判定。对于使用定制化TLS实现的攻击者，指纹可能伪装得接近真实浏览器，这时需要第二层和第三层接力。
配置上，TLS指纹应当以白名单加分制而非黑名单封禁来使用：指纹落在真实浏览器已知范围内的请求获得较高初始置信度，指纹偏离的请求进入更严格的行为审查队列，而不是直接丢弃。直接按指纹封禁会误伤使用非主流TLS库的正常客户端（某些企业VPN、老旧终端、特定行业软件），低频CC防护的第一原则是误杀成本高于漏放成本，漏过的请求可以在后续层补救，误杀的真实交易无法挽回。
业务基线建模：每个接口一条独立的“正常水位线”
频率阈值失效之后，替代方案不是另一个全局数字，而是按接口分别建立动态基线。坚果盾在金融API场景下的做法是为每个API端点独立建模，跟踪正常请求速率、参数分布、响应时间、错误率、用户会话关联性等指标，用在线学习持续更新基线并检测偏离度。
基线建模的关键在于“偏离”不等于“攻击”。一个支付接口平时每秒200次请求、每个用户每分钟最多调用5次，攻击时飙升到5000次且大量来自无历史交易的新IP，这个偏离是强信号。但一个行情接口在开盘瞬间从200跳到2000，偏离同样巨大，却完全是正常业务。两者的区别不在幅度，而在偏离的结构：攻击流量的参数分布、会话关联性和IP历史画像与正常峰值有系统性差异。
可操作的配置顺序是：先给每个接口划定正常参数空间（路径、方法、Content-Type、关键字段的取值范围和格式），再设定速率基线的置信区间，最后把“速率偏离 + 参数分布异常 + 来源IP无历史”三个条件组合成触发条件，而不是任何一个单独指标越线就处置。对于转账、提现、登录这类高危接口，基线敏感度调高、触发组合条件收紧；对于查询类接口，容忍度可以放宽，优先保可用性。
设备与环境维度：把判定从“地址是谁”切换到“终端是不是真的”
秒拨IP改变的是源地址，但攻击工具所在的终端环境并不随之改变。一台运行自动化脚本的机器，即使每几分钟换一个公网IP，它的浏览器指纹、JavaScript执行能力、WebGL渲染特征、字体列表、鼠标轨迹仍然是同一套，与真实用户环境有稳定差异。
坚果盾的AI无感拦截在灰区请求上采用的正是这个逻辑：不立刻弹验证码，先通过轻量级挑战收集客户端环境完整性证据。真实浏览器在这些被动特征上表现稳定，headless浏览器和脚本工具会在某个环节露馅。判定为高置信度真人的请求直接放行，用户全程无感知；置信度不足的才进入轻量校验或显性验证。
这个维度对低频CC的意义在于它不依赖源IP的稳定性。秒拨IP可以无限更换地址，但更换不了终端环境指纹。设备维度与TLS指纹、业务基线叠加之后，攻击者要同时伪装三层才能穿过判定，成本从“买一个代理池”上升到“维护真实浏览器集群并模拟业务行为节奏”，低频CC的经济性被直接压缩。
需要注意的边界是：设备指纹的采集和校验必须控制在不影响首屏加载和核心交互的范围内。对于金融登录、支付发起这类关键路径，校验逻辑应当异步或内联完成，不阻塞主请求；对于无障碍访问、低版本浏览器和老旧终端，保留白名单策略，避免把合规用户挡在验证环节之外。
游戏与金融的策略分支：判定维度相同，处置节奏不同
低频CC的判定框架在游戏和金融场景下可以复用，但处置的松紧和验证的侵入程度必须按业务容忍度分开配置。
游戏场景的CC集中打在登录服和匹配服，攻击流量与真实玩家的请求在协议层可能完全一致，都是游戏客户端发出的加密二进制包。判定依据需要加入协议时序指纹：登录阶段先握手、再发固定长度的认证包、之后按固定间隔交换心跳，这个节奏模式攻击工具很难精确模仿。对可疑的UDP包，不直接丢弃，而是发一个基于时间戳和源IP生成的挑战码，要求客户端返回正确响应；验证通过的源IP进入临时信誉白名单，10分钟内免检放行，整个验证交互的额外延迟只有2—3ms。游戏场景的误杀率容忍度极低，坚果盾高防IP在游戏客户实战中公布的误杀率低于0.01%，清洗时延4.5ms，这个量级是游戏策略分支的基准线。
金融场景的处置节奏需要更保守。支付和交易接口的每一次误判都直接对应客诉和资损风险，因此策略重心放在精准识别而非快速封禁。TLS指纹和业务基线负责把可疑流量从正常交易中分离出来，渐进式验证按置信度分级：高置信度真人直接放行，中等置信度触发无感人机挑战，低置信度才进入限速或拦截。某股份制银行的实践数据是拦截99.2%恶意请求的同时，正常访问用户的验证率控制在极低水平。金融分支的配置原则可以概括为：宁可让少量攻击流量在多层过滤中漏过，也不让一个真实支付用户被误拦在交易之外。
从观察期到全量期：策略上线不要一步到位
低频CC防护的策略参数如果在上线第一天就按“理想值”配置，几乎必然产生误杀。可操作的推进节奏分三个阶段。
观察期只记录不拦截。把TLS指纹、设备特征、业务基线偏离度全部打成日志，跑完一个完整的业务周期（至少覆盖一次峰值和一次低谷），评估各维度在正常流量中的分布，确定初始阈值不会在正常峰值时触发。这个阶段的产出是一份“误杀预估”：如果按当前阈值全量执行，会有多少正常请求被处置。
灰度期只对高置信度可疑流量执行处置。把拦截范围收窄到多个维度同时越线的请求，观察拦截命中率和误杀反馈。灰度期的重点是验证判定组合是否有效，而不是追求拦截总量。如果高置信度区间的误杀率仍然不可接受，回到观察期调整组合条件，而不是靠放宽全部阈值来降误杀。
全量期按验证过的策略执行，但保留持续调优的入口。低频CC的攻击手法会迭代，秒拨IP的轮换策略、TLS库的伪装程度、行为模拟的精细度都会变化，基线模型需要持续学习而不是一次配置长期不动。调优中始终优先保误杀率：漏过的攻击可以在下一层被频率或人机校验兜底，误杀的真实用户不会回来。
常见问题
低频CC攻击用高防CDN还是高防IP防？
取决于攻击入口的协议形态。HTTP/HTTPS页面、小程序接口、Web API走高防CDN，在边缘节点完成TLS指纹采集和行为判定；游戏登录、支付网关的TCP端口、私有协议API走高防IP，在端口转发链路上做协议时序识别和动态挑战。两者都内置AI无感拦截，低频CC的判定逻辑一致，差异在接入层能看到的协议深度。
秒拨IP一直在换，封IP还有意义吗？
单独封IP对秒拨池的压制有限，但IP维度并非无用。IP的ASN归属、IDC属性、历史攻击记录、地理集中度仍然是有效信号，只是不能作为唯一判定依据。正确用法是把IP画像作为加权项，与TLS指纹、设备特征、业务基线组合判断，而不是按IP频率直接封禁。
低频CC防护会不会拖慢正常交易接口？
TLS指纹在握手阶段提取，业务基线是统计计算，设备校验以异步或内联方式注入，三者都不需要在请求路径上增加往返。坚果盾公布的低频CC防护链路对正常请求的附加延迟控制在5ms以内，游戏场景的验证交互额外延迟2—3ms。真正影响延迟的是策略配置过度激进导致的大量验证触发，这也是观察期和灰度期必须保留的原因。
业务峰值本身就像CC，基线会不会把峰值误判成攻击？
会，如果基线只看速率。业务基线建模的关键是同时跟踪速率、参数分布、会话关联性和来源IP历史，峰值期的正常流量在这些维度上仍然保持结构一致性，而攻击流量会在多个维度同时偏离。把“速率越线”作为单独触发条件必然误判峰值，组合条件才能把两者分开。
