CC攻击的本质不是拼带宽，而是拼资源。攻击者用大量看似正常的请求去消耗服务器的CPU、内存、数据库连接和会话资源，当这些资源被恶意请求占满后，真实用户的访问就会变慢甚至完全无法打开。很多网站被打了之后第一反应是买高防IP或者加带宽，但实际效果往往不理想，因为CC攻击的流量可能并不大，每秒几百个请求就能把一个优化不好的动态页面打到瘫痪。真正有效的防护必须从请求特征识别、访问频率控制、动态验证和架构层隔离四个维度同时下手。

先定位CC攻击最容易打穿的位置

绝大多数CC攻击的目标不是静态资源，而是那些需要查询数据库、执行复杂计算或者生成动态内容的URL。比如搜索接口、登录接口、购物车提交、评论提交、验证码刷新、API数据接口。这些页面每一次请求都会触发后端逻辑，攻击者只要持续请求这些高消耗地址，服务器资源很快就会被耗尽。所以防护的第一步是梳理站点里哪些URL属于高消耗资源，把这些地址单独标记出来，针对它们设置更严格的访问策略，而不是对整个站点一刀切。

很多运维人员习惯在Web服务器层做全站限速，结果正常用户访问稍微频繁一点就被误伤。更合理的做法是区分静态资源和动态接口。静态图片、CSS、JS文件可以走CDN缓存，根本不回源，攻击者打这些地址没有意义。动态接口则要单独设置频率阈值，比如同一个IP对登录接口的请求每分钟不能超过10次，对搜索接口每分钟不能超过20次，超过就触发验证或者临时封禁。这个阈值要根据业务实际情况调整，不能照搬别人的数字。

识别真实攻击特征而不是只看IP

传统的CC防护喜欢按IP封禁，但现在的攻击者早就用上了代理池和僵尸网络，一个IP可能只发几十个请求就换下一个，单纯封IP根本追不上。更有效的做法是结合请求头特征、Cookie行为、会话状态和访问路径来识别。真实用户的浏览器会携带完整的User-Agent、Accept、Accept-Language、Referer等头部信息，而很多CC攻击脚本发出来的请求头是缺失或者格式异常的。可以在Web服务器或者WAF层配置规则，对请求头不完整、缺少Referer、User-Agent为空的请求直接拒绝或者跳转验证。

还有一个容易被忽视的特征是Cookie支持。正常浏览器第一次访问网站时会接收并回传Cookie，而很多攻击脚本不处理Cookie，每次请求都是无状态的。可以利用这个差异做一道过滤：对没有携带合法会话Cookie的请求，先返回一个JavaScript跳转或者Set-Cookie响应，要求客户端带上新Cookie再重新请求。能正确执行JavaScript并回传Cookie的基本可以判断为真实浏览器，攻击脚本如果不支持Cookie和JS解析，就会被挡在外面。这种方法对早期CC攻击工具效果很好，但现在一些高级攻击器已经能模拟Cookie和JS执行，所以只能作为第一层过滤，不能作为唯一防线。

频率限制要分层设计，不能只靠单一阈值

有效的频率控制不是简单的“每IP每秒限制多少请求”，而是要设计成多层级、多维度。第一层是IP维度，针对单个IP的请求速率做限制，这个大家都很熟悉。第二层是会话维度，同一个会话ID在单位时间内的请求次数也要限制，防止攻击者通过更换IP但复用同一个会话绕过IP限速。第三层是资源维度，针对某个具体的高消耗URL设置独立阈值，比如某个API接口每分钟最多允许200次请求，超过就返回429状态码或者触发验证码。第四层是全局维度，当整个站点的请求量突然超过正常峰值的数倍时，启动全局限流保护，优先保证核心页面可用，非核心功能降级或者排队。

限速的响应方式也很重要。直接返回403或者封IP容易误伤，而且攻击者发现被封后会立刻切换IP。更平滑的做法是先返回429 Too Many Requests，并在响应头里带上Retry-After字段，告诉客户端多久之后可以重试。对于疑似恶意请求，可以返回一个验证码页面，要求用户完成验证后才能继续访问。验证码可以选用滑块、点选或者计算题，既能挡住大部分自动化攻击，又不会对真实用户造成太大困扰。对于确认是攻击的流量，再考虑在防火墙层做短期封禁，封禁时间设置成递增式，第一次封30秒，第二次封5分钟，第三次封半小时，避免误封正常用户后长时间无法访问。

