摘要：# 当CC攻击撞上缓存污染：你的网站可能正在“帮倒忙” 我最近帮一个做电商的朋友看他们家的服务器日志，那场面真是……一言难尽。他们刚上了一个大促活动，流量暴涨本来是好事，结果网站慢得像回到了拨号上网时代。技术团队一开始以为是常规的CC攻击，上了高防IP，…

当CC攻击撞上缓存污染：你的网站可能正在“帮倒忙”

我最近帮一个做电商的朋友看他们家的服务器日志，那场面真是……一言难尽。他们刚上了一个大促活动，流量暴涨本来是好事，结果网站慢得像回到了拨号上网时代。技术团队一开始以为是常规的CC攻击，上了高防IP，流量是拦住了，但奇怪的是，后台显示数据库压力一点没减，反而更大了。

排查了半天，最后发现问题出在缓存上——更准确地说，是CC攻击触发了Web缓存污染，而他们之前配置的缓存策略，不仅没帮忙，反而在“助纣为虐”。

这场景你应该不陌生吧？很多团队一遇到CC攻击，第一反应就是上硬防、扩容，但往往忽略了攻击链条里最隐蔽的一环：缓存层。

一、CC攻击怎么就和缓存污染“勾搭”上了？

咱们先不说术语。你可以把CC攻击想象成一场“恶意挤兑”。

正常情况：一个顾客（用户）走进超市（你的网站），拿了一瓶水（请求一个商品页面），收银台（服务器）处理，完成。

CC攻击：雇了1000个人，每个人不停地、只问同一个问题：“矿泉水多少钱一瓶？”（高频请求同一个动态URL）。收银台被这1000个人围得水泄不通，真正想买东西的顾客根本挤不进去。

那缓存污染又是啥？

还是那个超市。为了减轻收银台压力，超市在门口设了个“咨询台”（缓存服务器）。第一个顾客问“矿泉水多少钱？”，店员查了价，告诉他“2块”，并且把这个答案（缓存）记在了小本本上。接下来一段时间，再有人问同样问题，咨询台直接看小本本回答“2块”，就不用再去麻烦收银台了。

问题来了：如果那1000个“恶意挤兑”的人，问的不是“矿泉水多少钱？”（这容易缓存），而是问“穿红衣服、戴眼镜、身高一米七五的店员手里的那瓶矿泉水多少钱？”

这就麻烦了。这个描述（对应的URL参数）极其独特，几乎不会重复。咨询台（缓存服务器）每次都得跑去问收银台（源站）。更糟的是，咨询台的小本本（缓存空间）是有限的，很快就被这些毫无意义、永不重复的“个性化问题” 塞满了。当正常顾客来问“矿泉水多少钱？”时，反而发现小本本上找不到这个简单问题的答案了，因为早就被挤出去了——这就是 “缓存击穿”加“缓存污染”。

说白了，攻击者用海量、带随机参数的请求（比如?uid=随机数），目的就是：

1. 让缓存失效：每个请求看起来都“独一无二”，无法命中缓存，直接回源。
2. 污染缓存池：挤占宝贵的缓存空间，把正常的、热门的缓存条目全部冲刷掉。

很多防护方案PPT上吹得天花乱坠，真遇到这种“组合拳”，如果缓存策略没配好，源站压力反而会不降反增——因为每个恶意请求都“如愿以偿”地打到了数据库上。

二、你的缓存策略，可能正在“裸奔”

我自己看过不少站点的配置，问题往往不是没上缓存，而是配错了。下面这几个坑，你看看中招了没：

1. 缓存键（Cache Key）设计太“老实” 默认配置里，缓存键常常包含完整的URL，包括那一长串查询参数（Query String）。攻击者就是利用这点，在参数里加入随机数（?timestamp=1742xxxxxx），轻松制造海量“唯一”请求，让你的缓存形同虚设。

（私货：很多开源的CMS和框架，默认缓存策略其实挺天真的，根本没想到会有人这么“坏”。）

