买了云服务器，看到「弹性扩容」四个字就以为被 DDoS 攻击时能自动扛住？这个想法很常见，也很危险。本文用 8 个问答讲清弹性扩容到底能防什么、防不了什么，以及被打时正确的处置顺序，命令与配置可直接复制。
Q：云服务器弹性扩容能防DDoS吗？
结论先给：弹性扩容不能防 DDoS，它只能应对业务量增长，不能应对攻击流量。
- 扩容的对象是计算资源：CPU、内存、应用实例数。
- DDoS 打的是网络资源：入向带宽、连接表、并发连接数。
- 攻击流量在到达实例之前，往往已经把带宽出口占满，扩容多少台机器都进不来。
一句话概括：扩容是「加人手」，DDoS 是「把门堵死」。门被堵死的时候，加多少人都没用。
Q：为什么说扩容对DDoS基本无效？
因为攻击方消耗的资源是无状态、成本极低的，而你扩容的资源是有状态、有成本的。逐层看：
- 带宽层：10Gbps 的流量进来，云实例的带宽上限常在 100Mbps 到 1Gbps 量级，实例还没开始工作，链路先满了。
- 连接层：SYN Flood 直接把连接表占满，瓶颈在内核表项而不是 CPU，加实例解决不了。
- 应用层：CC 攻击打的是动态接口，每个请求都很「贵」。扩容能延缓几分钟，攻击方只要加大并发，你就得继续加机器。
最致命的是成本结构：扩容是攻击者免费、你买单。按量计费的实例随攻击量上涨，扩得越多账单越贵，攻击方一分钱不多花。这正是「扩容陷阱」的核心 —— 它把攻击成本转嫁给了被打的人。
Q：弹性扩容在什么情况下真的有用？
三种场景适合，而且都不是 DDoS。
- 突发真实流量：内容被推荐、上了热搜、活动开抢。流量有上限、会回落、请求分布正常。
- CC 攻击的早期缓冲：攻击并发还小时，扩容能撑一段时间，给你留出加防护规则的时间窗。
- 爬虫爆发：大量爬虫集中在白天抓取，扩容能撑住，但更省钱的方案是限速加封禁。
判断标准很直接：流量曲线缓慢上涨、有峰有谷、请求分散，扩容有效；秒级阶跃、单 URL 集中、深夜不降，扩容无效。
Q：扩容防攻击有哪些必须避开的坑？
- 账单炸掉：必须给伸缩组设最大实例数上限，并且开预算告警。攻击期间 CPU 打满触发扩容、一天烧掉几个月预算是常见事故。
- 缩容风暴：攻击停几分钟就缩容，攻击再起又扩容，实例反复拉起导致启动慢、连接被丢。
- 缓存冷启动：新实例本地缓存是空的，一上来全量回源，可能把数据库打挂，扩容反而放大故障。
- 依赖没跟着扩：应用扩了 10 倍，数据库没扩，瓶颈只是从应用层搬到数据库层，故障时间点推迟而已。
# 给伸缩组设上限（以阿里云 CLI 示意，字段名以实际版本为准）
aliyun ess ModifyScalingGroup \
--ScalingGroupId asg-xxxxxx \
--MinSize 4 \
--MaxSize 10
# 同时绑定预算告警：按量实例月度消费超阈值即通知
# 控制台配置「费用中心 - 预算管理」，阈值建议设为日常成本的 3 倍Q：怎么判断是被打满带宽还是被吃满CPU？
两个命令就能分清，这是处置方向的分叉点。
# 1. 看实时带宽：哪个进程、哪块网卡在跑
iftop -nNP -i eth0
# 看历史峰值（5 分钟粒度）
vnstat -5
# 2. 看连接表与套接字状态
ss -s
ss -ant state syn-recv | wc -l
ss -ant state established | wc -l
# 3. 看来源集中度（Nginx 侧近万条请求的 Top IP）
tail -10000 /var/log/nginx/access.log | awk '{print $1}' \
| sort | uniq -c | sort -rn | head -10判读口诀：带宽先满、CPU 没动，是四层攻击；带宽正常、CPU 和连接数飙升，是应用层攻击。前者要靠上游清洗，后者要先限速再封来源。补充一点，ss -s 输出里 synrecv 持续上涨基本可判定 SYN Flood。
Q：被DDoS攻击时正确的处置顺序是什么？
- 先藏源站：确认源站 IP 是否已暴露。暴露了就先换 IP 或接入防护节点，把解析切过去。
- 再降单请求成本：把被打的 URL 上缓存或静态化，让攻击请求打不到后端。命中缓存对后端是零成本。
- 然后切来源：用带超时的
ipset自动封禁，别手工维护黑名单。 - 最后评估是否上高防：持续大流量攻击本地挡不住，需要清洗服务。
# ipset + iptables：封禁 3600 秒自动解封，避免永久误封
ipset create badip hash:ip timeout 3600 -exist
ipset add badip 203.0.113.7 -exist
iptables -I INPUT -m set --match-set badip src -j DROP
# 查看与清理
ipset list badip | head
ipset destroy badip顺序不能颠倒。先封 IP 而后端还在被同一批 URL 刷，等于只堵了一个出口；先上缓存再封来源，成本才最低。
Q：CDN能补上扩容补不了的那部分吗？
能补一部分，但要分清补的是什么。CDN 的核心价值是隐藏源站 IP 加分担静态请求，它本身不等于高防。
- 静态资源走 CDN 后源站只处理动态请求，可被攻击面直接缩小一个量级。
- 源站 IP 不暴露，攻击者只能打 CDN 节点，节点被打还有调度兜底。
- 大流量四层攻击仍需要清洗能力，普通 CDN 的带宽池不一定够。
# 接 CDN 后源站必须校验回源 IP，否则等于把门敞开
allow 203.0.113.0/24;
allow 198.51.100.0/24;
deny all;关键点：不要写成 allow 0.0.0.0/0，那等于没配。回源段清单在 CDN 控制台可以下载，改完一定要在监控里确认业务没被误挡，再放开流量。
Q：还有什么补充建议？
- 买之前问清三件事：清洗阈值多少、超阈值怎么处理、是否按攻击流量计费。很多所谓弹性防护实际只是卖你按量实例。
- 预留一个降级开关：被打时一键切静态页或只读模式，保住核心交易链路，比硬扛有效得多。
- 监控盯三个数：入向带宽、
synrecv数量、单 IP 最高请求数。三个一起看就能判断攻击层级。 - 别让扩容替代防护：扩容是容量工具，防护是安全工具。混为一谈的结局就是一个又贵又挡不住的系统。