用缓存和静态化降低动态请求压力

CC攻击之所以能打垮服务器，根本原因是动态请求太消耗资源。如果能把动态内容变成静态内容或者半静态内容，攻击者的请求就不会直接打到后端数据库。对于不频繁变动的页面，比如文章详情页、产品介绍页、列表页，可以生成静态HTML文件或者使用页面缓存，用户访问时直接返回缓存内容，后端程序根本不执行。对于需要实时数据的接口，可以设置短时间缓存，比如5秒或者10秒，同一个请求在这个时间窗口内只回源一次，其余请求直接命中缓存。这样即使攻击者发起大量请求，大部分请求也会被缓存层拦截，真正打到后端的请求量会大幅下降。

缓存策略要结合业务场景来定。像用户个人中心、订单查询这类页面不能简单缓存，因为每个用户看到的数据不同。但可以缓存公共部分，比如页面框架、导航栏、底部信息，只对用户个性化内容做动态加载。对于搜索接口，如果搜索结果变化不频繁，可以对相同关键词的搜索结果做短时间缓存。对于API接口，可以在响应头里设置Cache-Control和Expires，让中间层和客户端也能缓存。缓存层可以放在Web服务器前面，用Nginx的proxy_cache或者专门的缓存服务器来实现，命中率越高，后端压力越小。

部署WAF并配置针对CC攻击的专项规则

Web应用防火墙是CC防护中非常关键的一环。WAF不仅能拦截SQL注入、XSS等攻击，还能通过内置的CC防护模块做智能识别。好的WAF会结合IP信誉库、请求速率、请求特征、行为模型等多维数据来判断一个请求是否属于CC攻击。比如某个IP在短时间内请求了大量不同的URL，但每个URL只请求一次，这种扫描式行为就会被标记。再比如某个IP的请求间隔非常均匀，精确到毫秒级，正常人类操作不可能这么规律，也会被识别为机器人。

配置WAF规则时要注意几个细节。一是要开启会话验证功能，对没有合法会话的请求做JS挑战或者Cookie挑战。二是要配置针对特定URL的精细规则，比如登录接口、注册接口、支付回调接口要设置更低的频率阈值。三是要开启攻击IP自动封禁，但封禁时间要合理，避免误封。四是要定期查看WAF的拦截日志，分析攻击特征变化，及时调整规则。很多攻击者会不断变换手法，WAF规则也要跟着迭代。如果WAF规则长期不更新，防护效果会越来越差。

架构层做隔离和弹性扩容

如果业务本身很重要，不能因为CC攻击就完全不可用，那么架构上必须做隔离和弹性扩容。把静态资源、动态应用、数据库分层部署，静态资源走CDN，动态应用放在负载均衡后面，多台应用服务器同时提供服务。当某台服务器被CC攻击打满资源时，负载均衡可以把它摘掉，由其他服务器继续承接流量。数据库层做读写分离和连接池限制，防止应用层被攻击后拖垮数据库。还可以在应用服务器前面加一层消息队列，把请求先放进队列里，由后端按固定速率消费，超过队列容量的请求直接拒绝。这样即使攻击者发起再多的请求，后端处理速率也是恒定的，不会因为突发流量而崩溃。

弹性扩容在云环境下比较容易实现。可以设置监控告警，当CPU使用率、内存使用率、请求延迟或者错误率超过阈值时，自动增加应用服务器实例。攻击流量过去之后再自动缩容。但弹性扩容只能缓解压力，不能根治问题，如果攻击流量持续不断，扩容成本会非常高。所以弹性扩容要配合前面的识别和拦截手段一起使用，先过滤掉大部分恶意流量，再用弹性扩容应对剩余的正常流量波动。

针对HTTPS CC攻击的特殊处理

