Linux服务器被CC攻击怎么处理？Nginx封IP教程

CC攻击本质是高频、伪装性强的HTTP请求洪峰，单纯靠Nginx静态封IP（如deny指令）几乎无效——攻击者利用海量代理或肉鸡轮换IP，且deny发生在请求处理后期，早已耗尽服务器资源；真正有效的防御体系需分层协同：以Nginx原生limit_req在请求早期内核级限流为第一道防线，结合map动态识别恶意路径与UA实现智能流量区分，再通过fail2ban实时解析日志并调用iptables精准封禁，最终将防护压力从应用层前移到网络与协议层，但必须清醒认识到，再完善的配置也无法替代业务层的风控逻辑（如人机验证、行为分析），因为真实浏览器集群攻击与突发合法流量的边界，永远需要应用自己来定义和守护。

CC攻击不是靠“封IP”就能解决的，Nginx本身没有内置防火墙，所谓“Nginx防火墙”实际是靠限流 + 拒绝响应 + 外部工具协同实现的。直接在 nginx.conf 里写 deny 规则对真实CC几乎无效——攻击者用的是代理池或肉鸡，IP每秒换，硬封等于白忙。

为什么 deny 和 allow 在CC场景下基本没用

这些指令只在 http、server 或 location 块中生效，属于静态访问控制，不感知请求频率、User-Agent异常、Cookie缺失等CC典型特征。更关键的是：deny 发生在请求处理后期，Nginx 已完成连接建立、SSL握手、header解析——攻击流量早已吃满 worker 连接和 CPU。

• 单个IP每秒发100个请求？deny 1.2.3.4 顶多拦住这一个IP，但CC通常来自上千个不同IP
• 攻击者用 Selenium、headless Chrome 模拟真实浏览器？deny 完全无法识别
• 你手动查日志封IP，速度远低于攻击发起速度，tail -f access.log | grep "POST /login" | awk '{print $1}' | sort | uniq -c | sort -nr 查出来时，这批IP可能已切换

真正有效的第一道防线：用 limit_req 控制单IP请求数

这是 Nginx 原生命令，内核级限流，开销极低，且在请求早期（解析完 header 后、进入 location 前）就触发。必须配合 limit_req_zone 定义共享内存区域，否则会失效。

http {
    # 定义限流区域：以 $binary_remote_addr（压缩后的IP）为key，10m内存约存16万IP
    limit_req_zone $binary_remote_addr zone=cc_limit:10m rate=10r/s;
<pre class="brush:php;toolbar:false;">server {
    location / {
        # 突发允许最多5个请求，超过即503；nodelay可改为burst=5 delay=1
        limit_req zone=cc_limit burst=5 nodelay;
        proxy_pass http://backend;
    }
}

}

• rate=10r/s 是关键阈值：正常用户点页面不会每秒刷10次，但CC脚本轻松做到100+，这里先卡死量级
• 别用 $remote_addr，它未标准化，IPv6下可能出错；$binary_remote_addr 更稳定、省内存
• 如果后端是 API 接口（如 /api/v1/submit），应单独配更严策略：rate=2r/s burst=1
• 注意：该限流对 HTTPS 的 SNI 阶段无影响，但能有效压低后续 HTTP 请求洪峰

进阶防御：用 map + limit_req 区分正常流量和可疑行为

纯按 IP 限流会误伤 NAT 用户（比如整个公司出口是一个IP）。更合理的方式是结合请求特征动态打标，再限流。

http {
    map $request_uri $is_cc_path {
        ~*"/wp-login.php|/xmlrpc.php|/phpmyadmin" 1;
        ~*"\.(php|jsp|asp)\??.*"                    1;
        default 0;
    }
<pre class="brush:php;toolbar:false;">map $http_user_agent $is_bad_ua {
    ~*(python-requests|curl|httpie|Go-http-client) 1;
    ~*(HeadlessChrome|PhantomJS|Node-fetch)       1;
    default 0;
}

limit_req_zone $binary_remote_addr$host$is_cc_path$is_bad_ua zone=smart_cc:10m rate=3r/s;

server {
    location / {
        limit_req zone=smart_cc burst=2 nodelay;
        proxy_pass http://backend;
    }
}

}

• map 指令必须在 http 块顶层定义，不能放在 server 内
• 匹配逻辑是“或”，所以把高危路径和恶意 UA 合并进同一个 limit_req_zone key，让它们共用额度
• 不要过度依赖 User-Agent 过滤——高级CC会伪造 Chrome UA，但它很难同时伪造 Referer、Accept-Language、Cookie 等字段
• 这个方案仍无法防住真实浏览器集群攻击，需配合下一环

必须搭配系统层工具：用 fail2ban 抓日志+封禁到 iptables

Nginx 只能限流，真要阻断连接，得让内核丢包。fail2ban 是唯一被广泛验证的方案：它监控 access.log，匹配规则后调用 iptables 或 nftables 封禁源IP，且支持自动解封。

• 安装后，编辑 /etc/fail2ban/jail.local，添加自定义 jail：

[nginx-cc]
enabled = true
filter = nginx-cc
logpath = /var/log/nginx/access.log
maxretry = 30
findtime = 60
bantime = 3600
action = iptables[name=nginx-cc, port=http,protocol=tcp]

• 再新建 /etc/fail2ban/filter.d/nginx-cc.conf，写精准正则（例如匹配1秒内10个 POST）：

[Definition]
failregex = ^<host> -.*"(POST|GET).*HTTP.*" 200 .*
ignoreregex =</host>

• 关键点：findtime 和 maxretry 要根据业务调整——电商秒杀期间可能天然高并发，不能照搬默认值
• 封禁走 iptables 比 ipset 更通用，但若 IP 量超5000，建议改用 ipset 避免规则膨胀
• 务必确认服务器开启了 net.ipv4.conf.all.rp_filter=1，否则伪造源IP的SYN Flood可能绕过 iptables

真正的难点不在配置，而在于区分“攻击流量”和“突发合法流量”。比如发布会开抢、微博热搜导流、爬虫合规采集——它们的表现和CC高度相似。没有银弹，limit_req 是底线，fail2ban 是兜底，中间那层业务特征分析（如登录频次、Token有效性、JS挑战）必须由应用自己承担。

以上就是《Linux服务器被CC攻击怎么处理？Nginx封IP教程》的详细内容，更多关于的资料请关注golang学习网公众号！