CC攻击和靠打满带宽实现效果的DDoS攻击有明显区别。它不是依靠海量流量硬冲服务器，而是模拟普通用户行为，反复调用资源消耗量大的页面接口。搜索接口、登录校验、购物车结算这类接口，每接收一次请求，服务器都需要查询数据库、执行业务逻辑、拼装页面内容。攻击者会调用大量代理IP或者肉鸡节点，单个IP只发送少量请求，从访问特征看接近正常用户访问，但累积请求总量很大。最后服务器CPU满载、数据库连接数耗尽，真实用户反而无法正常访问站点。
想要抵御这类攻击，首要思路就是不要把源服务器直接暴露在公网。域名解析指向CDN节点或者高防IP，用户访问请求先抵达CDN，真实服务器IP隐藏在后方。攻击流量会先经过CDN，CDN自带带宽清洗能力，可以拦截一部分攻击请求。CDN还能缓存图片、CSS、JS这类静态资源，这类资源访问不用回源，源站压力会下降。不过动态请求依旧需要回源处理，CDN不能做到完全防护。
WAF属于第二层防护，可以选用云WAF或是自行部署ModSecurity。它能够识别常见攻击特征，例如异常User-Agent、短时间重复访问同一URL、请求参数携带异常字符。配置防护规则不能过于死板，部分正常用户访问也会出现空User-Agent，一刀切的策略容易误伤真实访客。可以单独针对登录、搜索、表单提交接口配置限制策略，举例：同一个IP一分钟请求超过20次触发验证码，请求超过50次直接封禁十分钟。
频率限制是很直接的防护手段。Nginx可借助limit_req模块，基于IP或者会话维度限制请求速率。例如设置单个IP每秒最多5次请求，突发请求上限10次，超出阈值返回503状态码或者排队等待。阈值需要结合自身业务情况调试，设置过严会拦截正常用户。还可以区分不同URL单独配置，首页、静态资源放宽限制，搜索和登录接口收紧限制条件。
人机验证放在关键访问入口效果不错，登录、注册、发帖、下单页面，配置滑块或者点选类验证码。不需要对每一次访问都触发校验，只在IP或者会话行为异常的时候弹出验证。像是同一个IP短时间切换多个账号访问，或是请求间隔非常规律，符合脚本定时访问特征，就触发验证机制。验证码服务本身要保证稳定性，避免攻击还没挡住，验证码服务先宕机。
单纯依靠IP做判断有局限，行为分析方案效果更好。CC攻击请求一般具备固定特征：只访问少数指定URL、不会加载图片CSS资源、Cookie为空、缺少Referer、请求头顺序和真实浏览器不一致。把多项特征组合做风险打分，高分请求先限速，分数继续升高直接拉黑。不少云防护平台内置机器学习模型，不用自己从零编写规则。但要做好白名单配置，防止误拦截搜索引擎爬虫、第三方API调用服务。
缓存与页面静态化，可以从根源减少动态请求数量。变动频率低的页面生成静态HTML文件，或者用Redis缓存数据库查询结果。攻击者持续发起请求，服务器直接读取缓存返回内容，不用反复查询数据库。必须动态处理的接口，可以引入消息队列削峰，请求先进入队列排队，后端依照自身负载消费任务，防止瞬时流量击穿数据库。
负载均衡搭配弹性扩容作为兜底方案。前端部署多台服务器，通过Nginx或者云负载均衡分摊访问流量。如果使用云服务器，可以配置自动伸缩策略，CPU使用率超过70%自动新增实例。但扩容操作存在时间消耗，攻击流量爆发速度快的时候，新增机器来不及上线。所以还是要依靠前置流量清洗、请求限速扛住第一波攻击。
监控告警环节不能省略。日常持续观测QPS、页面响应耗时、CPU使用率、数据库连接数指标。设置告警阈值，比如QPS突然翻倍，或是502错误占比超过5%，触发短信、钉钉告警。一旦遭受攻击，管理人员可以第一时间收到通知，而不是等到用户反馈故障。应急处置阶段，可以临时切换至高防清洗中心，或是修改域名解析指向备用IP，转移攻击流量。
还有一处容易忽略的服务器参数。Linux系统默认somaxconn和文件描述符上限偏小，攻击发生时连接数很容易打满，正常请求连TCP握手都无法完成。适当调整ulimit以及sysctl相关参数，可以让服务器承载更多并发连接，争取更多处置时间。
大规模CC攻击场景，单台服务器或者简单规则无法独立抵御。CDN、WAF、请求限速、人机验证、缓存、弹性扩容多层防护需要协同生效。平时做好日志留存与监控，攻击发生时才能定位瓶颈，针对性调整防护规则。不存在永久有效的防护方案，只能结合网站业务特性持续调试优化。