服务变慢时，先别急着封禁一批来源地址：带宽饱和和某个页面请求激增，处理方式并不相同。CC攻击与DDoS攻击的识别及防护差异，关键在于判断瓶颈落在网络链路、连接处理还是应用逻辑，再用业务可承受的方式限流。
还要注意，CC并非与DDoS完全互斥的类别。CC通常指针对应用层的高频请求攻击，可能构成应用层DDoS；而DDoS也可能通过网络层或协议层流量造成影响。
先看症状，再判断攻击层次
网络层流量异常，优先看链路和基础设施
如果入口带宽、数据包速率或连接数明显偏离日常峰值，同时多个不同业务入口都受影响，可能是网络层或协议层DDoS。监控中应对照带宽使用率、丢包、连接状态和上游告警；只看网站响应时间，无法判断是否已经发生链路拥塞。
应用请求异常，进一步检查资源消耗
如果带宽未明显打满，但某类页面、搜索或报表请求激增，应用线程、数据库连接或缓存命中情况恶化，应检查应用层攻击的可能性。比较请求路径、方法、状态码、响应耗时及单位请求消耗。相同请求量对静态页面和复杂查询造成的压力可能完全不同。
实务中，可把“网络层攻击”“应用层攻击”“速率限制”“行为分析”作为四类处置线索，而不是简单按流量大小判断。CC攻击与DDoS攻击的识别及防护差异，也要结合服务基线：定时任务、发布活动或用户集中访问都可能造成正常峰值。
按风险由外到内配置防护
- 建立基线：按入口和接口记录正常时段、业务高峰的请求量、响应时间、错误率与资源使用。至少区分静态内容、普通查询和高成本操作；观察周期应覆盖业务自身的日常波动。
- 先保护网络可达性：确认云平台或网络服务商提供的流量清洗能力、告警方式和切换流程。链路已拥塞时，仅在应用服务器上加规则通常无法恢复入口带宽；提前核实防护边界和联络步骤。
- 再控制应用请求：针对登录、搜索等高成本入口设置分级速率限制，结合账号、会话、来源网络和请求特征判断。限制值应依据正常峰值与后端容量压测设定，不能直接套用统一阈值；必要时对可疑请求增加验证码或短时冷却。
- 降低重复计算：对适合缓存的公开内容设置合理缓存策略；为查询设置超时、并发上限和降级方案。缓存不能保护必须实时计算的操作，也不能代替网络侧清洗。
- 小范围验证并留回退：先对少量流量或单个入口启用规则，检查正常用户的成功率、延迟和错误反馈。误伤增加时，缩小规则范围或恢复旧配置，并记录触发原因。
策略要看业务代价
一刀切封禁来源地址实施快，但共享出口、移动网络及代理环境可能让正常用户受影响。行为分析和交互式校验更精细，却会增加系统复杂度或用户操作。静态资源适合优先缓存；关键交易、医疗预约等不能随意拒绝的操作，则应采用更谨慎的分级限流和人工复核机制，不预设所有业务都能接受相同挑战。
处置期间持续观察请求成功率、延迟、资源占用和投诉反馈，并把策略变更与业务事件对照。CC攻击与DDoS攻击的识别及防护差异最终落到同一原则：网络侧缓解拥塞，应用侧压制异常消耗，同时用真实业务基线控制误伤。
常见问题
CC攻击一定属于DDoS吗？
不一定要把两者当作同义词。CC通常描述应用层请求模式；当这类请求由多个来源共同发起并造成拒绝服务时，可以属于应用层DDoS。
只看请求来源地址能识别CC吗？
不能。地址可能共享或变化，应结合请求路径、频率、行为特征和后端资源消耗判断。
限流阈值应该设多少？
没有适用于所有网站的固定值。根据正常高峰、接口成本及压测结果设定，并在小范围启用后持续校正。
应用服务器加机器能解决DDoS吗？
只能缓解部分计算瓶颈。若入口链路已拥塞，扩容应用服务器通常不能替代上游清洗或网络侧处置。