面对CC攻击，前端静态资源与动态接口的分离部署策略
摘要：# 当CC攻击来敲门：别让静态图片拖垮你的动态接口 上个礼拜，我和一个做电商的朋友吃饭，他愁眉苦脸地说：“网站又卡了，用户投诉说下单页面刷不出来。” 我第一反应是：“又被打了？” 他摇摇头：“没啊，监控显示流量正常，服务器负载也不高。” 我让他打开开发…
当CC攻击来敲门：别让静态图片拖垮你的动态接口
上个礼拜，我和一个做电商的朋友吃饭，他愁眉苦脸地说：“网站又卡了，用户投诉说下单页面刷不出来。” 我第一反应是：“又被打了？” 他摇摇头：“没啊，监控显示流量正常，服务器负载也不高。”
我让他打开开发者工具看了一眼——好家伙，首页几十张高清大图，一个轮播图接口每秒被调用几百次。这哪是正常流量，分明是有人盯着他的动态接口，用请求静态资源的姿势在搞事情。
这种场景你应该不陌生吧？很多中小站长都觉得：“我上了CDN，图片都缓存了，应该安全了吧？” 说真的，这种想法很危险。 很多所谓防护方案，PPT很猛，真被打的时候就露馅了。
一、CC攻击的“新玩法”：专挑你的逻辑漏洞
先别急着关页面，我问你个问题：如果你的网站首页有10张轮播图，每张图都通过一个动态接口/api/get-banner?id=xxx来获取地址，攻击者只需要用脚本疯狂刷新这个接口，你的服务器会怎样？
——CPU会飙升，数据库连接池会被占满，而你的CDN可能还在悠闲地喝茶。
这就是典型的利用静态资源请求动态接口的攻击手法。攻击成本极低，一个Python脚本加一堆代理IP就能搞起来，但防御起来却特别头疼。
我见过最离谱的案例，是上海一家做在线教育的公司。他们的课程封面图都是通过/api/course-cover?course_id=xxx这个接口返回的。攻击者就盯着这个接口打，每秒几千次请求，直接把MySQL打崩了。更讽刺的是什么？这些封面图其实都是固定的，完全可以直接用静态URL。
很多站点的架构问题，不是没上防护，而是配错了。 你把金库大门装了防弹玻璃，却把钥匙挂在门口的信箱里——这防护有意义吗？
二、分离部署：不是“要不要”，而是“怎么分”
好了，吐槽完了，咱们说点实在的。
静态资源和动态接口分离，这个道理谁都懂。但真正做的时候，十个有八个都做得半吊子。我总结了一下，常见的坑有这么几个：
1. “伪静态”陷阱
很多开发者喜欢用伪静态，比如把/product/123重写成/api/product?id=123，觉得这样“优雅”。优雅是优雅了，但攻击者也优雅地找到了所有动态端点。
说白了，动态接口就该长得像动态接口。 别玩那些花里胡哨的伪装，该用/api/开头的就用/api/开头，该用.php、.aspx的就别藏着掖着。这样至少WAF规则好写，清洗策略好配。
2. CDN配置的“想当然”
我在腾讯云、阿里云的工单系统里看到过太多这样的问题：“我开了CDN加速，为什么网站还是被CC打垮了？”
——因为你的CDN只缓存了.css、.js、.jpg这些明显是静态的文件，但那些返回图片URL的动态接口，CDN默认是不缓存的。攻击者就盯着这些接口打，请求根本不经过CDN缓存层，直接回源到你的服务器。
解决方案其实很简单（但也容易被忽略）：
- 给真正的静态资源用独立的域名，比如
static.yourdomain.com - 这个域名只放静态文件，不部署任何动态程序
- 配置严格的缓存策略，比如图片缓存30天，CSS/JS缓存7天
- 最关键的一步：把这个域名解析到高防CDN，而不是普通CDN
普通CDN和高防CDN的区别，就像小区保安和特种兵——一个负责维持秩序，一个负责应对极端情况。
3. 动态接口的“裸奔”问题
如果你的动态接口还直接暴露在公网，那我劝你今晚别睡了，赶紧去处理。
源站隐藏这个词听起来高大上，其实原理特别简单：只允许特定的IP（比如高防CDN的回源IP、高防IP的转发IP）访问你的真实服务器，其他所有请求一律拒绝。
具体怎么做？以Nginx为例，几行配置就能搞定：
location / {
# 只允许高防CDN的回源IP段访问
allow 1.2.3.0/24; # 替换成你的高防服务商提供的IP段
allow 5.6.7.0/24;
deny all;
proxy_pass http://your_backend;
}这种配置下，攻击者即使知道你的源站IP，也摸不到你的服务器。他们只能打到高防节点上，而高防节点的防护能力，通常是你源站服务器的几十倍甚至几百倍。
三、实战策略：从“能抗”到“会躲”
分离部署只是第一步，接下来得考虑怎么“聪明地抗”。
策略一：动静彻底分离
-
静态资源域名：
static.example.com- 全部走CDN，配置长期缓存
- 开启HTTPS，但不用考虑动态验证
- 可以放到对象存储（OSS/COS）上，成本低，扩展性强
-
动态接口域名：
api.example.com- 不直接暴露，通过高防IP或高防CDN转发
- 所有接口必须有频率限制（rate limiting）
- 关键业务接口（登录、下单）要加验证码或token验证
策略二：动态资源的“静态化降级”
这是很多大厂在用的技巧——当检测到CC攻击时，自动降级。
比如你的商品详情页，正常情况是通过/api/product-detail?id=xxx动态渲染的，里面包含库存、价格等实时数据。当CC攻击来临时，可以临时切换到一个静态版本：
- 价格显示“咨询客服”
- 库存显示“现货”
- 购买按钮变成“到货通知”
这个静态页面可以提前生成，放到CDN上。虽然用户体验打了折扣，但至少网站能正常打开，不会完全瘫痪。
这种策略的精髓在于：用体验换生存。 在攻击期间保住80%的功能，总比完全宕机强。
策略三：监控的“颗粒度”
别只盯着CPU、内存这些宏观指标。CC攻击的早期迹象往往在微观层面：
- 某个特定接口的QPS突然飙升
- 数据库的
SELECT操作暴增 - Redis的缓存命中率骤降
我推荐在关键接口上埋点，记录：
- 请求来源IP（看是不是集中在某些IP段）
- User-Agent（看是不是大量相同的UA）
- 请求参数（看是不是在遍历id）
这些数据不用实时分析，存到ELK或者时序数据库里，出问题的时候再查。但采集必须实时，否则攻击过去了，你连证据都找不到。
四、那些“小众但实用”的偏方
说点你在别处可能看不到的。
偏方一：用“错误”来迷惑攻击者
这是我从一个游戏公司学来的招数。他们的登录接口被CC攻击，攻击者用脚本遍历用户名密码。他们怎么做的？
在登录接口里加了一个逻辑：如果同一个IP在短时间内失败次数超过阈值，后续的请求依然返回200状态码，但返回的内容是一个错误的JSON结构。
比如正常登录成功返回：
{"code": 0, "token": "xxxx"}对于攻击IP，返回：
{"status": "success", "data": null}攻击者的脚本通常只检查HTTP状态码是不是200，看到200就认为请求成功了，继续下一个请求。但实际上这个响应根本通不过客户端的校验。
这招的妙处在于：消耗攻击者的资源，但不暴露你的防护规则。 攻击者不知道自己是哪里出了问题，只能继续傻傻地打。
偏方二：动态路径+时间戳签名
对于必须实时返回的动态资源（比如验证码图片），可以用这种方式：
// 前端生成一个签名
const timestamp = Math.floor(Date.now() / 1000);
const path = `/captcha/${timestamp}/${md5(timestamp + 'secret_key')}.jpg`;
// 后端验证
// 1. 检查timestamp是否在最近2分钟内
// 2. 重新计算签名是否匹配
// 3. 不匹配就返回404这样每个验证码的URL都是临时有效的，攻击者无法提前构造大量URL来攻击。
偏方三：客户端“指纹”的妙用
别误会，我说的不是获取用户隐私的那种指纹。而是通过JavaScript收集一些浏览器特征：
- 屏幕分辨率
- 支持的字体列表
- WebGL渲染器信息
- Canvas指纹
把这些信息hash一下，作为客户端ID。正常用户的浏览器，这个ID相对稳定；而攻击者用的脚本工具（比如puppeteer、selenium），要么指纹完全相同（批量启动），要么每次都不一样（每次新建实例）。
用这个ID来做频控，比单纯用IP准得多。当然，这招对移动端API不友好，需要酌情使用。
五、最后的大实话
写到这里，我突然想起一个客户问过的问题：“我按你说的都配了，是不是就高枕无忧了？”
我的回答是：没有绝对的安全，只有相对的代价。
分离部署、源站隐藏、高防CDN……这些措施都是在提高攻击者的成本。当攻击你的成本高于攻击别人的成本时，你就相对安全了。
但如果你真的惹到了不差钱的主儿——比如竞争对手铁了心要搞你，或者被黑产团伙盯上了——那再好的防护也可能被攻破。这时候要考虑的就不是“怎么防”，而是“怎么快速恢复”。
所以，除了防护措施，你还得准备：
- 备份源站：随时可以切换的备用服务器
- 切换预案：DNS切换、高防服务商切换的SOP
- 应急联系人：云服务商、安全公司的24小时技术支持电话
这些可能一辈子都用不上，但用上一次，就能救你的业务一命。
行了，不写那么长了。如果你现在还在纠结“要不要分离部署”，那我劝你别纠结了，马上去做。这种基础架构的优化，就像给房子打地基——平时看不出效果，地震来了才知道它的好。
如果你的源站现在还裸奔着……你心里其实已经有答案了，对吧？