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%可用。所以业务侧必须做“多活”设计。比如关键域名解析到多个高防节点，流量调度系统自动检测节点是否异常，异常时快速切换；静态资源走CDN，CDN本身就是天然的分布式抗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）：这是最直观的指标，实时监测，超过阈值立刻告警。
- 每秒新建连接数（cps）：SYN 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级流量很吓人，但只要你有架构兜底、流程明确、人能快速上手，业务照样能稳稳地跑在浪尖上。希望这份经验清单能让你少走我走过的弯路。
