摘要：# 别让CC攻击拖垮你的服务：用Kong网关“限流”轻松搞定 那天晚上十点多，我正打算关电脑，突然接到一个朋友的紧急电话。他运营的一个在线教育平台，用户登录页面彻底卡死了。后台一看，CPU直接飙到98%，但真实用户数明明没几个。他第一反应是：“是不是被D…

别让CC攻击拖垮你的服务：用Kong网关“限流”轻松搞定

那天晚上十点多，我正打算关电脑，突然接到一个朋友的紧急电话。他运营的一个在线教育平台，用户登录页面彻底卡死了。后台一看，CPU直接飙到98%，但真实用户数明明没几个。他第一反应是：“是不是被DDoS了？” 我让他查了一下日志——好家伙，全是同一个IP在疯狂请求登录接口，一秒几十次。这哪是DDoS，这是典型的CC攻击，专挑你业务里最吃资源的接口，往死里打。

很多刚入行的朋友容易把CC攻击和DDoS搞混。说白了，DDoS是叫一大帮人（肉鸡）堵你家大门，用海量垃圾流量把你带宽挤爆；而CC攻击，更像是一个“精神小伙”，不堵门，但拿着你的门禁卡，在门口那个最精密的指纹识别器上，疯狂地、反复地刷——直到把识别器的CPU给刷烧了。它打的就是你的业务逻辑，消耗的是你的计算资源。

面对这种“精准打击”，很多方案显得有点笨重。你上高防IP吧，成本高，而且对应用层这种“合法”请求的识别有时没那么细。你自己在Nginx里写规则？不是不行，但维护起来挺头疼，规则一多，配置容易乱。

今天，我就聊一个我们团队在不少项目里实际用过的、成本相对低、效果又立竿见影的方案：用Kong网关的速率限制插件来防CC。这玩意儿，真没你想的那么复杂。

一、Kong的速率限制插件：你的“流量阀门”

Kong是个开源的API网关，你可以把它理解为你所有服务入口的“总闸门”和“调度中心”。它的速率限制（Rate Limiting）插件，核心功能就一句话：在指定时间窗口内，限制同一个客户端（比如同一个IP）对你某个接口的请求次数。

这听起来平平无奇，对吧？但对付CC攻击，它恰恰打在了七寸上。

CC攻击者的逻辑很简单：用脚本模拟大量正常请求，在短时间内向你某个接口（比如登录、搜索、提交订单）发起高频调用。你的服务器来不及区分真假，只能老老实实处理，结果资源被耗光，正常用户访问不了。

而Kong的速率限制插件，就在请求到达你真正的业务服务器（源站）之前，把它们拦下了。它在网关层直接计数：这个IP，一分钟内访问/login接口超过60次？后面的请求，直接返回429 Too Many Requests，并告诉你稍后再试。攻击脚本的请求根本到不了后端，你的CPU自然就安静了。

这比你在业务代码里写限流逻辑优雅多了。业务代码只管处理业务，防护的事儿，交给网关这个“专业保安”。

二、实战配置：三步设置，立竿见影

别被“网关”、“插件”这些词吓到，实际操作起来，比你配个Nginx复杂不了多少。假设你已经装好了Kong（用Docker部署是最快的，这里不展开），我们直接看怎么给一个叫/api/login的登录接口上防护。

第一步，创建一个服务（Service）和路由（Route） 这是告诉Kong：“嘿，以后所有访问/api/login的请求，都先到我这儿来报到，然后我帮你转发到后端的真实服务器（比如http://your-backend:8080）。”

# 创建服务（指向你的真实业务后端）
curl -X POST http://localhost:8001/services \
  --data "name=login-service" \
  --data "url=http://your-backend:8080"

# 为上方的服务创建路由（指定匹配的路径）
curl -X POST http://localhost:8001/services/login-service/routes \
  --data "paths[]=/api/login"

到这一步，所有访问 http://你的Kong地址:8000/api/login 的请求，就已经被Kong代理了。

第二步，给这个路由加上速率限制插件 这是核心操作。我们设定：每分钟（60秒），同一个IP地址，最多只能请求60次。超过部分，立即被阻断。

curl -X POST http://localhost:8001/routes/{上一步创建的路由ID}/plugins \
  --data "name=rate-limiting" \
  --data "config.second=60" \
  --data "config.minute=60" \
  --data "config.hour=1000" \
  --data "config.policy=local" \
  --data "config.limit_by=ip" \
  --data "config.fault_tolerant=false"

我来拆解一下这几个参数：

