本文目录导读：
接口防刷（防止恶意请求、爬虫、CC攻击等）的核心策略通常从频率控制、行为验证、资源消耗三个维度出发，以下是一套可配置的防刷策略体系：
核心策略维度
频率限制（最基础）
- IP级别：同一IP单位时间内请求次数
- 用户级别：同一用户（Token/UserID）请求次数
- 设备指纹级别：设备ID、浏览器指纹
- 接口级别：不同接口独立配置阈值
行为分析
- 请求间隔：正常用户请求有随机间隔，爬虫常固定间隔
- 请求顺序：正常用户操作有逻辑顺序（先登录再操作）
- 请求路径：异常用户可能遍历API路径
- 请求参数：固定参数或参数变化规律异常
验证机制
- 图形验证码：超过阈值后触发
- 滑块验证：行为验证
- 短信验证：高频操作触发二次验证
- Token校验：动态Token、签名校验
可配置化策略方案
配置中心设计（YAML示例）
anti-scrape:
# 全局开关
enabled: true
# 频率限制配置
rate-limit:
ip:
enabled: true
window: 60 # 时间窗口（秒）
max-requests: 100 # 窗口内最大请求
block-duration: 300 # 封禁时长（秒）
user:
enabled: true
window: 60
max-requests: 30
block-duration: 1800
api:
# 按接口细粒度配置
/api/login:
window: 60
max-requests: 5
/api/query:
window: 10
max-requests: 20
# 行为分析配置
behavior-analysis:
interval-check:
enabled: true
min-interval: 0.5 # 最小请求间隔（秒）
sample-size: 10 # 检测样本数
path-traversal:
enabled: true
suspicious-patterns: ['/api/\\d+', '/admin/.+']
# 验证码触发配置
captcha:
trigger:
type: 'threshold' # threshold | risk-score
threshold: 5 # 第6次失败触发
challenge:
type: 'slider' # slider | image | sms
expire: 120 # 验证码有效期（秒）
动态规则配置（从数据库/配置中心加载）
-- 防刷规则表
CREATE TABLE anti_scrape_rules (
id INT PRIMARY KEY AUTO_INCREMENT,
rule_name VARCHAR(50) NOT NULL,
dimension ENUM('ip', 'user', 'device', 'api') NOT NULL,
window_size INT NOT NULL COMMENT '窗口大小(秒)',
max_requests INT NOT NULL COMMENT '限制请求数',
action ENUM('block', 'captcha', 'delay', 'log') NOT NULL,
action_value VARCHAR(100) COMMENT 'block时长或delay毫秒',
priority INT DEFAULT 0,
enabled TINYINT(1) DEFAULT 1,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
分层策略实现
第一层：前置过滤（网关层）
# Nginx + Lua 实现
lua_shared_dict anti_scrape_cache 10m;
location /api/ {
access_by_lua_block {
local anti_scrape = require("anti_scrape")
anti_scrape.check({
ip = ngx.var.remote_addr,
path = ngx.var.uri,
method = ngx.req.get_method()
})
}
}
第二层：业务层（注解驱动）
@AntiScrape(
dimension = "user",
window = 60,
maxRequests = 30,
action = Action.CAPTCHA,
actionValue = "slider"
)
@PostMapping("/api/order")
public Result createOrder(@RequestBody Order order) {
// 业务逻辑
}
第三层：自适应策略（智能限流）
class AdaptiveRateLimiter:
"""基于机器学习的自适应限流"""
def __init__(self):
self.model = load_model('behavior_model.h5')
self.cache = RedisCluster()
def score(self, request_features):
"""计算风险分数"""
features = self.extract_features(request)
risk_score = self.model.predict(features)
if risk_score > 0.8:
return 'BLOCK'
elif risk_score > 0.5:
return 'CAPTCHA'
else:
return 'PASS'
策略配置管理
动态调整API
# 实时更新规则
POST /api/admin/anti-scrape/rules
{
"rule": {
"dimension": "ip",
"window": 30,
"maxRequests": 50,
"action": "block",
"duration": 600
}
}
# 查询当前活跃规则
GET /api/admin/anti-scrape/rules?status=active
策略优先级
高优先级 → 低优先级
用户级别白名单 > IP白名单 > 用户级别黑名单 > 频率限制 > 行为分析 > 全局策略监控与告警
关键指标
- 触发率：各策略被触发的次数/比率
- 误杀率：被误判的正常用户比例（需人工审核）
- 响应延迟：防刷模块对正常请求的影响
- 封禁分布：被封IP/用户的地域、时段分布
告警阈值
{
"alerts": [
{
"metric": "trigger_rate",
"condition": "> 10%",
"window": "5m",
"action": "slack_notify + pause_aggressive_rules"
},
{
"metric": "false_positive",
"condition": "> 0.1%",
"window": "1h",
"action": "rollback_last_config"
}
]
}
最佳实践建议
- 灰度发布：新策略先对5%流量生效，逐步扩大
- 用户分层：VIP用户、内部IP使用不同的策略
- 缓存优化：使用Redis Cluster存储计数器，避免单点瓶颈
- 成本控制：验证码、短信验证等成本较高的策略设置合理阈值
- 日志审计：记录所有触发的请求详情，便于后续分析
常见场景配置示例
场景1：登录接口防爆破
/api/login: ip_limit: 10次/分钟 → 封禁15分钟 user_limit: 5次/小时 → 触发滑块验证 device_limit: 3次/小时 → 触发短信验证（高风险）
场景2：数据爬虫防护
/api/data:
ip_limit: 100次/分钟
behavior:
min_interval: 1秒
consecutive_patterns: ['page', 'next_page'] # 连续翻页检测
captcha_trigger:
after_50_requests: true
这套策略配置体系可以根据业务场景灵活组合,建议从简单频率限制开始，逐步增加行为分析和自适应策略。
