个人网站免费CC攻击防御优化技巧

个人网站遇到CC攻击时，最典型的特征不是带宽跑满，而是服务器CPU和数据库连接数短时间内飙升，网站响应从几百毫秒退化到十几秒甚至直接宕机。CC攻击的本质是消耗服务器资源，而不是消耗带宽，所以很多免费防御手段如果只盯着流量清洗，往往效果很差。真正有效的免费策略，是把防御重心放在“降低单次请求成本”和“拦截异常流量特征”上。

先明确一个前提：免费防御无法对抗超大流量CC，但足以应对绝大多数针对个人网站的脚本攻击、小型CC和扫描器发起的资源消耗。个人站长要做的不是追求完美防御，而是让攻击成本高于攻击者收益，同时保证正常访客几乎无感。

很多站长一看到CPU升高就以为是CC，其实可能是搜索引擎蜘蛛抓取过频、插件死循环或者数据库慢查询。判断方法很简单：查看服务器当前并发连接数，如果正常时段并发在50以下，突然长时间维持在300以上且访问的都是同一个URL或几个URL，基本可以判定为CC。再结合日志分析，如果大量请求来自相同User-Agent、相同IP段或者请求间隔极短，特征就更明显。

确认之后不要急着上防护，先把服务器基础配置做对。很多个人网站被“打死”不是因为攻击多强，而是因为服务器本身配置太脆弱。

如果你用的是Nginx，有两个模块必须配置好：limit_req和limit_conn。limit_req用于限制请求速率，limit_conn用于限制并发连接数。下面是一段可直接使用的配置示例：

http {
    limit_req_zone $binary_remote_addr zone=req_one:10m rate=30r/s;
    limit_conn_zone $binary_remote_addr zone=conn_one:10m;

    server {
        location / {
            limit_req zone=req_one burst=50 nodelay;
            limit_conn conn_one 20;
        }
    }
}

这段配置的含义是：每个IP每秒最多30个请求，允许突发50个，超过后直接返回503；每个IP同时最多保持20个连接。对于个人博客或小型站点，这个阈值足够正常用户使用，而脚本攻击通常每秒会发起上百次请求，会被立即拦截。

Apache用户可以用mod_evasive或mod_qos实现类似效果。mod_evasive配置简单，能自动封禁短时间内大量请求的IP，但需要注意误伤共享IP的访客，所以封禁时间不宜设置过长，建议60秒到300秒之间。

Cloudflare免费版虽然不提供高级WAF规则，但已经具备几个非常实用的CC防御能力。首先开启“Under Attack Mode”，这个模式会对所有访问者启用JavaScript挑战，能过滤掉大部分不执行JS的脚本攻击。不过这个模式会影响用户体验，建议只在攻击发生时临时开启。

更精细的做法是在Cloudflare的WAF自定义规则里，利用免费额度创建5条规则。针对CC攻击，可以设置：当请求速率超过阈值时进行质询或阻止。免费版虽然不能直接使用速率限制规则，但可以通过“Security Level”和“Bot Fight Mode”来降低攻击流量。Bot Fight Mode能拦截已知的恶意爬虫和自动化工具，对脚本型CC有不错的效果。

还有一个容易被忽略的免费功能是“Page Rules”。你可以针对被攻击的URL设置“Cache Everything”，让边缘节点直接返回缓存内容，请求根本不会到达源站。如果攻击的是动态页面，可以设置“Bypass Cache on Cookie”，让带有正常登录Cookie的用户回源，而匿名攻击流量被缓存层吸收。

如果攻击流量已经到达服务器，系统防火墙是最后一道免费防线。Linux下使用iptables或firewalld，可以根据IP、端口、连接数进行限制。例如用iptables限制单个IP对80端口的并发连接：

iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 30 -j DROP

这条规则会直接丢弃单个IP超过30个并发连接的请求。对于个人网站来说，正常浏览器访问一个页面通常只会建立4到8个连接，30个并发已经非常宽松。

如果攻击源IP比较集中，可以直接用脚本从日志中提取高频IP并批量封禁。一个简单的Shell脚本思路是：分析最近5分钟日志，统计每个IP的请求次数，超过阈值的加入临时黑名单，定时清理。但要注意，如果攻击者使用大量代理IP，这种方法效果有限，而且手动封禁容易误伤。

