娱乐城网站被刷得像筛子？别急着调参数，先看看这5个坑你踩了没
登录页面卡成PPT，抽奖接口动不动就返回“系统繁忙”，后台日志里全是重复的 /api/draw 请求——别慌，大概率不是服务器扛不住，是有人在拿你家接口当“免费试玩区”了。这种攻击不靠流量堆死你，而是用成千上万的“假人”模拟正常用户行为，悄无声息地把后端服务拖垮。
说白了，问题根本不在带宽或配置多高，而在于：你的WAF压根没挡住该拦的流量。
别一上来就冲着买更高配实例、升级防护套餐去。真能扛住这类攻击的，是在应用层设置精准的访问频率控制策略，而且得结合你自己的业务逻辑来调，不能照搬模板。
普通防火墙为啥挡不住？因为分不清谁是人、谁是机器
很多人觉得开了防火墙就万事大吉，现实却打脸打得啪啪响：
普通防火墙只看源IP和端口，连“人”和“脚本”都分不清；
攻击者用几百个合法代理轮着发请求，每个都不超限，系统还以为是“正常用户”；
娱乐城常见的“每日签到”“抽奖领取”这些接口，本身设计就是高频访问，结果成了攻击者的天然掩护。
所以啊，必须在应用层做识别，光靠网络层过滤等于白搭。
⚠️ 特别提醒：如果你的业务没强制登录，或者用户没绑定唯一身份标识（比如
uid），那所有基于用户维度的限流，基本都是摆设。
华为云WAF防CC实战五步走（可直接抄，但记得加血）
以下基于华为云标准WAF功能，适合中小型娱乐城场景。但得说清楚：这套方案在极端攻击下照样会崩，维护起来也挺费劲。
第一步：先把关键接口列出来
别想着“全站保护”，先盯住最容易被刷的几个点，比如：
/api/draw（抽奖）/login（登录）/checkin（签到）/get_reward（领奖）
这几个接口是攻击重灾区，必须单独设规则。不然你搞一堆防御，攻击者专挑没防护的入口猛攻，白忙活。
✅ 补充建议：
如果某个接口允许匿名访问，又没有身份标识，那就别指望靠
uid来限流；这类接口建议配合“行为分析” “验证码”双重验证，否则单纯限流纯属自欺欺人。
第二步：启用频率控制，但别信默认值
进华为云WAF控制台 → 安全策略 → 频率控制。
关键配置别照搬：
触发条件：每分钟同一用户请求超过10次
统计对象：选“自定义字段”，填
cookie:uid（前提是登录后返回的 uid 是稳定唯一的）处置动作：阻断 记录日志
生效范围：只对上述接口生效
✅ 优点很明显：不至于因为封一个IP，导致一整群正常用户被误伤（尤其在用NAT出口的环境里，一个公网IP背后可能上百个用户）。
❌ 真实痛点：
很多平台的
uid是动态生成的，登录后才写入，前10秒内根本识别不了用户，攻击者刚好趁这个空档刷一波；用户换浏览器/设备登录，可能被误判为“多个用户”；
某些客户端缓存
uid，登出后还留着，变成“幽灵账号”长期存在。实战经验：
别一上来就设10次/分钟，先从 30次/分钟 开始测，观察三天日志，看有没有误拦；
一旦发现异常，立刻降到 15次/分钟，并加入人工审核队列；
对高价值接口（比如抽奖），别光靠限流，最好叠加滑动验证码或短信验证，否则攻击者轻轻松松就能绕过去。
第三步：打开浏览器合法性检测，但别太当真
在WAF里打开“反爬虫”模块，重点开启两项：
检查
User-Agent是否是常见爬虫（比如Python-requests,curl）检查是否为无头浏览器（如
Puppeteer,Selenium）
设置为“阻断”，能干掉90%以上的自动化脚本。
✅ 有效的时候：
攻击者用原始脚本批量发包，没伪装浏览器行为，基本一抓一个准。
❌ 但十有八九会失效：
攻击者用了 浏览器指纹伪造工具（比如 Puppeteer stealth plugin），完全骗过检测；
用 真实安卓模拟器 或手机端环境，伪装成真人操作；
新型攻击工具已经能模拟鼠标轨迹、点击间隔、滚动节奏，传统检测形同虚设。
真实教训：
有个棋牌平台，启用了浏览器检测，结果攻击流量还是每秒2000 ，因为对方用了真实安卓模拟器 本地代理池，系统根本看不出破绽。实战建议：
别依赖单一手段，必须跟“行为分析”联动（比如点击间隔、页面停留时间）；
可以先设成“警告 记录”，观察几天再决定要不要正式拦截；
如果发现大量非浏览器请求来自东南亚、东欧等地区，大概率是僵尸网络，建议联动DDoS清洗。
第四步：接入Anti-DDoS服务，但别等崩了才开
如果发现攻击来自单一地区，或出现大量异常源IP，说明已超出普通WAF处理能力。
这时候要联动 华为云Anti-DDoS服务：
在控制台开启“BGP引流”
攻击流量自动被牵引到清洗中心
清洗后的干净流量再回注到原站
整个过程全自动，不用手动干预。
⚠️ 重要提醒：
这功能得提前开通并绑定域名，别等到攻击来了才去申请，那时候早就晚了；
某些小运营商线路（比如某省电信）高峰期容易丢包，即使引流成功，也可能部分请求丢了；
引流后，原站入口延迟可能增加50~100毫秒，对实时性要求高的游戏接口影响不小。
隐性代价：
Anti-DDoS按峰值流量计费，攻击持续4小时，费用可能上千块；
如果你月预算低于5000元，强烈建议放弃这个方案，直接改用备选：前置CDN 自建限流中间件。
第五步：设置监控告警，但别指望它能救命
用 云监控CES 设几条报警规则：
某接口1分钟内请求量突增超过500次，立即发短信/邮件通知
每天查看一次WAF拦截日志，排查误拦情况
重点看被拦截请求的来源，确认是不是真攻击。
✅ 有用的地方：
能及时发现异常波动，防止事态扩大。
❌ 常见坑：
告警阈值设得太低（比如100次/分钟），每天收几十条无效通知，听得人头疼；
忽略日志存储周期，30天后自动删了，出了事根本没法追溯；
没人定时看日志，告警成了“电子噪音”。
实战建议：
告警阈值设为 800次/分钟，并加上“连续3次触发才报警”；
日志至少保留60天，建议导出到OSS独立存储；
安排专人轮班盯盘，尤其活动期间，凌晨2点到5点是最容易被攻击的时间段。
常见错误配置陷阱（别再犯了！）
❌ 把限流条件设成“按IP”，结果共享公网下的正常用户被误封（尤其某些云厂商的弹性公网地址，一个IP背后上百个用户）；
❌ 限流阈值设得太低（比如每分钟3次），反而让攻击者轻松绕过（他们只要调慢点间隔就行）；
❌ 测试阶段忘了关日志记录，结果存储爆了，每月多花几千块不说，还可能拖慢主站性能；
❌ 规则库不更新，新出现的攻击手段（比如“慢速攻击” “伪装心跳包”组合）根本拦不住；
❌ 盲目相信“一键防护”模板，不根据业务调整参数，结果防御失效还怪系统不行。
真实案例：某棋牌平台扛住单日10万次攻击（细节版）
背景：一家小型娱乐城，在活动期间遭遇疑似组织化刷奖攻击，服务器负载飙到98%，部分接口响应超5秒。
应对措施：
在
/api/draw接口启用 按uid限流（30次/分钟），并开启日志记录；启用浏览器检测，拦截非浏览器请求；
发现攻击集中在凌晨2点，判断为自动化脚本，启动Anti-DDoS BGP引流；
实时监控发现攻击源主要来自东南亚，且请求携带固定特征头，手动添加规则屏蔽；
3天后拉黑17个异常账号，并限制其登录行为。
结果：攻击持续4小时后停止，正常用户访问不受影响，服务器稳如老狗。
关键细节：
攻击者用了120个代理IP，每个都注册新账号，但未使用真实浏览器环境，因此被浏览器检测拦下；
最终清点，共拦截9.7万次非法请求，其中3.2万次来自已知恶意指纹；
但仍有近2000次请求绕过了检测，原因是部分请求使用了老旧安卓模拟器，未被识别。
业内真实做法 & 成本更低的平替方案（别被忽悠）
✅ 中大型平台怎么干（真实反馈）：
通用架构是 “WAF CDN 自研限流中间件” 三层防线；
核心接口（如抽奖）不依赖WAF限流，而是由业务层用 令牌桶 滑动窗口 控制；
高频接口强制接入 验证码 或 行为验证（比如点图拼图、滑动验证）；
所有异常请求统一打标，进入风控系统做二次判定。
预算有限怎么办？试试这些平替方案：
用CDN前置 Nginx限流：在边缘节点用
ngx_limit_req控制频率，比WAF便宜90%以上；自建轻量级限流服务：用 Redis Lua 写个每分钟10次的令牌发放逻辑，部署在应用前；
静态资源分离 接口隔离：把抽奖、签到这些接口独立部署，方便单独防护；
用现有日志系统做实时分析：用ELK或Prometheus Alertmanager，实现低成本监控。
劝退指南：
如果你符合以下任一情况，请直接放弃高级WAF限流方案：
月预算低于3000元；
没有专职运维人员；
业务接口少于5个；
从未做过安全审计；
服务器部署在本地机房；
建议改用 CDN Nginx限流 人工巡检 组合，省钱又够用。
总结：别再幻想“一键防御”
真正的防护，从来不是靠某个按钮，而是在真实业务中不断试错、调参、复盘。
别信“0误伤”“100%拦截”的宣传；
别指望一个规则解决所有问题；
别忽略维护成本和副作用。
最靠谱的做法是：先用简单方案跑起来，再逐步加固。
记住一句话：
能挡住攻击的不是配置，是你每天盯着日志的眼睛。