现在很多CC攻击走HTTPS协议，因为HTTPS握手本身就要消耗服务器资源，攻击者利用这一点，发起大量TLS握手请求，让服务器在SSL/TLS握手阶段就耗尽CPU。这种攻击比普通的HTTP CC更难防，因为请求还没到应用层，WAF和应用层的限速规则都来不及生效。针对HTTPS CC攻击，需要在负载均衡或者反向代理层做TLS握手限速和连接复用优化。可以限制单个IP的TLS握手速率，超过阈值就拒绝握手。可以开启TLS会话复用，减少重复握手的开销。还可以把TLS终止放在专门的硬件设备或者高性能代理上，让后端应用服务器只处理已经解密后的HTTP请求，减轻后端压力。

另外要注意HTTP/2和HTTP/3协议下的CC攻击。HTTP/2支持多路复用，一个连接上可以同时发送大量请求，传统的基于连接数的限速会失效。需要针对HTTP/2的流做限速，限制单个连接上的并发流数量。HTTP/3基于UDP，传统的基于TCP连接的防护手段完全不适用，需要部署支持HTTP/3的防护设备，在UDP层做流量清洗和连接管理。如果业务暂时不需要HTTP/3，可以在网络层直接禁用UDP 443端口，减少攻击面。

建立监控和应急响应机制

CC攻击的防护不是配置完规则就一劳永逸，攻击者会不断调整策略，防护方也要持续监控和响应。需要在服务器上部署监控，实时采集请求量、响应时间、错误率、CPU负载、内存使用、数据库连接数等指标。当这些指标出现异常波动时，第一时间告警。告警阈值要根据历史数据设定，比如正常时段请求量在每秒500左右，突然涨到每秒2000并且持续超过5分钟，就要触发告警。告警之后要有预定义的应急流程，比如先确认是否真的是CC攻击，再根据攻击特征临时调整WAF规则、增加限速阈值、启用备用服务器等。

日志分析在应急响应中非常重要。攻击发生后，要从WAF日志、Web服务器日志、应用日志中提取攻击源IP、攻击目标URL、请求特征、时间分布等信息，分析攻击手法和规模。这些信息不仅能帮助当前事件的处置，还能用于后续的规则优化。建议把日志集中存储，使用日志分析工具做聚合查询和可视化展示，方便快速定位问题。对于反复出现的攻击源IP段，可以在网络层做长期封禁。对于攻击者使用的特定User-Agent或者请求头特征，可以加入黑名单规则。

不要忽视业务层的防护设计

很多CC攻击利用的是业务逻辑本身的漏洞。比如一个验证码接口，每次请求都会生成一张图片并写入会话，攻击者反复请求这个接口就会消耗大量内存和CPU。再比如一个搜索接口，允许用户输入超长关键词，后端做全文检索时消耗大量资源。这些业务层的问题，光靠WAF和限速是防不住的，需要在代码层面做优化。验证码接口可以加频率限制和过期时间，同一个会话在验证码有效期内不能重复获取。搜索接口可以限制关键词长度，对搜索结果做缓存，对复杂查询做异步处理。登录接口可以增加失败次数限制和锁定机制，防止暴力破解消耗数据库资源。业务层的防护设计要和基础设施层的防护配合起来，才能形成完整的防护体系。

还有一种常见的攻击手法是慢速攻击，攻击者建立连接后以极慢的速度发送请求体或者读取响应，占用服务器连接资源。针对这种攻击，需要在Web服务器上设置请求体超时、响应超时、连接最大存活时间等参数。比如限制请求头必须在10秒内发送完毕，请求体必须在30秒内发送完毕，超过时间就断开连接。同时限制单个IP的并发连接数，防止攻击者用大量慢速连接占满连接池。

CC攻击的防护是一个系统工程，没有单一的技术手段能解决所有问题。需要把请求特征识别、多层级限速、缓存优化、WAF规则、架构隔离、业务层防护和监控响应结合起来，根据实际业务场景灵活调整。防护策略也不是越严格越好，过于严格的策略会误伤正常用户，影响业务转化。最好的防护是在不影响用户体验的前提下，让攻击者的成本远高于收益，让他们觉得打这个站点不划算，自然就会放弃。