CC防护使用会话验证码仅在异常请求时弹出

CC防护中的会话验证码策略，核心逻辑就是"不打扰正常用户，只拦截异常流量"。具体做法是：通过前端埋点或后端行为分析，识别出短时间内高频请求、非人类操作特征、IP异常等信号，仅在这些异常场景下才触发验证码弹窗，而正常浏览、登录、提交表单等操作完全无感通过。这套机制既能有效抵御CC攻击，又不会因为全站弹验证码而导致用户体验崩塌和转化率下降。

很多网站运营者面临一个两难困境：开了CC防护全站弹验证码，用户嫌烦直接走了；不开防护，服务器被打崩。会话验证码仅在异常请求时弹出，就是解决这个矛盾的最佳方案。下面我从原理、实现方式、配置策略、注意事项四个维度，把这件事讲透。

传统CC防护的做法比较粗暴，要么直接封IP，要么全站弹验证码。这两种方式都有明显缺陷。封IP容易误杀，因为很多用户共享出口IP，一个人被封可能影响一大片人。全站弹验证码更是杀敌一千自损八百，正常用户每操作一次就要输入一次验证码，体验极差，电商站、内容站的跳出率会飙升。

会话验证码的"按需弹出"策略，本质上是一种精细化的流量治理思路。它的判断依据通常包括以下几个维度：同一IP在单位时间内的请求次数、请求间隔是否符合人类操作节奏、User-Agent是否异常、是否携带自动化工具特征、会话行为路径是否合理。只有当多个指标同时指向"非正常"时，才触发验证码挑战。

这种策略的好处非常明显。第一，正常用户几乎感受不到防护的存在，页面加载速度和操作流畅度不受影响。第二，攻击者的自动化脚本会被精准拦截，而且因为是会话级别的验证，攻击者很难通过简单的换IP绕过。第三，服务器资源消耗大幅降低，因为不需要对每个请求都做验证码渲染和校验。

实现"仅异常时弹出"的会话验证码，通常需要前端和后端协同配合。整体架构分为三层：行为采集层、判定决策层、验证执行层。

行为采集层负责记录用户的每一次操作。前端通过JavaScript埋点，记录点击事件、页面停留时间、滚动行为、表单填写节奏等数据，并通过AJAX定时上报到后端。后端则记录请求频率、IP信息、请求头特征、会话Token状态等。这些数据构成了判断"正常还是异常"的原始依据。

判定决策层是核心。后端根据预设的规则引擎或机器学习模型，对采集到的行为数据进行实时分析。常见的规则包括：单IP每分钟请求超过60次触发预警、同一会话5秒内提交超过3次表单触发验证、检测到无头浏览器特征直接弹出验证码、请求频率呈规律性脉冲特征判定为机器行为。

验证执行层负责在判定为异常后，向前端返回验证码挑战指令。前端收到指令后，在当前页面或通过弹窗展示验证码，用户完成验证后，后端为该会话标记"已验证"状态，后续请求在一定时间窗口内免检。这个时间窗口通常设置为5到30分钟，根据业务安全等级调整。

下面给出一个基于Node.js的简化实现示例，展示如何在异常请求时才触发会话验证码：

const express = require('express');
const session = require('express-session');
const app = express();

app.use(session({
  secret: 'your-secret-key',
  resave: false,
  saveUninitialized: true,
  cookie: { maxAge: 30 * 60 * 1000 }
}));

// 请求频率统计（生产环境建议用Redis）
const requestCounter = new Map();

function isAbnormal(req) {
  const ip = req.ip;
  const now = Date.now();
  const key = `rate:${ip}`;
  
  if (!requestCounter.has(key)) {
    requestCounter.set(key, { count: 1, start: now });
    return false;
  }
  
  const record = requestCounter.get(key);
  record.count++;
  
  // 60秒内超过50次请求判定为异常
  if (record.count > 50 && (now - record.start) < 60000) {
    return true;
  }
  
  // 重置计数器
  if (now - record.start > 60000) {
    requestCounter.set(key, { count: 1, start: now });
  }
  
  return false;
}

app.use((req, res, next) => {
  const sessionData = req.session;
  
  // 已验证的会话在有效期内免检
  if (sessionData.verified && sessionData.verifiedAt > Date.now() - 10 * 60 * 1000) {
    return next();
  }
  
  // 检测异常行为
  if (isAbnormal(req)) {
    // 返回需要验证码的标识
    res.status(403).json({ needCaptcha: true, reason: 'abnormal_request' });
    return;
  }
  
  next();
});

// 验证码验证接口
app.post('/api/captcha/verify', (req, res) => {
  const { sessionId, captchaInput } = req.body;
  // 校验逻辑（此处简化）
  if (captchaInput === 'correct') {
    req.session.verified = true;
    req.session.verifiedAt = Date.now();
    res.json({ success: true });
  } else {
    res.json({ success: false });
  }
});

