一、混淆的源头：为什么需要区分DoS和CC？
验证与回滚
关于DoS L3，最值得先弄清楚的是配置边界和排错顺序。当你的网站突然无法访问，运维群里有人喊“被DDoS了”时，80%的情况可能是应用层CC攻击，而不是传统意义上的大流量DDoS。但很多人用“DDoS”一词泛指所有拒绝服务攻击，导致排查方向完全错误。
你可能遇到过这样的场景：服务器CPU飙升到100%，但带宽监控显示流量只有几十Mbps；或者网络入口丢包严重，但后端服务器负载几乎为零。这两种现象分别指向两类不同的攻击——应用层CC攻击（L7）和网络层DoS（L3/L4）。面向小白的核心认知：攻击发生的“层次”决定了它们如何消耗资源，也决定了应该如何进行清洗。
DoS L3：二、网络层DoS（L3/L4）：洪水堵门，靠流量压垮带宽
2.1 它攻击什么？
网络层DoS攻击的目标是带宽和网络设备。攻击者伪造大量IP包，向你的服务器发送海量数据，比如SYN Flood、UDP Flood、ICMP Flood等。这些数据包在第三层（网络层）或第四层（传输层）就消耗掉了服务器的网络接口、路由器、交换机以及防火墙的会话表资源。一旦带宽被打满，正常的用户请求无法进入。
2.2 典型特征
- 服务器带宽监控出现异常尖峰，可能从几Gbps飙升至几百Gbps甚至Tbps级别。
- 网络连接数暴涨，但服务器CPU/memory相对正常（如果没被流量打满交换机）。
- 业务完全不可达，ping超时或丢包率极高。
2.3 中小型网站的“躺枪”
对于单机部署的小站点，一次10Gbps的SYN Flood就能让服务器网卡瘫痪。但中大型云端Web系统通常有较高入带宽（比如10Gbps～100Gbps），且具备DDoS高防清洗能力。所以网络层攻击对于中大型系统更多是“流量冲顶”风险，需要在前端清洗中心或运营商层面进行流量丢弃。
三、应用层CC攻击（L7）：伪装成正常请求，耗尽应用资源
3.1 它攻击什么？
CC攻击（Challenge Collapsar）属于应用层攻击，攻击者模拟真实用户的HTTP请求，发送大量看似正常的GET/POST请求，比如频繁查询数据库、触发耗时计算、模拟登录等。这些请求从协议栈角度看完全合法，所以防火墙和传统DDoS清洗设备很难直接丢弃。CC攻击的目标在于耗尽Web服务器的CPU、内存、数据库连接池或者缓存资源，使其无法处理真实用户的请求。
3.2 典型特征
- 带宽使用正常或只有小幅增加（通常远低于网络层攻击）。
- Web服务器CPU持续飙高，或者慢查询增多。
- 网页响应变慢或出现502/503错误，但ping仍然正常。
- 日志中出现大量来自不同IP的相同URL请求，请求间隔极短。
3.3 为什么CC攻击更难清洗？
因为攻击流量与正常流量混合在一起，没有明显的“洪水”特征。如果直接丢弃所有来自某个IP的请求，可能会误伤正常用户。而且攻击者可以使用代理池或僵尸网络，每个IP只发少量请求，总量却巨大。这需要比网络层攻击更精细的检测手段，比如基于行为分析、请求频率、页面访问模式等。
关联教程：此处可内链到“DoS L3部署与验证”内容。
延伸阅读：此处可内链到“DoS L3配置案例”相关文章。
四、分层清洗设计：成体系地拆解攻击
中大型云端Web系统通常采用多层架构：CDN缓存层、负载均衡层、应用服务器层、数据库层。每一层都有不同的抗攻击能力。分层清洗的核心思想是：在最合适的位置，用最合适的方法，拦截不同层次的攻击，而不是试图用一个设备搞定所有。
4.1 第一层：网络层清洗（L3/L4）—— 挡洪水
在云端基础设施入口部署DDoS高防清洗中心或云服务商提供的Anti-DDoS服务。这一层专门处理大流量攻击：SYN Flood、UDP Flood、ACK Flood等。清洗中心通过流量整形、源验证（如SYN Cookie）、黑白名单、限速等方式，将恶意流量在进入你的前置网络之前丢弃。对于中大型系统，建议采用≥Tbps级别的清洗能力，并配置自动触发阈值。例如：当入带宽超过总带宽的70%时，自动启用更激进的清洗策略。
关键点： 网络层清洗只关注包特征，不解析内容，因此对CC攻击几乎无效。
4.2 第二层：边缘节点/反向代理层（L4/L7）—— 减量
经过第一层清洗后，流量的体积已经大幅下降，但可能仍包含大量CC攻击请求。此时可以在反向代理（如Nginx、Envoy、Cloudflare、GoEdge等）上设置第二道防线。
- 启用连接速率限制：每个IP每秒最多允许建立多少个TCP连接，或多少请求。
- 启用IP/UA/Referer黑名单：快速拦截已知恶意来源。
- 启用静态页面缓存：对频繁请求的静态资源（CSS/JS/图片）直接返回缓存，减少后端压力。
- 启用挑战机制：对可疑来源进行JavaScript挑战或验证码，这是对抗CC攻击的有效手段。
这一层需要注意业务特性。比如API接口不能完全缓存，因此需要更精细的规则：对登录、下单、查询等接口采用不同的限速阈值。
4.3 第三层：应用服务器层（L7）—— 精细过滤
经过前两层，大部分恶意流量已被移除，但可能有少量“高质量”CC请求穿透（比如来自真实登录用户的恶意行为，或攻击者绕过CDN直接打到源站IP）。在应用服务器（Tomcat/PHP-FPM/Python uWSGI等）层面，可以通过WAF（Web应用防火墙）或自定义中间件进行更深入的分析：
- 会话行为分析： 记录每个用户的访问路径，如果发现异常跳跃（例如直接访问支付页面而没有浏览商品页），则视为可疑。
- 接口调用频率检测： 结合用户身份（JWT/Token）做限流，超过阈值则返回429 Too Many Requests。
- 动态屏蔽： 当检测到同一IP反复触发敏感接口时，临时将其加入黑名单并通知第二层反向代理同步。
这一层通常需要与应用逻辑结合，因此实现成本较高，但对攻击的识别准确率也最高。
4.4 第四层：基础架构弹性伸缩 —— 被动承受
即使前三层做了最好的防护，仍有漏网之鱼。靠弹性伸缩（自动扩容）可以在短时间内支撑突发流量而不会完全崩溃。比如Kubernetes HPA根据CPU/请求数自动增加Pod副本；云数据库自动增加只读实例分担读压力。注意：弹性伸缩不能替代清洗，只能延缓“被击垮”的时间，让你有足够的时间手动介入调整策略。同时，弹性伸缩会带来成本增加，需要设好上限。
五、分层清洗的协同原则
故障定位思路
真正有效的分层清洗，各层之间不能是孤立的。推荐以下协同策略：
- 阈值级联： 第三层发现某IP恶意，应主动通知第一层或第二层进行更早的丢弃，避免后续流量继续消耗资源。
- 统一日志中央分析： 将CDN、WAF、负载均衡、应用服务器的日志汇总到SIEM系统，用机器学习模型识别攻击模式，动态调整各层规则。
- 回滚预案： 任何清洗策略都可能误伤正常流量。必须预留“白名单”机制，比如对已知的API调用方、爬虫、合作伙伴IP放行，并且能在出现误杀后快速回滚配置。
六、面对小白的两个常见问题
Q1：我是不是必须同时部署所有层次？
不一定。如果你的业务是静态博客，第一层（DDoS防护）+ 第二层（CDN缓存）可能就足够了；如果是电商或金融系统，则需要完善的三层甚至四层。节省成本的方法：优先保证第一层和第二层，第三层根据业务风险逐步构建。
Q2：云厂商的WAF能代替自己搭建的清洗吗？
云厂商的WAF通常同时提供L3/L4 DDoS清洗和L7 WAF能力（如阿里云WAF、腾讯云WAF、Cloudflare WAF）。对于中小型企业，直接使用云厂商的托管服务可以快速获得分层能力。但对于中大型系统，自建部分自定义规则（比如针对内部接口的细粒度限流）仍然有必要，因为云厂商的通用规则可能不够贴合你的业务场景。
相关阅读：此处可内链到“DoS L3常见问题”专题。
七、总结与DoS L3
故障定位思路
网络层DoS攻击是“蛮力”，靠流量冲垮带宽；CC攻击是“巧力”，靠逻辑耗尽资源。分层清洗的本质就是用大炮对付蛮力，用手术刀对付巧力。第一层用大流量清洗中心挡海量包，第二层用限流和缓存减量，第三层用行为分析精准切除，第四层用弹性伸缩兜底。掌握这个框架，你就能在面对攻击时不再手足无措，而是有条不紊地逐层应对。
最后提醒：不要等到攻击来了再配置规则。提前做好容量评估、阈值设置和演练回滚流程，才是中大型云端系统长期稳定的保障。后续只要定期检查关键指标，DoS L3就不会变成维护负担。
延伸阅读