公开的API接口就像一扇不上锁的门，任何人拿到地址都能发请求。如果没有任何防护，你的接口可能正在被成百上千个脚本日夜不停地扫描、抓取甚至刷数据。这些自动化流量不仅占用了大量带宽和服务器资源，还可能触发业务异常，比如秒杀接口被机器人抢空名额、用户数据被爬虫批量拉走。本文将以Node.js为核心，搭建一套自动化的API流量清洗体系，从请求特征识别到动态拦截，完整走一遍落地过程。
一、先搞清楚：恶意Bot流量到底长什么样
要做清洗，第一步是识别。在动手写代码之前，我们需要明白正常用户请求和机器人请求在特征上的差异。正常用户通过浏览器或App访问，请求头完整，行为有随机性，访问频率符合人类操作节奏；而自动化脚本往往是程序构造的HTTP请求，在很多细节上会露出马脚。
常见的识别维度有四个。第一是请求头特征，比如缺失Accept-Language、User-Agent为空或者明显是Python-requests、curl、Scrapy等已知工具签名。第二是行为特征，真人不会在一秒内对同一个接口发起五十次请求，也不会以毫秒级固定间隔轮询。第三是网络特征，同一IP段集中出现大量请求，或者来源IP属于数据中心机房而非家庭宽带。第四是高级特征，比如TLS握手指纹，很多HTTP客户端库的TLS ClientHello与浏览器存在明显差异，即使伪造了请求头也会暴露身份。
单看某一个维度都不足以定性，比如有些正常用户也会用代理，有些公司出口IP也是机房IP。所以工业界的做法是把多个维度的信号加权打分，超过阈值才判定为Bot。这套思路贯穿下文的所有实现。
二、基于Express中间件的请求特征初筛
初筛的目的是用最低的成本过滤掉最粗糙的脚本，这一层适合做成中间件，在请求进入业务逻辑之前就完成判断。下面是一个基于Express的实现，覆盖请求头校验、UA黑名单和基础格式检查。
const SUSPECT_UA = /(python-requests|scrapy|curl|wget|go-http-client|java\/|okhttp)/i;
function botPrefilter(req, res, next) {
const ua = req.headers['user-agent'] || '';
const score = { bot: 0, reasons: [] };
// UA为空或过短，高度可疑
if (!ua || ua.length < 10) {
score.bot += 40;
score.reasons.push('ua_missing_or_short');
}
// 命中已知工具签名
if (SUSPECT_UA.test(ua)) {
score.bot += 60;
score.reasons.push('ua_tool_signature');
}
// 缺失浏览器常见头
if (!req.headers['accept-language']) {
score.bot += 15;
score.reasons.push('no_accept_language');
}
if (!req.headers['accept'] || req.headers['accept'] === '*/*') {
score.bot += 10;
score.reasons.push('suspicious_accept');
}
// Header顺序异常：Node的HTTP客户端不会先发Cookie再发Host，浏览器会
const headerOrder = Object.keys(req.headers);
if (headerOrder[0] === 'cookie' && headerOrder.indexOf('host') > 2) {
score.bot += 15;
score.reasons.push('header_order_anomaly');
}
req.botScore = score;
if (score.bot >= 60) {
return res.status(403).json({ code: 'BOT_BLOCKED' });
}
next();
}
app.use(botPrefilter);这个实现的要点在于没有采用一刀切，而是累积分数。单个特征命中只加分，达到阈值才拒绝，这样能避免误杀那些关掉了语言偏好的真实用户。被拦截的请求建议写入日志并附带reasons字段，方便后续分析新型Bot的特征。另外要注意，UA和请求头都可以伪造，这一层只能挡住低成本的扫描器，真正对抗性的爬虫需要靠后面的行为分析和指纹检测。
三、用Redis做行为频率统计与动态限流
特征可以被伪造，但行为模式很难隐藏。一个脚本要完成抓取任务，必然表现出高频、规律、覆盖面广的访问模式，这些都可以通过请求计数统计出来。Redis天然适合这类高频计数场景，配合滑动窗口算法可以精准限制单IP或单账号的访问速率。
const redis = require('redis');
const client = redis.createClient({ url: 'redis://127.0.0.1:6379' });
// 滑动窗口限流：窗口60秒，阈值120次
async function slidingWindowLimit(key, windowSec = 60, maxReq = 120) {
const now = Date.now();
const member = `${now}:${Math.random().toString(36).slice(2, 8)}`;
const pipeline = client.multi();
pipeline.zAdd(key, { score: now, value: member });
pipeline.zRemRangeByScore(key, 0, now - windowSec * 1000);
pipeline.zCard(key);
const results = await pipeline.exec();
const count = results[2][1];
if (count > maxReq) {
await client.expire(key, windowSec * 2);
return { allowed: false, count };
}
await client.expire(key, windowSec);
return { allowed: true, count };
}
async function behaviorGuard(req, res, next) {
const ip = req.ip;
const path = req.path;
// 分别统计：全局速率 + 单接口速率
const global = await slidingWindowLimit(`rl:${ip}`, 60, 200);
const perApi = await slidingWindowLimit(`rl:${ip}:${path}`, 60, 60);
if (!global.allowed || !perApi.allowed) {
// 连续触发限流的IP进入观察名单，累计3次直接封禁
const strikes = await client.incr(`strike:${ip}`);
await client.expire(`strike:${ip}`, 3600);
if (strikes >= 3) {
await client.set(`banned:${ip}`, '1', { EX: 86400 });
}
return res.status(429).json({ code: 'RATE_LIMITED' });
}
next();
}滑动窗口相比固定窗口的优势是不会出现窗口边界的速率突刺，统计更平滑。上面的代码还实现了一个渐进式惩罚机制：偶尔超限可能只是用户手速快，但如果短时间内反复触发限流，就会被打入观察名单，累计三次直接封禁一天。这种阶梯式响应比直接永久封IP更稳妥，因为家庭宽带的IP会被运营商动态分配，永久封禁可能误伤后来分到这个IP的正常用户。
除了计数，还可以统计请求间隔的方差。真人的操作间隔波动很大，脚本的间隔往往非常规律，标准差接近零。把每个IP最近一百次请求的时间戳存进Redis的List，计算间隔方差，低于设定阈值就额外加分，这个信号对伪装得很好的定时任务型爬虫特别有效。
四、分层拦截架构与人机验证兜底
前面的手段都是在服务器侧静默判断，但对抗是持续升级的。当Bot升级到使用无头浏览器、代理池加随机化间隔时，静态规则的命中率会下降。这时候需要一套分层架构，把处置手段从轻到重排列，既保证拦截效果，也控制误杀成本。
推荐的四层结构是这样的：第一层是边缘CDN或WAF的IP信誉过滤，直接挡掉已知恶意网段，成本为零；第二层是本文实现的特征初筛和频率限流，拦截绝大部分脚本流量；第三层是挑战验证，对可疑但不确定的请求触发一次行为验证，比如JavaScript质询——下发一段只能在真实浏览器执行的计算任务，脚本拿不到结果就无法继续；第四层是业务风控，对核心接口要求登录态加签，请求参数带时间戳和签名，服务端验签不过直接拒绝。
JavaScript质询的实现思路值得展开说一下：首次访问时服务端返回一段加密挑战串和一段混淆过的JS代码，浏览器执行后计算出应答串带回，服务端校验。由于代码经过混淆且带时效，脚本作者逆向的成本会远高于换一个目标。对无法执行JS的纯HTTP客户端，这一招几乎是降维打击。
// 简化的JS质询流程
const crypto = require('crypto');
function issueChallenge(res) {
const seed = crypto.randomBytes(16).toString('hex');
const answer = crypto.createHash('sha256').update(seed + 'salt').digest('hex');
// seed存入会话，5分钟有效
challengeStore.set(seed, { answer, expires: Date.now() + 300000 });
res.json({ challenge: seed });
}
function verifyChallenge(seed, clientAnswer) {
const record = challengeStore.get(seed);
if (!record || Date.now() > record.expires) return false;
challengeStore.delete(seed); // 一次性使用
return crypto.timingSafeEqual(
Buffer.from(record.answer),
Buffer.from(clientAnswer)
);
}最后提醒几个容易踩的坑：一是不要在拦截响应里暴露过多信息，返回统一的403或429即可，错误信息越详细越容易被脚本作者利用来调试绕过；二是所有封禁决策要有白名单逃生通道，比如支付回调、搜索引擎爬虫的UA加反向DNS双重验证后才放行；三是监控拦截率的变化曲线，如果某天拦截率骤降而流量正常，大概率是Bot换了新特征，需要及时更新规则。流量清洗从来不是一次性工程，而是一个持续对抗、持续迭代的过程，把日志分析闭环建好，规则库才能跟着威胁一起进化。