攻击发生的第一时间，你的首要任务不是自己埋头硬扛，而是拿起电话联系上游服务商，把“我正在被打”这件事准确传达给对方，并启动双方的协同处置流程。
DDoS攻击的流量清洗能力，从来不在源站服务器上，而在上游骨干网络的“咽喉要道”里，当你发现服务器CPU飙升、带宽被打满、网站响应超时的那一刻，攻击流量其实已经通过了运营商或高防服务商的节点，继续在服务器上捣鼓防火墙规则，就像家里漏水了不去关总闸，只盯着地板上的一滩水发愁，业内专家指出，超过半数的严重DDoS攻击事件，最终都是靠上游的流量牵引和黑洞路由才化解的，这篇文章就聊聊在攻击发生的黄金一小时内,你怎么跟上游服务商打好这场配合战。
为什么必须拉上上游一起“动手术”
搞清楚协同处置的必要性，是你按下那个拨号键的前提，很多团队第一反应是“我们自己有CDN，有WAF，能扛”，但实际上，普通CDN节点的单点带宽通常只有几十G，而常见的SYN Flood或UDP反射放大攻击，动辄就能打出上百G的流量，当攻击量级超过你所有防护节点的总和时，CDN反而成了攻击者的放大器流量从四面八方汇聚到你的源站，源站一垮,边缘节点缓存再厚也没用。
上游服务商手里的王牌是清洗能力和近源压制，他们的机房直接连着骨干网，通过BGP路由通告，可以把原本指向你IP的流量先引到他们的清洗设备上，过滤掉恶意包，再把干净流量回注到你的源站，这个过程叫“流量牵引”，没有他们的配合，你自己在服务器上敲一万行iptables命令,也只是在洪水中划拉小船。
拿起电话前，先准备好这三样东西
别一打通电话就语无伦次，上游的运维专家一天要接几十个攻击电话，你提供的有效信息越多，他们启动应急响应的速度越快，建议你提前在团队内部定一个“攻击急诊单”模板,包含以下三项核心内容：
- 被攻击的IP或域名：具体到哪个IP段正在被攻击，是单个IP还是整个C段,这决定了对方是否要做黑洞路由。
- 攻击的初步特征：是带宽型攻击（流量跑满）还是资源消耗型攻击（CPU跑满但带宽不高）？如果是应用层攻击,最好能提供一两条典型的恶意请求日志。
- 你当前的应急状态：你是否已经自行封禁了某些海外IP？是否已经开启了CDN？是否已经对源站做了降级处理？
信息越全，对方越能快速判断是采用旁路清洗还是牵引黑洞，行业共识认为，90%以上的紧急工单延误，都是因为用户在电话里描述不清攻击类型,导致上游反复调整防护策略浪费了时间。
协同处置的三个关键阶段：别当“甩手掌柜”
拉上上游一起做事，不代表你可以下线关机，整个攻击生命周期,你们需要按照以下三个节奏紧密配合。
流量牵引期，你盯紧“黑洞”副作用
当上游决定对某段IP启用黑洞路由或牵引清洗时，你会观察到两个明显变化：第一，攻击流量确实进不来了，因为都被引导到了上游的清洗设备；第二，你的服务器对外响应可能变得极慢，或者干脆ping不通，这时候别慌，这是“清洗”的代价。
你需要做的事是立刻检查源站服务器的负载，如果CPU已经降下来，而业务仍然无法访问，很可能是上游的回注链路没有打通,此时你需要做的动作是：
- 检查源站防火墙是否放行了上游清洗设备的回注IP段。
- 确认你的公网IP是否在服务商的黑洞列表里，如果被黑洞了,立即申请解封并切换备用IP。
这时候切忌“双线操作”一边跟上游说着在清洗，一边自己又在服务器上乱封IP，导致回注流量被你的本地规则误杀，你此刻的角色是盯着服务器日志，确认干净流量是否成功回流,而不是继续调优防火墙规则。
攻击持续期，你负责“情报”定位
攻击通常不会是一波流，而是打了停、停了打，在第二波攻击来临时，上游需要判断攻击源IP是否有规律，这时候，你要做的是深度配合溯源，别觉得溯源是网警的事，上游的设备能看到攻击包的五元组信息，但业务侧的特征更能帮助定位攻击动机。
具体实操上,你可以做如下动作：
- 在入口交换机上做端口镜像，抓包分析攻击包的特征码，看看是不是特定user-agent或特定协议字段。
- 配合上游，将攻击流量中的异常IP段信息反馈给他们，比如你发现攻击源集中于某个云服务商网段,上游可以直接对该网段做严控。
- 如果攻击打的是HTTP业务，你可以临时在源站前端加一道校验逻辑（如JS挑战），把动态请求和攻击流量区分开，并实时把“脏流量特征”同步给上游清洗设备做精准匹配。
这里有个容易忽略的细节：攻击有时是冲着你的服务商来的，如果上游机房整体被攻击，你的业务只是“殃及池鱼”，那你的诉求就不是清洗，而是申请迁移或调整出口带宽，这种判断需要你冷静阅读上游发来的工单状态描述，别一股脑催对方“快点洗”。
攻击结束期，你必须要做“复盘”确认
攻击流量归零，不代表事情结束，真正的协同处置，收尾阶段必须确认两件事：黑洞是否完全解除、清洗策略是否已经下掉，要是忘了通知上游解除清洗策略，你的流量会一直被绕行,导致链路延迟暴增。
建议你主动向上游索要本次攻击的防护报告，里面通常包含攻击峰值、攻击类型占比、清洗结果，拿到报告后，对照你自己的监控数据，评估一下“丢包率”和“业务受损时长”，这个步骤的价值在于，下次如果再被打，你能清晰地知道“上次的方案是否有效”，以及“哪类攻击自己扛得住，哪类必须第一时间找上门”。
找“谁”协同？选择比努力更重要
有些用户用着免费的高防，攻击一来就跑去找机房管理员，结果对方两手一摊说“我们也是租的运营商线路”，这就很被动。高效的协同，建立在服务商具备三层能力之上：有大带宽资源（至少单点防护1T以上）、有BGP全动态路由调度能力、有7x24小时的人工应急响应群。
选型时别只看宣传页上的“最高防护峰值”，那是防不住时的“天花板”，可以问问销售：“你们的清洗通道是专属的还是共享的？攻击流量打满通道时，会不会被限速？”如果对方支支吾吾，建议谨慎选择天猫、腾讯这类头部云厂商的正规产品，虽然价格高点，但人家的清洗集群更像“正规军”,打配合战不掉链子。
地域上，如果你的用户群主要在华东，尽量选择上海、杭州机房的上游节点，避免跨运营商调度带来的时延，不少攻击事件里，用户发现和上游“地域不匹配”，导致回注流量绕了半个中国，业务延迟暴增到300ms以上，这体验基本等于“虽然没打死，但已经半残废”，协同不只是“刷脸”，更是网络拓扑上的就近匹配。
定期“演习”：把协同变成肌肉记忆
别等到被打才去找上游的电话号码，建议你平时就跟服务商的运维团队建立一个日常联络群，把双方的接口人拉进去，每个季度，可以主动发起一次模拟演练：故意在深夜用压测工具打一下自己的IP，然后走一遍提工单、电话通知、牵引清洗、回注恢复的完整流程。
演练的价值在于，你能真实评估对方的响应速度，这里有个比较直观的判断标准：如果从你拨出电话到攻击流量被成功牵引，耗时超过15分钟，说明对方的自动化调度能力堪忧；如果超过半小时，你就要考虑换一家了，多数情况下，成熟的商业高防服务商能在5分钟内完成流量切换，这就是协同的“黄金窗口”。
相关Q&A
Q：攻击发生后，我能不能直接联系IP所属的运营商（如电信、联通）来处置？
可以，但效果通常不理想，运营商主要提供基础网络通道，他们面对DDoS攻击的常规动作是“封IP”或“黑洞路由”，这属于断臂求生，会直接牺牲你的业务可用性，专业的高防服务商或云厂商，才是做精细化流量清洗的机构，建议将“运营商通报”和“服务商协同”分开：给运营商报备攻击事件，主要为了防止IP被永久封禁；给服务商打电话,是为了尽快恢复业务。
Q：如果上游服务商说“攻击流量太大，需要硬扛2小时”，我该怎么办？
这说明对方已经尽到了清洗职责，但攻击峰值超过了他们当前的冗余带宽，此时你需要立即启动降级策略：将源站切换为静的只读模式，关闭登录、支付等动态接口；同时果断推高CDN的缓存命中率，让边缘节点扛住静态流量，这就像暴风雨太大，你家屋顶漏雨，你一边找物业（上游）拉防水布，一边自己抓紧把贵重物品（核心数据）往二楼搬，等流量洪峰过去，再恢复动态服务，此刻最大的误区是反复刷新服务器后台试图“看看到底好了没”，这毫无意义,只会增加你的焦虑。
Q：攻击过后，我要做些什么来避免下次挨打？
攻击结束后，第一时间检查源站服务器的日志，看是否有被植入的Webshell或后门程序，因为大部分DDoS是“烟幕弹”，真正目的是掩盖同步进行的CC攻击或入侵行为，将本次攻击的样本特征（如特定攻击端口、协议类型）写入高防IP的防护策略中，开启“智能封禁”模式，给源站更换IP，并在新IP前加一层访问控制白名单，只允许高防回注IP段访问源站，这样即便再有零日攻击,对方也打不到你的真实源站。