这段代码展示了基本思路：用Map做内存级别的频率统计，对异常请求返回403状态并附带needCaptcha标识，前端根据这个标识决定是否弹出验证码。生产环境中，频率统计应该用Redis等分布式存储，并且要加入更多维度的判断，比如请求路径分析、行为指纹识别等。

前端的职责是监听后端返回的异常信号，并在合适的时机展示验证码。关键点有三个：第一，不要在页面加载时就弹验证码，而是在用户进行下一步操作时（比如点击提交按钮）才触发，这样用户感知更自然。第二，验证码的展示形式要轻量，推荐使用滑块验证或点选验证，比传统字符输入体验好得多。第三，验证通过后要及时清除状态，避免用户重复操作时再次弹出。

前端伪代码逻辑如下：

// 拦截表单提交
document.querySelector('#submitBtn').addEventListener('click', async (e) => {
  e.preventDefault();
  
  const response = await fetch('/api/submit', {
    method: 'POST',
    body: formData
  });
  
  if (response.status === 403) {
    const data = await response.json();
    if (data.needCaptcha) {
      showCaptchaModal(); // 弹出验证码
    }
  } else {
    // 正常提交
    handleSuccess(response);
  }
});

function showCaptchaModal() {
  // 展示滑块验证组件
  const modal = document.createElement('div');
  modal.innerHTML = '<div class="captcha-slider">拖动滑块完成验证</div>';
  document.body.appendChild(modal);
  
  // 验证成功后提交
  onCaptchaVerified(() => {
    document.querySelector('#submitBtn').click();
  });
}

这种方式的优势在于，验证码只在真正需要的时候才出现，用户在正常浏览时完全不会被打断。而且滑块验证的通过率高、用户反感度低，比传统图形验证码好用很多。

会话验证码要真正做到"精准弹出"，阈值配置是关键。配置太松，攻击者能钻空子；配置太紧，正常用户会被误伤。以下是经过实战验证的参考阈值：

单IP请求频率：普通网站建议设为每分钟40到60次，高流量网站可以适当放宽到80次。这个数值要结合你网站的实际PV和UV比例来定。如果你的网站平均每个用户每分钟只产生3到5次请求，那40次就已经是很明显的异常了。

会话行为判断：同一会话在10秒内发起超过5次POST请求，或者连续访问超过20个不同页面且每个页面停留不超过1秒，都应该触发验证。这些行为模式几乎不可能是真人操作。

验证有效期：建议设置为10到20分钟。太短会导致用户频繁被弹验证，太长则安全窗口过大。对于安全性要求高的场景（比如支付、登录），可以缩短到5分钟。

另外要注意一个细节：不要只依赖单一指标。比如某个用户IP请求频率高，但同时他的浏览路径合理、停留时间正常、操作节奏像真人，那可能只是因为他在公司网络里和很多人共享了一个出口IP。这种情况下应该结合多维度判断，而不是一刀切地弹验证码。

第一个坑：验证码被绕过。有些攻击者会用打码平台或者OCR自动识别验证码。解决方案是使用行为验证（滑块、点选）而不是纯字符识别，因为行为验证需要模拟人类操作轨迹，自动化破解成本高得多。

第二个坑：正常用户被误伤。特别是在促销活动、秒杀场景下，大量用户同时涌入，频率阈值很容易被触发。解决方案是在大促前临时调高阈值，或者对已登录用户降低触发标准，因为登录用户的身份已经经过一次验证。

第三个坑：验证码弹出后影响SEO。如果搜索引擎爬虫被误判为异常流量并弹出验证码，会导致页面无法被正常抓取。解决方案是对已知的爬虫UA（如百度蜘蛛、必应爬虫等）设置白名单，直接放行不触发验证。

第四个坑：状态同步问题。如果你用了多台服务器做负载均衡，单台服务器的内存计数无法反映全局情况。必须用Redis等集中式存储来共享频率数据，确保任意一台服务器都能做出一致的判断。

如果你的技术团队有能力，可以在规则引擎基础上引入机器学习模型。通过收集正常用户和攻击流量的行为特征数据，训练一个分类模型，让系统自动学习什么是"正常"、什么是"异常"。这种方式比硬编码规则更灵活，能识别出规则覆盖不到的新型攻击手法。

但要注意，AI方案不是银弹。模型需要持续训练和更新，而且初期冷启动阶段可能误判率较高。建议先用规则引擎跑稳，再逐步叠加AI能力，两套机制互为补充。

总结来说，CC防护中会话验证码仅在异常请求时弹出，是当前兼顾安全和体验的最优解之一。它的核心在于"精准识别、按需触发"，而不是一刀切的全站拦截。实现上需要前后端配合、多维度判断、合理的阈值配置，以及对特殊场景的针对性处理。把这些做到位，你的网站既能扛住CC攻击，又不会把正常用户赶走。