2. 动态内容无差别缓存 有些页面明明是根据用户登录状态实时变化的（比如“欢迎回来，张三”），你也给它设了个短缓存，比如10秒。攻击者用不同账号疯狂刷这个页面，这10秒的缓存反而成了帮凶——它确实缓存了，但缓存的是无数个不同用户的页面副本，同样快速污染缓存池。

3. 忽略了对“边缘”的防护 现在大家多用高防CDN或云WAF，攻击流量在边缘节点就被清洗了。但你想过没有，如果攻击流量大到足以穿透边缘，或者你的缓存策略在CDN和源站之间的“中间层”（比如Varnish、Redis）上，这里的配置如果没和边缘防护联动，就会成为最脆弱的短板。

三、能落地的缓存策略调整思路（别硬撑）

面对这种局面，低配的、静态的缓存策略真扛不住。调整的核心思路，从“尽量缓存”转向“聪明地缓存，更聪明地不缓存”。

1. 净化缓存键：给请求“脱衣服” 这是最关键的一步。在缓存服务器（如Nginx、Varnish）或CDN配置中，规范化你的缓存键。

• 剥离无关参数：只将决定页面内容的核心参数纳入缓存键。比如商品ID (?id=123)，而忽略追踪参数 (?utm_source=xxx)、随机数 (?_=1742xxxxxx)。
• 示例（Nginx思路）：你可以用 map 或 if 指令（谨慎使用if）来重写请求，将带随机参数的URL归一化到同一个缓存键上。或者更直接点，在CDN控制台直接设置“忽略查询字符串”进行缓存（适用于参数不影响内容的页面）。

2. 区分对待：动态与静态的“分居”策略

• 静态资源（JS、CSS、图片）：直接设置超长缓存（如一年），并加上指纹哈希（文件内容变，文件名也变），这是老生常谈但必须做对。
• 纯动态页面（用户中心、订单页）：要么不缓存，要么仅对未登录用户缓存一个极短的、通用的“登录引导页”。
• 半动态页面（商品详情、文章页）：这是重点。可以缓存一个较长时间（比如5-10分钟），并通过 “边缘计算” （如CDN的Edge Workers）或 “缓存标签” 来实现快速 purging（清除）。当后台更新商品信息时，主动清除该商品的缓存标签，而不是傻等缓存过期。

3. 设置“熔断”机制：保护源站最后一道防线 当监测到异常流量模式（如单一URL参数模式请求激增）时，除了触发CC防护规则外，缓存层应立刻介入：

• 对于被识别为攻击的请求模式，直接返回一个固定的、轻量级的错误页面或验证挑战，并将其缓存一个很短的时间（如2秒）。这样，后续的同模式攻击请求会在边缘命中这个“错误缓存”，而不会继续回源。
• 主动封禁缓存键：临时将攻击者使用的特定缓存键加入黑名单，在一段时间内，所有命中该键的请求都直接返回403或验证码。这招很狠，但对付有明确特征的攻击非常有效。

4. 别忘了监控你的缓存命中率 这就像汽车的仪表盘。你需要实时关注两个指标：

• 边缘缓存命中率：如果突然暴跌，很可能正在遭受参数污染攻击。
• 源站请求数/流量：在开启防护后，如果源站请求数没有明显下降，甚至上升，说明你的缓存/防护策略可能没生效，或者攻击已经绕过了缓存直接打到了源站。

写在最后

防护CC攻击，早就不是堆硬件防火墙那么简单的事了。它已经演变成一场在流量层、应用层、缓存层同时进行的立体攻防。

你的缓存策略，不应该是一份“配置好了就永不更新”的文档。它应该是你安全响应体系中的一个智能部件，能够感知威胁、动态调整。

所以，如果你的源站还在用着两三年前那套缓存配置“裸奔”面对今天的流量，你心里其实已经有答案了。是时候重新审视一下，别让那些本该保护你的缓存服务器，成了攻击者最好的“帮凶”。

行了，不废话了，赶紧去查查你的缓存命中率日志吧。