1. 面对T级大流量攻击先弄清楚你接到了什么“流量”先说句实话很多人对“T级大流量攻击”没有概念以为就是带宽被占满、网站变慢而已。真到了那个量级你会发现情况完全不是这样——机房交换机端口被打满只是最低级的症状更麻烦的是四层并发连接耗尽、源站CPU被打到100%、日志系统被冲崩、甚至运营商直接给你做黑洞路由整个IP从公网上消失。这次的“T”已经从过去几年的几百G、一两T变成了动辄三五T甚至更高的清洗能力需求单靠某一台设备或某一条链路根本扛不住。这篇文章的适用范围很明确如果你的业务属于中大型网站、在线游戏、金融交易、直播互动、电商大促这类对可用性极其敏感的场景而且你预估自己的带宽在百G以上且历史上被打过或可能被打那这篇文章的整套思路可以直接抄作业。如果只是普通小站思路也可以参考但不需要上全套方案。先说清楚一个基本概念T级大流量攻击最常见的形态是DDoS流量型攻击核心目的就是耗尽链路带宽和网络设备的转发能力让正常用户连不上你的服务器。它不一定要攻破你的业务逻辑只要把你的“路”堵死就够了。所以防御的核心不是一个“防住”的概念而是一个“分流 清洗 冗余”的系统工程。我经历过几次半夜被T级流量打醒的事件从最开始的手忙脚乱到后来形成了一套固定流程这篇文章就把整套思路、步骤、排障经验都整理出来希望对你有用。2. 防御架构设计为什么“扛住”不是靠单一设备2.1 先理解攻击流量是怎么打过来的攻击流量的来源绝大多数是僵尸网络也就是被木马或蠕虫控制的大量肉鸡设备。这些设备分布在全世界各地主控端下发指令后它们同时向你的IP或域名发起大量请求。常见手法有UDP反射放大比如NTP、Memcached、SSDP反射、SYN Flood、ACK Flood、HTTP Slowloris等。T级攻击基本是多种手法混合打单纯靠某种算法过滤根本无法根治。这里有个概念要分清攻击流量到达你机房时你只有两条路可以选——要么找上游运营商帮你丢弃要么靠自己的清洗设备硬扛。你自己机房的接入带宽是有限的比如你买了200G接入带宽攻击来了400G那机房入口就满了任何人的流量都进不来包括正常用户。所以第一要务不是“自己扛住”而是“让流量在到达你机房之前的某个地方被处理掉”。2.2 三层防御架构是标配我用过的比较稳的方案是三层架构分别解决不同层面的问题第一层运营商级黑洞与流量调度。和IDC机房、运营商提前约定好一旦流量超过某个阈值直接把被攻击IP的流量导入黑洞路由虽然自己的服务也停了但至少保住了同机房里其他业务的带宽和路由设备不被拖死。这是最后一道“弃车保帅”的策略属于兜底方案。第二层高防IP / 高防机房清洗。所有业务域名解析到高防IP流量先进入高防机房的清洗集群那里有专门的大带宽和算法匹配设备把攻击流量识别出来、丢弃掉把干净流量回源到你的真实服务器IP。这是日常最常用的一层。第三层本地防护加固。在源站服务器上部署四层和七层的防护软件比如iptables、nginx层限速、WAF等做最后一道过滤防止清洗漏网的小流量直接打到业务端口上。这三个层级不是独立的而是要联动。比如高防IP清洗能力不够被更大的流量冲过阈值就要触发第二层的运营商黑洞清洗设备的回源策略如果配置不合理源站照样会被打瘫。这一整套联动逻辑建议用文档固化下来并且在每次活动前做一次演练。2.3 全链路“不把鸡蛋放在一个篮子里”真正扛过T级攻击的人会告诉你一个残酷的事实就算你有高防也不一定能保证100%可用。所以业务侧必须做“多活”设计。比如关键域名解析到多个高防节点流量调度系统自动检测节点是否异常异常时快速切换静态资源走CDNCDN本身就是天然的分布式抗D节点源站IP不直接暴露在解析记录里避免被“摸到后路”直打源站。这一段听起来像架构课但我实际经历里很多公司被打瘫不是因为扛不住T级而是因为被攻击者找到了源站IP精确打击了源站的瓶颈资源。源站隐藏做得越深你的安全垫就越高。3. 高防IP选型、调度策略与关键参数配置3.1 高防IP怎么选别只看“T”数市面上的高防IP服务广告都写得很大——“可抵御N T攻击”“清洗能力无上限”真用起来才知道里面门道很多。我建议按以下几个维度去评估评估维度关注点为什么会坑清洗带宽是独享还是共享最大清洗量能到多少共享带宽的高防IP大攻击时可能被其他租户挤掉额度回源带宽清洗后回源到你的带宽是多少回源带宽低于攻击流量峰值数据就直接在清洗端堵死了封禁策略触发黑洞的阈值是可调的还是固定的固定阈值下正常业务流量一大甚至误触发黑洞防护算法是否支持四层七层联动清洗只有四层防护HTTP应用层攻击照样打穿节点数量是一地部署还是多地区调度单节点被攻击宕机全站就废了我自己的筛选经验是先问一句话——“如果我有一天被打了5T你们的SLA怎么保证触发了黑洞之后多久恢复”如果对方支支吾吾说“看情况”那建议直接换一家。3.2 关键参数配置阈值、清洗策略、回源设置这里有几个参数我认为必须仔细理解和配置踩坑概率极高第一个是触发黑洞的阈值。这个值通常是清洗能力上限的某个百分比。你不要以为越小越安全设太小的话一波正常业务突发流量就可能把IP打进黑洞业务直接中断。设太大又等于没有防护。我的做法是结合业务高峰期的正常带宽峰值乘以一个系数通常是1.5到2倍但同时也必须在清洗能力的80%以内。比如平时峰值20G清洗能力200G那阈值可以定在40G左右——既能容纳正常流量波动又不会因为小攻击就误触。第二个是清洗模式的开启时机。很多高防产品支持“观测模式”和“清洗模式”。我的建议是平时不要一直开着强清洗尤其对UDP业务而是通过监控指标比如入向带宽、并发连接数触发自动清洗。手动开清洗的延迟一般在几分钟这几分钟足够让业务打崩了所以建议用产品自带的阈值触发功能。第三个是回源方式。常见的有两种一种是通过高防节点的内网IP回源另一种是通过公网IP回源。内网回源延迟低、安全性好但要求源站和清洗节点在同一内网网络里公网回源灵活但源站IP暴露在公网环境下如果回源白名单配置不严源站还是能被直接打到。无论哪种方式回源IP上一定要做白名单只允许来自高防节点的IP访问源站。3.3 多云/多高防节点间的流量调度我踩过一个比较深的坑高防节点本身是单点管你宣称清洗能力多强一旦节点内部的某个设备故障或链路中断业务就全断了。后面改成“双高防节点 健康检查自动切换”后心里才稳了不少。实现的逻辑是这样的每个高防节点后面都配置源站的健康检查通常是HTTP HEAD请求或TCP端口探测一旦连续3次探测失败DNS流量调度系统会立刻把该节点的解析权重降为0把流量切换到另一个节点。这个过程不是秒级DNS TTL加上探测周期大概会有1到5分钟切换时间但对业务连续性来说可以接受。另外一个细节是流量调度系统本身的监控页面要在本地留存一份独立的告警通道不能只依赖第三方控制台的通知否则平台自身出问题时你根本不知道。4. 从监控告警到应急响应实操中的战术手册4.1 监控什么指标怎么设置告警先给一套我常用的监控指标清单全部做成图表并配上告警入向带宽bps这是最直观的指标实时监测超过阈值立刻告警。每秒新建连接数cpsSYN Flood攻击时这个值会瞬间飙升到几十万甚至上百万。并发连接数能看出业务到底是被拖垮了还是只是带宽问题。CPU/内存使用率应用层攻击比如慢速连接会表现为CPU暴涨。DNS解析成功率如果DNS被污染或调度系统出问题这个指标会先爆。回源成功率高防节点到源站的链路出问题业务也会挂。告警阈值建议分层橙色预警比如入向带宽达到正常峰值的1.5倍、红色告警达到清洗阈值80%、黑色告警达到触发黑洞阈值——每一层对应不同的响应动作。4.2 应急响应SOP从发现到恢复的固定动作我整理了一份被人验证过比较稳妥的应急响应流程这里直接分享具体步骤确认攻击类型和方向。先看流量是否都打在高防IP上还是源站IP也被打了。打开高防控制台的流量报表看攻击手法是UDP Flood还是TCP Flood这决定了后续清洗策略怎么调整。自动触发清洗是否生效。如果产品开了阈值自动清洗确认清洗状态是否变为“清洗中”如果没有自动清洗立刻手动开启清洗模式。检查回源链路是否正常。这一步特别容易被忽略——清洗了攻击流量后回源链路如果因为之前的冲击出现丢包或拥塞正常流量也进不来。这时候要在源站上抓包确认回源质量。评估是否需要切换高防节点。当前节点清洗能力已经到顶或者清洗效果不佳就启动备用节点切换流程。观察业务恢复情况。用本地拨测工具比如curl指定回源header、第三方拨测平台确认用户侧能正常访问。保留证据、复盘。把抓取的pcap、流量报表、告警记录都保存下来事后分析攻击源是否有规律以便优化后续防护参数。这套SOP里最重要的其实是第3步很多团队以为清洗一开就完事了没想过回源链路也可能被打断。我实际遇到过攻击流量被高防节点清洗得很干净但回源链路上的中间网络设备被大流量冲击后产生了路由器震荡导致源站收不到回源数据。4.3 万一触发了黑洞怎么最快恢复黑洞是运营商的强制保护手段一旦触发IP在路由层面被置为不可达所有流量包括正常的都会被丢弃。这个过程通常持续30分钟到2小时不等。恢复的经验是如果你有多个IP或多个高防节点第一时间把解析切换到一个未被黑洞的地址如果是单一IP被打进黑洞只能等待黑洞自动解除。不要试图用“换个端口”或“改个域名”这种临时手段黑洞是按IP粒度生效的域名解析到其他IP需要时间但源站带宽也扛不住那么大流量。另一个实际经验是黑洞触发前把当前攻击特征、清洗策略、流量大小都记录在案等黑洞解除了更新策略——不然同样的攻击再来一轮还会被黑洞。这个“记录-调整-验证”闭环是在T级攻击下活下来的基本功。5. 常见问题与排查技巧实录硬件、配置、人这三大坑5.1 高防设备“误杀”正常流量怎么办清洗设备为了丢弃攻击流量一般会设置一些规则比如按IP限速、按协议限速。但有时候攻击特征和正常业务很像比如都是UDP大包就会导致正常用户被限速体验直线下降。我的排查步骤是第一在清洗策略里把源站IP的白名单做细——比如只允许特定运营商IP或特定来源地域访问第二开启“防护观测模式”一段时间把清洗前的流量和清洗后的流量做对比看是不是丢弃比例过高第三调整清洗力度把高敏感度算法调低一档宁可让少量攻击流量漏过去也别误杀正常用户。提示清洗策略不是“越严格越好”要在安全性和可用性之间做平衡。正常情况下误杀率应低于万分之一如果你发现清洗后业务流量掉了一半大概率是策略有问题。5.2 攻击没停但清洗没触发是什么原因这个比较邪门但确实遇到过。排查思路如下先看监控指标是不是真的达到了阈值入向带宽是瞬时值还是均值如果用的是5分钟均值攻击峰值可能被“削平”了再看清洗设备本身的CPU是否有瓶颈设备处理能力不足时即使流量超大清洗状态也显示未触发最后看是不是攻击流量含有大量的IPv6流量部分清洗设备对IPv6清洗支持不完善。这类问题最好的解决方式是在攻击发生前就做一次“模拟攻击测试”。很多高防服务商提供这种测试服务可以提前验证清洗阈值和触发逻辑是否正常。我非常建议每季度做一次宁可花钱买安心别等到真出事再来验证。5.3 源站IP被“扒”出来直打怎么防源站IP被扒通常不是黑客技术多强而是你的DNS历史记录没清理干净、邮件头暴露了真实IP、测试子域名没有隐藏、或者证书里包含真实IP信息。被直打源站后高防IP就成摆设了——攻击者绕过了清洗直接打你的真实服务器。应急处理第一步更换源站IP并在新IP上只允许高防节点IP访问通过安全组或iptables白名单第二步清理所有可能泄露源站IP的地方第三步关键的防御点是——回源流量要伪造一下TCP特征比如修改TCP窗口大小、TTL值等让攻击者更难判断你的真实源站IP。这个“伪装回源流量”的做法很多人不知道但对隐藏源站有奇效。5.4 攻击期间业务逻辑正常但用户体验还是差一个容易被忽略的细节T级攻击会影响运营商骨干网络的拥塞状态即使你的高防把攻击流量清洗掉了用户到高防节点的链路也可能因为骨干网拥塞而延迟升高或丢包。这就是你明明看着一切正常用户却在反馈“卡成PPT”的原因。我试过比较管用的优化把业务的核心页面和接口尽量做成静态资源放CDN把动态请求压缩到最小另外关键业务尽量接入多个云厂商的CDN不同运营商链路条件不一样在攻击期间做实时切换。6. 从被动防守到主动防御日常需要练好的基本功6.1 容量规划平时就要按“被打”来设计很多人把容量规划当成“买多少带宽服务器”的问题但我建议按攻击场景来规划。比如正常峰值20G的业务至少要保证以下三个能力高防清洗能力200G以上、源站回源带宽50G以上、源站集群横向扩容能力在30分钟内翻倍。用这个标准去检验现有架构大概率会发现自己很脆弱。特别是回源带宽很多人只买了20G或者干脆复用业务带宽清洗完的流量都回不来那清洗就等于白洗了。回源带宽建议是正常业务峰值的2到3倍。6.2 攻击预案要“写下来、练过、能调”预案写了的不少练过的很少。我建议每季度做一次桌面推演或实战演练把高防切换、黑洞恢复、源站加固、应急联系方式全部过一遍。演练时故意设置几个“故障”——比如备用节点不可用、回源白名单失效、清洗阈值误触发——让团队在压力下找出问题。平时可以把常见攻击的应急命令都写到同一个运维脚本仓库里贴好注释确保换个人也能操作。比如一键开启清洗、一键切换高防节点、一键修改回源白名单、一键导出流量包。6.3 攻击之后的复盘和优化每次攻击结束后一定要拉通所有干系人复盘。我习惯用三个维度来量化复盘结果恢复时长从攻击开始到业务恢复的时间、影响范围哪些业务线中断了多久、失效点架构里哪个环节没扛住。这三点记录清楚下一次方案优化就有数据支撑。我见过有些团队攻击结束后把IP换一换、策略调一调就完事了没有沉淀任何文档和自动化工具。结果下次被打还是同样的流程同样的慌乱恢复时间一点没缩短。真正的成长不在于“扛过了T级攻击”而在于把这套经验固化成系统和流程让团队不依赖某个“大神”也能快速响应。6.4 从“扛住攻击”到“降低损失”业务降级预案最后补充一个很多人不重视但实战中很加分的东西业务降级预案。T级攻击来的时候即使你有一套完整防护部分功能可能会暂不可用。与其全面不可用不如提前想清楚哪些功能是“核心中的核心”哪些可以临时降级。以电商为例大促期间被打你可以临时下线评论、搜索、推荐等低优先级功能保证下单、支付链路可用以游戏为例可以临时关闭跨服、排行等模块保持登录和战斗房间稳定。业务降级不是认怂而是在极端情况下把损失降到最低的聪明做法。我个人在实际操作中的体会是抗大流量攻击不是一场“单点防护”的对抗而是整个系统设计、日常运维、应急预案、团队配合的综合素质比拼。T级流量很吓人但只要你有架构兜底、流程明确、人能快速上手业务照样能稳稳地跑在浪尖上。希望这份经验清单能让你少走我走过的弯路。