CC攻击之所以能拖垮服务器，很大程度上是因为动态请求太“重”。一个普通的WordPress页面可能触发几十次数据库查询，如果攻击者直接请求动态页面，服务器很快就会耗尽资源。免费防御的核心思路之一，就是把动态请求尽量静态化。

对于WordPress用户，安装缓存插件是最有效的免费手段。WP Super Cache或W3 Total Cache可以把动态页面生成静态HTML文件，攻击请求命中静态文件时，Nginx或Apache直接返回文件内容，完全不经过PHP和数据库。即使攻击流量很大，只要磁盘IO和带宽没被打满，服务器就不会宕机。

如果不想用插件，也可以在Nginx层面配置FastCGI缓存。下面是一段简单的FastCGI缓存配置：

fastcgi_cache_path /tmp/nginx_cache levels=1:2 keys_zone=MYCACHE:10m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

server {
    location ~ \.php$ {
        fastcgi_cache MYCACHE;
        fastcgi_cache_valid 200 301 302 10m;
        fastcgi_cache_bypass $cookie_PHPSESSID;
        fastcgi_no_cache $cookie_PHPSESSID;
        include fastcgi_params;
    }
}

这段配置会把PHP返回的200、301、302响应缓存10分钟，带会话Cookie的请求不缓存，这样登录用户不受影响，匿名攻击流量则直接命中缓存。

除了Cloudflare，还有一些免费CDN服务商提供基础防护能力。但要注意，免费CDN通常节点有限，防御能力也有限，更适合作为辅助手段。如果你的域名DNS支持分线路解析，可以把攻击流量导向一个专门的“防御域名”，正常流量走主线路，但这需要一定的技术操作。

更实用的做法是利用DNS的TTL设置。在攻击发生前，把TTL设置得短一些，比如300秒，这样切换解析时生效更快。如果网站被打到完全无法访问，可以临时把域名解析到一个静态页面或者第三方托管页面，保证品牌展示不中断。

个人站长最容易忽略的是日志的价值。CC攻击发生时，日志里往往有明显的规律：某个URL被反复请求、某个User-Agent出现频率异常、某个IP段集中访问。通过分析日志，可以快速定位攻击特征，然后针对性地写规则拦截。

例如，如果发现攻击请求的User-Agent都是“python-requests/2.25.1”，可以在Nginx里直接拒绝：

if ($http_user_agent ~* "python-requests") {
    return 403;
}

如果攻击请求都带有一个特定的GET参数，可以用类似方式拦截。这种基于特征的拦截非常精准，几乎不会误伤正常用户。

更进一步，可以写一个简单的监控脚本，每分钟检查服务器负载和连接数，当超过阈值时自动执行预设的防御命令，比如开启更严格的限速、临时封禁高频IP、或者调用Cloudflare API切换到Under Attack模式。这种自动化响应能让个人网站在无人值守时也能快速应对攻击。

个人网站资源有限，不可能像企业站那样部署多层防护。但有一个思路值得考虑：把静态资源和动态请求分离。静态资源（图片、CSS、JS）可以放在免费的静态托管服务上，源站只处理动态请求。这样即使源站被打，静态资源仍然可以正常加载，而且攻击流量不会消耗源站的带宽和IO。

另外，如果网站有评论、搜索等功能，这些功能往往是资源消耗大户。在攻击期间，可以临时关闭这些功能，或者给它们加上验证码。一个简单的数学验证码就能挡住大部分自动化脚本。

第一个误区是以为加了CDN就万事大吉。CDN只能挡住直接攻击源站的流量，如果攻击者找到了源站的真实IP，CDN就形同虚设。所以源站IP一定要保密，不要用源站IP直接访问网站，也不要让邮件服务暴露源站IP。

第二个误区是盲目封禁IP。CC攻击经常使用代理池，封禁单个IP意义不大，而且可能误伤正常用户。更好的做法是基于行为特征进行拦截，而不是基于IP。

第三个误区是只防不备。很多站长在攻击结束后就不管了，下次攻击来临时又手忙脚乱。建议把防御配置写成文档，把常用命令保存成脚本，这样下次可以快速部署。

个人网站免费CC防御的核心逻辑是：先优化服务器基础配置，降低单次请求成本；再利用免费CDN和防火墙规则过滤异常流量；最后通过日志分析和自动化脚本实现快速响应。这套组合拳虽然不能对抗大型攻击，但足以让绝大多数个人网站在小型CC攻击中存活下来，而且几乎不需要额外成本。