摘要：# 别让CC攻击拖垮你的网站，Nginx这个“限速器”真能救命 ˃ 很多所谓防护方案，PPT很猛，真被打的时候就露馅了。其实吧，最实在的防护，往往就在你手边。 “网站又卡了？” 上周，我一个做电商的朋友半夜给我打电话，声音里透着绝望。他那小破站，平时…

别让CC攻击拖垮你的网站，Nginx这个“限速器”真能救命

很多所谓防护方案，PPT很猛，真被打的时候就露馅了。其实吧，最实在的防护，往往就在你手边。

“网站又卡了？”

上周，我一个做电商的朋友半夜给我打电话，声音里透着绝望。他那小破站，平时一天就几百个订单，突然涌进来几千个“用户”同时刷商品页面。服务器CPU直接飙到100%，数据库连不上，真用户一个都进不来。他花大价钱买的高防CDN还在配置中，攻击已经持续半小时了。

“你先别急，”我问他，“你用的Nginx吧？现在赶紧登录服务器，改个配置。”

五分钟后，他回电，语气像捡回条命：“流量……好像下来了。”

我没让他买什么昂贵设备，只是让他启用了Nginx里一个被很多人忽略的功能——limit_req模块。说白了，这就是给网站入口装了个“限速器”。

---

01 实战场景，CC攻击到底有多“贱”？

CC攻击（Challenge Collapsar）这玩意儿，跟DDoS那种洪水猛兽不太一样。它不追求带宽打满，专挑你应用层的软肋下手。

想象一下，你开了家小面馆（网站），正常情况同时接待10个客人（并发请求）没问题。突然来了100个人（攻击流量），不点餐，就占着座位反复问“这面多少钱？”、“有啥口味？”（高频请求特定页面）。

你（服务器）得不停回答，后厨（数据库）被无效查询塞满，真正想吃饭的客人（真实用户）根本挤不进来。你的店（网站）从外面看还开着，里面已经瘫痪了。

我见过太多站点，尤其是中小企业的，问题往往不是没上防护，而是配错了。一听说被攻击，第一反应就是买高防、上WAF，钱花了不少，有时候效果还不如一个针对性配置。

02 限流模块，Nginx自带的“看门大爷”

Nginx的limit_req模块，就是个认死理的看门大爷。它的核心逻辑就一条：在规定时间内，同一个“身份”（比如IP）的访问次数，不能超过我设定的数。 超过了？后边排队等着去，或者直接拒之门外。

这个“身份”识别，通常就用客户端IP地址。当然，攻击者可能会换IP（代理池），但那是另一个层面的攻防了。对于大多数低频、小规模的CC攻击，基于IP的限流效果立竿见影。

它的配置语法不复杂，关键在理解几个参数：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

    server {
        location / {
            limit_req zone=one burst=20 nodelay;
        }
    }
}

我拆开说人话：

• limit_req_zone ...：这是定义规则。在内存里划出一块叫“one”的区域（10m大小），用来记录每个IP的访问状态。rate=10r/s是核心速率：每秒只允许10个请求。
• limit_req ...：这是应用规则。在网站的某个位置（比如全站/）启用这个限流。
• burst=20：这是缓冲队列。比如突然来了个瞬间30个请求，前10个正常处理，接下来20个进入队列延迟处理，超过30个的直接拒绝。
• nodelay：这个参数有点意思。不加它，队列里的请求会乖乖排队等；加上它，队列里的请求也会立即开始处理，只是如果队列也满了，就直接拒绝。适合对响应速度要求高、又能承受一定突发的场景。

03 配置陷阱，配错了比不配还糟

我自己看过不少站点，limit_req是配了，但问题一堆。最常见的有两个：

陷阱一：速率（rate）设得太死。

有人一上来就设rate=1r/s（一秒一次），觉得这样最安全。结果呢？正常用户稍微多刷新两下，或者用了个脚本工具，立马被拦在外面。用户体验差到骂娘。

怎么设？ 你得先看看自己网站的正常访问日志。用awk分析一下，真实用户平均每秒从同一个IP发多少个请求。比如一个内容站，用户正常浏览，rate=5r/s到10r/s通常是个安全且宽松的起点。如果是登录接口、验证码接口，那可以设得更严格，比如rate=2r/s。

陷阱二：作用范围（location）乱套。

有些教程图省事，让你直接在server块里全局限流。这可能导致你的静态资源（图片、CSS、JS）也被限速，页面加载变得奇慢无比。

正确的做法是精细化管理：

location /api/ {
    # 对API接口严格限流
    limit_req zone=api_zone burst=5 nodelay;
}

location ~* \.(jpg|png|css|js)$ {
    # 静态资源，放开限制
    expires 30d;
    access_log off;
}

说白了，好钢用在刀刃上。把宝贵的防护规则，精准地用在动态接口、登录页面这些容易被攻击的地方。

04 真实对抗，光有限流还不够？

当然，我必须得说大实话：单靠Nginx限流，防不住专业的、持续的攻击。

如果攻击者手握庞大的代理IP池，轮流来撞你的门，limit_req基于IP的限制就会失效。这时候你会看到，限流规则明明在，服务器还是卡。因为攻击流量被平均分摊到了海量IP上，每个IP的请求频率都“符合规定”。

——这种情况怎么办？

这就是思维断点了。你不能只守着一道门，得建立纵深防御。

第一道防线，还是limit_req，它能过滤掉大部分低端攻击和意外流量。 第二道防线，考虑结合limit_conn模块（限制并发连接数），双管齐下。 第三道防线，上到应用层。比如，对高频访问的IP，弹出验证码（人机验证）。这是让机器流量现原形的最好办法之一。 第四道防线，才是考虑用云WAF或者高防IP，利用它们更大的流量分析和清洗能力，识别并拦截代理IP池。

很多企业犯的错，就是顺序反了。 一上来就买最贵的云WAF，结果自己Nginx的基础配置一塌糊涂，大量正常请求被误杀，防护效果没看到，用户体验和钱先没了。

05 效果监控，你的限流真的在工作吗？

配置完了，扔那儿不管了？那你可能怎么死的都不知道。

你得知道它有没有生效，挡掉了多少请求。Nginx的日志是关键。你需要在limit_req的location里，这样配置日志：

location / {
    limit_req zone=one burst=20 nodelay;
    access_log /var/log/nginx/limit.log main;
    error_log /var/log/nginx/limit_error.log warn;
}

然后在主日志格式里，确保有$remote_addr（客户端IP）和$request_time等字段。定期（比如每天）用脚本分析一下limit.log：

• 有没有同一个IP被大量拒绝（返回503状态码）？那可能是攻击迹象。
• 正常用户的请求延迟有没有明显增加？如果有，说明你的rate或burst可能设得太紧了，需要调整。
• 对比开启限流前后的服务器负载（CPU、内存）、数据库连接数，效果一目了然。

记住，安全配置从来不是“设好就忘”的一次性工作。 它是个动态调整的过程，得跟着你的业务量和攻击态势走。

行了，关于Nginx这个“限速器”就先聊这么多。它不是什么银弹，但绝对是每个运维和开发者工具箱里，最该被熟练使用的基础工具之一。下次再遇到网站突然变卡，别急着重启服务器，先看看日志，说不定调一下这里，就能省下好几万的高防费用。

你的源站，还在裸奔吗？