• config.second=60 & config.minute=60：这里我们主要用分钟级限制。minute=60意味着每分钟最多60次。秒级限制（second=60）设得高一些，防止误伤正常用户短时间内连续操作（比如输错密码重试）。
• config.policy=local：用本地内存计数，性能最快。如果你的Kong是集群部署，就得用redis，让所有节点共享计数。
• config.limit_by=ip：按客户端IP来限流。这是防CC最常用、也最直接的方式。攻击脚本通常来自有限的一些IP（即使是代理IP池，单个IP的请求频率也会异常高）。
• config.fault_tolerant=false：这个我建议设成false。意思是如果计数存储（比如Redis）出问题了，宁可错杀，不可放过，直接拒绝请求。在防御状态下，安全优先。

第三步，测试一下 配置完，立刻就能生效。你马上可以用curl或者Postman模拟一下：

# 快速连续请求61次
for i in {1..61}; do curl -I http://localhost:8000/api/login; done

观察返回结果，前60次应该是正常的200 OK或你的业务返回，但从第61次开始，就会看到Kong返回的429 Too Many Requests。这就成了！

三、进阶策略与“坑点”提醒

当然，实战环境比这复杂。直接按IP限流，可能会误伤在同一个NAT出口下的公司或学校用户（他们出口IP一样）。所以，我们得有些进阶玩法：

1. 组合使用“慢速”与“快速”限制 这是我们的一个经验策略。在插件配置里，同时设置一个很严格的秒级限制，和一个相对宽松的分钟级限制。

# 例如
config.second=10   # 每秒不能超过10次，瞬间高频直接掐死
config.minute=100  # 每分钟不超过100次，防持续低频攻击

这样，既能防住那种“脉冲式”的爆发攻击，也能防住长时间、低频率的“慢速CC”。

2. 区分接口，区别对待 别把所有接口的限流值设成一样。像登录、注册、短信验证码这种容易被靶向攻击的接口，限制要严（比如每分钟5-10次）。像文章列表、商品详情这类查询接口，可以放宽些。Kong可以给不同的路由（Route）或服务（Service）单独配置插件，非常灵活。

3. 小心“IP池”攻击 高水平的攻击者会用海量代理IP，每个IP只请求几次，绕过你单IP的限制。这时候，单纯靠limit_by=ip就不够了。你需要：

• 结合WAF：在Kong前面或后面，部署WAF（Web应用防火墙），用更智能的规则识别代理IP、僵尸网络特征。
• 启用Kong的“消费者”标识：如果你的业务有用户体系，可以改为limit_by=consumer，按用户ID来限流，这更精准，但需要你的请求里带上有效的身份令牌（如JWT）。
• 使用“集群”级策略：如果你发现攻击来自某个ASN（自治系统号）或IP段，可以在网络层或防火墙设置黑名单。Kong本身也有ip-restriction插件可以封禁IP段。

4. 别忘了监控和告警 插件配置好了，不是就一劳永逸了。一定要把Kong的日志（尤其是429状态码的日志）接入你的监控系统（比如ELK、Prometheus+Grafana）。设置告警规则，比如“5分钟内429错误数超过1000次”，就马上发短信或钉钉通知你。这样你才能第一时间知道被攻击了，并能评估防护效果。

四、说点大实话：它不能包治百病，但性价比极高

最后，我得泼点冷水。没有任何一个单一方案是银弹。Kong的速率限制插件，主要防的是那种基于请求频率的、比较“愣”的CC攻击。如果攻击者完全模拟正常用户行为，间隔随机，请求参数也随机，那光靠限流可能就有点吃力了。

但是，在绝大多数情况下——尤其是创业公司、中小型项目——它已经能帮你挡掉90%以上的CC骚扰了。它的优势太明显了：

• 成本低：Kong是开源的，除了服务器资源，几乎没有额外成本。
• 见效快：配置简单，改个参数，重启一下插件，防护立刻生效。
• 对业务无侵入：你在网关上做防护，后端业务代码一个字都不用改。

所以，如果你的API服务正在裸奔，或者正在被一些简单的CC脚本困扰，别犹豫了，花上半天时间，把Kong网关和这个速率限制插件搭起来。它可能不是PPT里最炫酷的“AI智能防护”，但绝对是那种“关键时刻真能顶上去”的朴实方案。

行了，关于配置的细节，官方文档写得比我全，你有兴趣可以慢慢啃。核心思路就一点：在攻击流量碰到你业务服务器之前，在网关层就把它掐掉。 这个思路，不管用什么工具实现，都值得你立刻去检查一下自己的系统。

你的源站，还扛得住下一个“精神小伙”的刷接口吗？是时候给大门加把智能锁了。