流量清洗扛大流量，本地防护管精细规则，两者按攻击类型分层分工，清洗在云端消化DDoS洪峰，防护在本地过滤剩余恶意请求。
流量清洗和本地防护怎么分工？边界就在“流量过不过门”
很多站长第一次接触DDoS防护时，被各种名词绕晕，高防IP、流量清洗、云WAF、本地防火墙、入侵检测……到底谁管谁？先想明白一个场景：你家门口突然冲进来一千个人，靠门卫一个个搜身肯定拦不住，得先让交警在路口把大部分人引流走，流量清洗干的就是交警的活儿，本地防护干的是门卫的活儿，分工逻辑就一句话：能在外围解决的大流量攻击，绝不放进本地；进了本地的流量，必须用精细规则挑出漏网之鱼。
流量清洗负责“减量”：消化带宽层攻击
流量清洗一般部署在云服务商或高防机房的入口侧，通过BGP引流把攻击流量牵引到清洗设备上，识别并丢弃恶意报文，再把干净流量回注到源站，它擅长处理的是SYN Flood、UDP Flood、ICMP Flood这类以耗尽带宽和基础设施资源为目标的攻击，这类攻击的特点是流量大、报文特征单一，检测逻辑相对简单，就是看速率、看包量、看连接数有没有异常飙升，清洗设备不需要理解业务逻辑，只需要快速判断“这个包是不是攻击”，是就扔掉,不是就放行。
行业共识认为，清洗节点越靠近骨干网，防御能力越强，因为带宽资源更充足，所以高防产品通常会强调“独享带宽”或“共享集群”,本质上就是给清洗留出足够的消化空间。
本地防护负责“抠细节”：拦截应用层攻击
流量回到源站之后，清洗已经帮你去掉了绝大部分洪水流量，但攻击者不会就此收手。HTTP Flood、慢速攻击、CC攻击这些应用层攻击，单个请求看起来完全正常，速率也不高，云端的清洗设备很难在“不误杀正常用户”的前提下精准识别，这时候本地防护就要接手,用更贴近业务的视角去做检查。
本地防护设备例如WAF、IPS、主机安全Agent，关注的是请求内容本身，比如URL路径、User-Agent、Cookie字段、请求频率、Session行为，它们能和业务代码深度结合，理解“什么才是正常用户的操作轨迹”，举个具体例子：一个登录接口一分钟收到200次请求，云端清洗大概率不会拦，但本地WAF看到同一个IP在暴力撞库,就会触发封禁策略。
流量清洗和防火墙有什么不同？按攻击链路由外到内分层
不少人在选型时纠结，到底买高防IP还是买防火墙？其实两者不是替代关系，而是上下游关系，把一次完整的DDoS攻击想象成一条流水线，流量清洗是第一个工序,本地防火墙是最后一道质检。
网络层大包交给清洗，会话层异常交给本地
- 流量清洗管网络层和传输层：处理的是IP报文和TCP/UDP会话，只要是带宽型攻击，无论报文怎么伪装,速率一上来就会被识别。
- 本地防护管会话层到应用层：处理的是TCP连接行为和HTTP业务逻辑，比如TCP连接建立后不发数据、HTTP请求头缺失、Cookie异常，这些行为特征流量清洗根本看不到,只能由本地设备判断。
清洗看“量变”，本地看“质变”
流量清洗的逻辑是阈值触发：连接数超过每秒X万个，或者入向带宽超过YGbps，就启动清洗，这种机制决定了它善于应对“突发、大量”的攻击，本地防护的逻辑是规则匹配和基线学习：某个接口的响应时间突然拉长、错误码比例异常升高、特定参数被反复尝试，这些“小动作”正是本地防护的识别范围。
实操中有一个判断技巧：如果攻击发生时源站带宽被打满，说明清洗节点没接好；如果带宽正常但业务卡顿，说明攻击穿透了清洗，本地防护需要加规则。 这个判断方法在排查问题时非常管用。
高防IP和本地防护如何配合？架构落地与操作路径
光知道理论还不够，具体怎么配？目前主流的高防IP服务都支持多种转发方式,推荐优先级从高到低排列：
- CNAME接入：域名解析到高防别名，高防节点完成清洗后再回源，适合Web业务，切换快,但需要源站IP对高防节点白名单开放。
- IP转发（BGP牵引）：通过路由协议把整个IP段的流量引到清洗设备，过滤后再送回源，适合非Web业务（游戏、APP长连接），但对源站架构有要求,需要支持回注隧道。
- DNS引流：通过DNS轮询或智能解析把不同地区的用户指向不同清洗节点，适合多线机房场景,但生效时间有延迟。
本地防护的策略要与清洗节点联动
很多用户踩过同一个坑：高防IP的清洗阈值调得很低，结果正常业务高峰被误杀；调得太高，攻击流量又漏进来了，建议把阈值设定在正常峰值的5倍到2倍，给业务留出波动空间，同时清洗节点的封禁动作要和本地防护的告警关联起来，比如本地WAF发现某个IP在频繁触发CC规则，可以调用云API把该IP加入高防的黑名单,实现联动封禁。
成本角度怎么选？按业务流量模型来
高防IP的计费模式通常是“保底带宽+弹性峰值”，保底部分每月固定付费，弹性部分按实际发生的最高值计费，如果业务日常流量低但容易被攻击，选高保底低弹性；如果业务本身流量就大，选低保底配较高的弹性上限更划算，部分云厂商的单点清洗能力有限，如果业务对可用性要求极高（比如金融支付），要选支持多地多节点调度的高防方案，单点故障时自动切换，地域上，华北、华东、华南的清洗资源相对充足,边缘地区的节点延迟会略高。
DDoS防护本地清洗方案哪个好？按场景对号入座
这是全网被问烂了的问题，但没有标准答案，不同业务受到的攻击特征差异巨大,选型逻辑完全不同。
游戏业务，长连接+高并发
游戏业务对延迟极度敏感，TCP长连接多，且容易被CC攻击针对，建议方案是“高防IP+本地四层防护”，高防IP负责在入口清洗大流量SYN Flood，本地防护要开启TCP连接合法性校验，比如TCP选项字段检测、窗口大小探测，专门拦截那些“不发数据只占连接”的恶意客户端，千万别在本地用太深的HTTP解析,会拖慢长连接转发效率。
电商网站，秒杀活动会误伤
电商业务的最大难点是正常流量和攻击流量长得一样，秒杀场景下几万人同时点一个按钮，从云端看就是CC攻击，这种情况下流量清洗的阈值必须调高，并且要依赖本地防护的人机校验能力，比如滑块验证、JS挑战、Cookie追踪，行业共识认为，电商场景必须用“云清洗+本地行为分析”的联动方案，光靠任何一端都不够，很多电商客户会在高防IP后面再挂一层WAF,专门处理动态请求。
政企门户，重合规轻性能
政企网站访问量不高，但攻击者喜欢用慢速攻击慢慢磨，这类业务不需要超大的清洗带宽，更重要的是本地防护的会话保持和源IP信誉库，选择方案时可以重点关注本地设备是否支持HTTP慢速攻击的精确识别（比如Headers超时时间、Body读取速率）,便宜大碗的高防包并不是首选。
Q&A：流量清洗和本地防护常见疑问
问：流量清洗会不会误杀正常用户？
清洗设备通过指纹学习和基线比对来判断正常流量，误杀率一般在较低水平，但秒杀、抢票这类瞬时高并发场景确实容易触发误判，解决思路是给高防IP设置“观察模式”，先记录不拦截，分析清楚后再开启拦截策略，本地防护的误杀更多来自规则冲突，建议先在测试环境全量放行记录日志,再逐步收紧。
问：源站IP暴露了怎么办？
高防IP的核心价值就是隐藏源站IP，但如果源站IP已经泄露（比如通过DNS历史记录、邮件头、代码仓库泄露），攻击者可以绕过清洗直打源站，这种情况下需要启用源站IP白名单，只允许高防回源段访问，同时建议源站开通运营商侧的黑洞路由应急通道，真正被打死时快速切换IP而不是干等清洗生效，本地防护需要开启同步防护策略,防止攻击者从非标准端口绕过。
问：本地防护设备自己的性能瓶颈怎么处理？
本地防护代理解析HTTPS流量的CPU开销不小，一旦流量超过设备性能，防护本身就会成为故障点，靠谱的做法是给本地防护做集群部署，前置负载均衡分发流量；或者开启透明桥接模式，设备宕机时自动BYPASS不影响业务链路，在云环境里，本地防护建议用弹性伸缩组托管，CPU超过阈值自动扩容，整体思路是：本地防护追求高可用优于高防御，扛不住的时候先保住业务存活,剩余攻击量再动态牵引回清洗节点。
流量清洗和本地防护的分工本质上是把DDoS防御拆成“粗筛”和“精查”两道工序，前者看流量够不够大，后者看请求像不像人，记住一条核心原则：所有链路都要有逃生通道，清洗失效时本地防护要顶得住第一波冲击，本地防护宕机时流量直接回源也不能拖垮业务。确保两端配置可灰度、可回滚,比追求单点极限防御能力重要得多。