面对CC攻击，如何通过调整Web服务器参数缓解压力
摘要：# 被CC攻击打懵了？别急着加钱，先调调这几个服务器开关 前几天跟一个做电商的朋友吃饭，他愁眉苦脸地说：“网站最近动不动就卡死，加了两回高防，钱花了不少，效果也就那样。”我让他把访问日志发我看看——好家伙，满屏都是同一个URL的请求，间隔规律得跟秒表似的…
被CC攻击打懵了？别急着加钱，先调调这几个服务器开关
前几天跟一个做电商的朋友吃饭，他愁眉苦脸地说：“网站最近动不动就卡死，加了两回高防，钱花了不少，效果也就那样。”我让他把访问日志发我看看——好家伙，满屏都是同一个URL的请求，间隔规律得跟秒表似的，典型的CC攻击。
他第一反应是“再加点防护预算”，我说你先别急，很多所谓防护方案，PPT很猛，真被打的时候就露馅了。其实像这种针对Web层的CC攻击，你服务器上好几个开关可能压根就没调对，白白浪费了机器性能，让攻击者用最低的成本把你拖垮。
今天咱就聊点实在的：不花一分钱，通过调整Web服务器（以Nginx和Apache为例）的几个关键参数，先扛住第一波，至少别让那些“低配版”攻击轻易得手。
先搞明白：CC攻击到底在“打”你哪里？
说白了，CC攻击不像DDoS那样猛灌流量，它更像一种“使绊子”的阴招。攻击者控制一堆“肉鸡”（或者干脆就是便宜的代理IP），模拟正常用户不停地访问你网站上最耗资源的页面——比如动态搜索页、登录接口、数据提交页面。
你的服务器每处理一个这样的请求，都要走一遍“接客-查数据库-渲染页面-送客”的完整流程。攻击者要的就是这个效果：用大量看似合法的请求，把你的CPU、内存、数据库连接这些资源一点点磨光。真正的用户这时候点进来，要么排队等半天，要么直接被拒绝服务。
所以，缓解的核心思路就一条：用最小的资源消耗，尽快识别并扔掉那些“假请求”，把资源留给真人。
Nginx：这几个参数调好了，能挡掉一大半“小打小闹”
Nginx现在是绝对的主流，咱们重点说它。很多默认配置是为了兼容性，防御力上基本是“裸奔”。
1. 限制单个IP的连接数与请求速率——这是第一道门栓
你想想，一个正常用户，一秒内能刷新多少次页面？攻击IP可就不一样了，一秒能发几十上百个请求。在Nginx的 http 或 server 区块里加上这些：
limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
server {
location / {
limit_conn addr 20; # 每个IP同时最多20个连接
limit_req zone=one burst=20 nodelay; # 每秒最多10个请求，允许突发20个
}
}rate=10r/s 意思是每秒最多处理来自同一IP的10个请求，burst=20 是允许一定程度的突发（比如用户正常刷新），超过的直接返回503错误。这个值设多少，得看你实际业务。一个资讯站可以设严点，秒杀页面就得设宽点，不然把真实用户也拦了。
2. 给动态请求“上锁”，静态资源“放行”
攻击者最爱打动态接口（像 /api/login, /search?q=），因为最耗资源。我们可以区别对待：
location ~ \.(php|jsp|cgi|do|asp)$ {
# 对动态脚本应用更严格的限制
limit_req zone=one burst=5 nodelay;
proxy_pass http://backend;
}
location ~* \.(jpg|gif|png|css|js)$ {
# 静态资源，过期时间设长点，让浏览器和CDN缓存
expires 30d;
access_log off; # 甚至可以关闭日志，减轻磁盘压力
}说白了，就是好钢用在刀刃上。把宝贵的连接数和CPU计算，优先留给真正的动态请求。
3. 调大超时时间？不，你可能做反了！
很多人一遇到慢，就想着把 keepalive_timeout、client_body_timeout 这些参数调大。这其实是帮了攻击者的忙。攻击者会故意建立连接然后不发数据，耗着你的资源。
正确的思路是：在不影响正常用户体验的前提下，尽可能地调短。
keepalive_timeout 15s; # 保持连接时间，别设太长
client_header_timeout 10s; # 客户端发请求头的超时
client_body_timeout 10s; # 客户端发请求体的超时
send_timeout 10s; # 服务端响应的超时设短一点，让“磨洋工”的连接尽快被掐断。
Apache：老当益壮，关键模块要用起来
如果你还在用Apache，核心思路也一样，主要通过 mod_evasive 和 mod_ratelimit 这类模块来实现。
1. mod_evasive：专治各种“请求轰炸”
这个模块简直就是为CC防御而生的。配置大概长这样：
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2 # 同一页面每秒请求阈值
DOSSiteCount 50 # 全站每秒总请求阈值
DOSPageInterval 1 # 页面计数间隔
DOSSiteInterval 1 # 全站计数间隔
DOSBlockingPeriod 10 # 封禁时间（秒）
</IfModule>意思是，如果同一个IP对某个特定页面每秒请求超过2次，或者对你的网站整体每秒请求超过50次，就封它IP 10秒。这数字非常激进，适合被打懵时的紧急止血，平时要调松一些。
2. 优化MaxClients和KeepAlive
Apache一个进程处理一个连接。MaxClients 决定了你的并发处理能力。设得太低，容易满；设得太高，内存扛不住。一个粗略的算法是：MaxClients ≈ 总内存 / 单个Apache进程平均占用内存。自己用 ps 命令查一下，别拍脑袋。
KeepAlive On 是好东西，能让一个TCP连接处理多个请求。但遇到攻击时，可以暂时 KeepAlive Off，虽然会增加用户建立连接的开销，但能有效防止攻击者占着连接不放。
重要提醒：这些“土办法”的局限在哪？
坦率讲，上面这些服务器参数调整，属于 “修修补补”的防御。它能帮你：
- 缓解低流量、慢速的CC攻击。
- 为部署更专业的WAF或高防服务争取时间。
- 优化服务器性能，避免被自己糟糕的配置拖垮。
但是，它搞不定：
- 海量IP的低速攻击：每个IP都守规矩，但总量巨大。
- 高级的模拟攻击：完全模仿真人浏览轨迹，参数调整很难区分。
- 大规模流量攻击：已经超出服务器本身处理能力。
如果你的源站IP已经暴露，并且持续被大规模攻击，那么调参数就像是用脸盆去舀一艘漏水的船——有必要，但救不了命。 这时候，你必须考虑真正的“源站隐藏”，也就是把网站放到高防CDN或高防IP后面，让攻击流量在云端就被清洗掉，打不到你的真实服务器。
最后说句大实话
安全防护，很多时候就是一个“成本博弈”。攻击者在找最便宜的方式打垮你，你也要找最具性价比的方式防御。一上来就买最贵的高防，可能是一种浪费；但一味只靠调参数硬扛，也可能因小失大。
我的建议是：把这些参数调整作为你的“标准出厂设置”，就像给服务器穿上基础防弹衣。然后，根据你业务的敏感程度和遭受攻击的实际情况，再决定要不要上“重装甲”（专业防护服务）。
至少，下次再遇到网站卡顿，别只会重启服务器了。先翻翻日志，看看是不是该紧紧服务器上的这些“螺丝”了。