小站被DDoS打：不加钱的五种应急

一、先判断类型：三个数字决定你该往哪个方向救

DDoS 的处置方向完全取决于攻击类型，而判断攻击类型不需要专业设备，看三个数字就能定位。

第一个数字是流量。图床、商城这类资源型站点被攻击时，特征是入向流量出现尖峰，出口带宽被长时间占满，但每一分钟的有效请求数并不高——因为攻击流量多是无效请求，你的服务器在拼命接收、解析、丢弃。判断命令是看网卡累计收字节：

# 每 10 秒采一次网卡收字节，观察 1 分钟内的增量
for i in $(seq 1 6); do
  cat /sys/class/net/eth0/statistics/rx_bytes
  sleep 10
done

如果 10 秒内的增量持续远超你正常业务峰值的 10 倍，这就是带宽型攻击（ volumetric ）。第二个数字是连接数。连接数暴涨但流量不高，说明是 SYN Flood 或者连接耗尽，特征是大量半开连接挂在内核队列里：

ss -s                       # 总连接数统计
cat /proc/net/synrecv      # 半连接队列长度
cat /proc/net/netstat | grep -E 'TcpExt|Syncookies'

SYN 队列被塞满、但应用层 CPU 并不高，是 SYN Flood 的典型表现。第三个数字是请求日志里的 URL 分布。用一条命令统计最近一分钟访问最多的路径：

awk '{print $7}' /var/log/nginx/access.log | tail -n 5000 | sort | uniq -c | sort -rn | head -20

如果攻击流量全部打在一个不存在的路径上，那是应用层攻击（ L7 ），源站每一台机器都在为无效请求做完整处理，CPU 直接打满。第四个补充信号是来源分布：把源 IP 统计一下，如果集中在少数几个网段，那是 IP 段级的定向攻击；如果均匀分散在大量真实住宅 IP 上，那就是混合型攻击，需要专业清洗。

查看 iwebfusion 当前月价与库存

三个数字的组合决定策略：带宽型靠 CDN 和清洗，应用层靠限流和验证，SYN 型靠调整内核参数和加带宽，混合型只能上专业清洗。

二、五种不加钱的应急手段，按这个顺序用

钱能解决的问题很多，但钱解决不了速度。攻击开始后的前 30 分钟，决定成败的是你手上有哪几条免费手段。下面五种按执行顺序排列，从最快见效排到最慢。

第一种，加 CDN 并把源站 IP 藏起来。这是收益最大的一步。把域名解析切到 CDN 的 CNAME，然后在你自己的服务器上用防火墙规则只允许 CDN 的回源 IP 段进来。攻击者打的是 CDN 节点，不再是你的源站；CDN 节点的带宽池远大于单台 VPS，能扛住远超你套餐能力的流量。

# 只允许 CDN 回源段访问 80/443，其余全部丢弃
for ip in 你的CDN回源段1 你的CDN回源段2; do
  iptables -A INPUT -p tcp -m multiport --dports 80,443 -s $ip -j ACCEPT
done
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j DROP

改完记得在云厂商控制台的安全组里也加同样的规则，两层都要配，否则重启后 iptables 规则丢失。

第二种，上 WAF 或反代层做限流。用 Nginx 直接在源站做限流，成本为零，效果立竿见影：

# 对单 IP 的请求速率限制为 10 次/秒，超出直接返回 429
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
server {
    limit_req zone=perip burst=20 nodelay;
    limit_req_status 429;
}

注意 nodelay 的作用：突发请求会被延迟处理而不是立刻丢弃，这能挡掉扫描型攻击但对真正的洪流无效，因为洪流的速率远超 10 次/秒，队列会被瞬间打满后开始大量返回 429，源站的 CPU 反而因为快速拒绝而下降。这一条对应用层攻击的防护效果最好。

第三种，临时关掉非核心功能。被攻击时最该做的是减少攻击面。关闭注册、登录、搜索、评论区、文件上传这些消耗资源的接口，只保留静态页面和订单查询。这一步十分钟内能做完，通常能扛掉 70% 的低强度持续攻击。

第四种，换 IP。这是新手最常想到的方案，但要看清楚它的局限——换 IP 只对 IP 段级定向攻击有效。如果攻击是打在单个 IP 上的，换 IP 有效；如果攻击者锁的是你的域名或整段 IP 池，换了也白换。技术实现上，把 A 记录指向新 IP 即可：

# 应急换 IP 时先把 TTL 降到 60 秒再改，否则全球解析要 24-48 小时才生效
dig +short 你的域名

改 TTL 到 60 秒后，等待旧 TTL 过期的时间取决于各地解析器的缓存状况，通常 1 到 2 小时即可完成切换。

查 racknerd 在售套餐与库存

第五种，报案与留证。这条不解决技术问题，但决定你能不能追回损失、能不能让攻击者付出代价。详见第九节。

三、算账：你的流量配额在攻击下能撑几分钟

这一节是本文最该被记住的部分。绝大多数小站不是被算力打垮的，是被流量配额打瘫的——攻击流量吃掉了正常业务的流量额度，你的站点在攻击持续期间完全无法访问，因为出向流量同样被挤占。

先把单位算清楚。1 Gbps 等于 125 MB 每秒，等于 0.1221 GB 每秒；10 Gbps 等于 1250 MB 每秒，等于 1.22 GB 每秒；20 Gbps 等于 2500 MB 每秒，等于 2.44 GB 每秒。用这个系数乘以你套餐里的月流量，就能算出被打满的时间：

查 cloudcone 在售套餐与库存

这张表把"小站被打了会怎样"从玄学变成了算术。1 TB 月流量的机器在 1 Gbps 攻击下只有 139.8 分钟的余量，超过这个时间你的套餐流量就被吃光，正常用户的页面全部打不开——注意是全部打不开，哪怕攻击流量全部命中的是不存在的图片。

按小时计，1 Gbps 每小时消耗 439.5 GB，5 Gbps 每小时 2197.3 GB，10 Gbps 每小时 4394.5 GB，20 Gbps 每小时 8789.1 GB。真正要算的是配额耗尽之后的边际成本。云途 HK.DS.M 含 9.77 TB 流量，在 1 Gbps 攻击下 22.76 小时配额见底，在 10 Gbps 下只要 2.28 小时；HK.DS.S 含 39.06 TB，1 Gbps 下 91.02 小时见底，10 Gbps 下 9.10 小时见底。

配额见底之后每一小时的账单，按商品库里的超额重置价直接算：云途 HK.DS.S 配额耗尽后，10 Gbps 攻击每小时再烧 4.29 TB，按每 TB 500 元计是每小时 2146 元，24 小时连续攻击的总账单是月费 800 元加超额 31967 元，合计 32767 元，等效单价从套餐内的 20.48 元每 TB 涨到 318.14 元每 TB。HK.DS.M 在同样的 10 Gbps 攻击下，24 小时账单是月费 350 元加超额 18646 元，合计 18996 元，等效单价 184.44 元每 TB。

这张表最重要的一行是云途 HK.DS.M：它的倍率只有 5.6 倍，是所有云途机型里最温和的，代价是套餐内单价 35.84 元每 TB 也是这批里最高的之一。低倍率高单价、高倍率低单价，这两条线的取舍取决于你预期被攻击时的持续时长。

四、算账：换一台能多撑多久

那么问题来了：同样的预算，换个机型能把抗攻击时间拉长多少。这里用同样月预算做对比。

月付 800 元的云途 HK.DS.S 折合每 GB 内存 6.25 元、每 TB 流量 20.48 元、每 GB 盘 0.13 元，是人民币机型里流量性价比最好的一档：39.06 TB 流量在 10 Gbps 下能撑 546.1 分钟。年付 1600 美元的 LAX-LARGE 折合 133.33 美元每月，每 GB 内存 8.33 美元、每 TB 流量 3.41 美元，同样是 39.06 TB 流量，10 Gbps 下同样是 546.1 分钟，但单价只有前者的六分之一左右。

这暴露了一个反常识的事实：决定抗攻击时间的不是机器档次，而是月流量额度。要撑得更久只有两条路，一是加流量额度，二是加机器数量分散源站。后者更划算，因为多台机器的流量额度是叠加的，而单台机器的入口带宽是共享的。

digitalocean 官网机型与实时报价

第四行是个重要提醒：同样是两台，LAX-LARGE 和 2 台 LAX-MEDIUM 的总流量一样，但 LAX-LARGE 的单价是每 TB 3.41 美元，LAX-MEDIUM 也是 3.41 美元，所以它们的成本结构完全相同。选择大内存还是大流量，取决于你的业务到底吃哪个。

还有一个容易被忽略的事实：双机方案的收益是线性的，但你需要付出的是双倍的运维复杂度。要让两台机器真正分担攻击流量，必须做会话保持，否则用户请求被随机打到两台机器上，登录态、购物车、CSRF token 全乱。落地方式是前面挂一个四层负载均衡，把流量按会话粘性分发：

# Nginx 四层负载均衡示例：按客户端 IP 做一致性哈希
upstream myapp {
    hash $remote_addr consistent;
    server 10.0.0.11:80 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:80 max_fails=3 fail_timeout=30s;
    keepalive 32;
}

会话粘性只是最省事的做法，更彻底的是把状态外置到 Redis 或数据库，让任何一台机器都能处理任何请求。外置状态之后，两台机器就真的可以互换，双机冗余的价值才完全释放。这一步的时间成本通常是半天到一天，但它是多机方案能不能真正生效的分水岭。

五、阈值：八项验收标准，不达标就是没救回来

被攻击之后不要凭感觉判断"应该好了"，跑这八项数字。

第一项，源站不再直接暴露。用外部工具查你的域名解析出的 IP，如果解析结果里出现了你的源站 IP，说明隐藏没做成功，这是最常见的致命失误。判定标准是：域名解析出来的 IP 集合里不包含你的服务器地址。

第二项，源站防火墙只放行 CDN 回源段。在你的服务器上执行 curl -s https://你的源站IP/ 必须超时或被拒，从 CDN 节点发起的请求必须返回 200。

第三项，5 分钟内 5xx 错误率低于 1%。用 Nginx 日志统计：

awk '$9 ~ /^5/ {c++} END {print c+0}' /var/log/nginx/access.log

第四项，攻击期间正常用户的可用性。取一个真实用户路径，用 curl 从外部节点连续测 20 次，成功率必须达到 19 次以上，也就是 95% 以上。

第五项，响应时间。首字节必须小于 300 毫秒，完整页面下载 1MB 必须小于 2 秒，也就是链路至少 4Mbps：

curl -s -o /dev/null -w 'ttfb=%{time_starttransfer} speed=%{speed_download}\n' https://你的域名/

第六项，内存谷值低于 15%。用 free -m 看 used 与 total 的比值，持续高于 15% 说明还有进程在占内存，很可能是之前挂掉的攻击请求没释放完。

第七项，连接数不超过内核上限的三分之一。ss -s 显示的当前连接数，与 sysctl net.ipv4.ip_local_port_range 给出的可用端口数比，超过三分之一说明源站已经暴露在连接耗尽风险下。

查 hostwinds 在售套餐与库存

第八项，流量消耗速率回落到正常水平。用第一节那条采样命令，攻击停止后 10 秒内的增量应当回落到正常业务峰值的两倍以内。如果还在高位，说明攻击还在打，只是被 CDN 挡住了。

六、缺陷：什么情况下这套应急方案不该用

这一节写的是不适用场景。依据只取公开事实——机房位置、线路类型、计费方式、IP 资源类型、流量计费规则，不对任何商家作好坏评价。

第一种，你的站点是纯后端 API，没有静态资源可缓存。CDN 隐藏源站在这种情况下基本无效，因为 API 请求必须回源计算，CDN 只能缓存响应不能缓存逻辑。这种场景的替代方案是加硬件层面的防护产品，以及在后端做限流与幂等设计。

第二种，你的用户主要在国内，而 CDN 节点在境外。这种情况下 CDN 反而会让延迟变差，回源链路可能被绕成很长的路径。替代方案是选国内有节点的 CDN，同时保留源站的独立访问入口备用。

第三种，你用的是固定带宽并且流量超支不额外计费的套餐。有些套餐承诺的是不限流量或者超额免费，这类套餐被攻击时你的损失体现在服务商侧的滥用处理——轻则限速，重则暂停实例。这类场景下你的第一优先级不是技术手段，而是提前和服务商确认滥用政策与申诉通道。替代方案：主动报备业务性质，保留攻击期间的流量截图作为非人为滥用的证据。

第四种，攻击是应用层的 HTTP Flood，请求路径和参数完全合法。单靠 IP 限流挡不住，因为攻击者会换 IP。要挡必须做行为识别，例如同一 IP 短时间内的请求路径多样性、User-Agent 分布、Cookie 有效性。替代方案：给关键接口加验证码或登录态校验，让匿名请求无法触达业务逻辑。

第五种，你打算"用更大的带宽硬扛"。这条在数学上不成立。以 10 Gbps 攻击为例，把流量额度从 39.06 TB 提到 78.13 TB 只能把撑住时间从 546.1 分钟拉到 1092.3 分钟，而攻击者只要把强度翻倍就又回到原点。硬扛的边际收益是线性的，攻击者的边际成本也是线性的，你永远追不上。替代方案：把资源投入到清洗与限流上，而不是带宽上。

查看 interserver 当前月价与库存

第六种，你的业务允许零成本重启。纯静态展示站、活动页、下载页这类无状态业务，最省钱的方案是切换到对象存储加 CDN 的静态托管，源站压力直接归零。替代方案：用便宜的小机器只做静态分发。

七、每种攻击类型对应的具体处置流程

上面是通用手段，这一节按攻击类型给完整流程。

带宽型攻击的处置流程：第一步把域名切到 CDN，确认解析生效；第二步在安全组和 iptables 里只放行 CDN 回源段；第三步在 CDN 控制台开启防护等级，先用中等档，观察 10 分钟再决定是否提高；第四步如果攻击强度超出 CDN 免费档位且你的站点是业务核心，考虑临时切到更高防护档并观察成本；第五步恢复后，把回源段配置固化到配置管理里，不要靠手工记忆。

应用层攻击的处置流程：第一步在 Nginx 加上按 IP 的限流，rate=10r/s、burst=20、nodelay；第二步给登录、注册、下单接口加验证码或人机校验；第三步用 awk 统计攻击最集中的路径，针对性下线该接口；第四步如果攻击请求带 Cookie，直接在校验层拒绝没有有效会话的请求；第五步用 Nginx 的 limit_req_status 429 观察 429 数量，如果 429 占比超过 95%，说明限流层已经接管，业务层压力应该已经解除。

SYN Flood 的处置流程：第一步开启 SYN Cookie，sysctl -w net.ipv4.tcp_syncookies=1 并写进 /etc/sysctl.conf；第二步调大队列，sysctl -w net.ipv4.tcp_max_syn_backlog=65536、sysctl -w net.core.somaxconn=65535；第三步如果云厂商支持，直接申请更高层的清洗，而不是自己调参数；第四步观察 cat /proc/net/synrecv 的长度，攻击结束后应当回落到个位数。

查看 itldc 当前月价与库存

连接耗尽的处置流程：第一步扩大端口范围，sysctl -w net.ipv4.ip_local_port_range="1024 65535"；第二步缩短 TIME_WAIT 停留，sysctl -w net.ipv4.tcp_fin_timeout=15、sysctl -w net.ipv4.tcp_tw_reuse=1；第三步前面挂 Nginx 或 HAProxy 做连接复用，让源站只维持后端到前端的少量长连接；第四步检查是否被打了带源 IP 的连接，及时在安全组限流。

八、预防：把成本前置到攻击之前

被攻击之后才发现自己扛不住，最贵的不是流量账单，是这几周的订单流失。四个预防动作按性价比排序。

第一，做一次流量审计。用 vnstat 或者云厂商的流量统计，拉出过去 90 天的日流量曲线，找到你的峰值和峰值的出现时段。把这个峰值乘以 2，作为你至少要能扛住的攻击强度：

vnstat --days
vnstat --hours

有了这个数字，你的套餐选择才不是拍脑袋。以 10 Gbps 为例，你需要的月流量额度至少是 39.06 TB，也就是至少要有一台 39 TB 流量档的机器。

第二，把源站藏好这件事做成常态。永远让 DNS 解析指向 CDN 而不是源站，源站 IP 只在服务器内部使用。这一步花不了一小时，但它能把 90% 的攻击流量挡在门外。

第三，准备一个备用机器。用最低配的月付机型就够，平时空跑着，攻击时把解析切过去。很多人是在被打了之后才第一次去开通备用机器，那时候要走开通、初始化、加 SSH 密钥、改 DNS，至少两小时，而这两小时里站点是全挂的。提前准备好，切换时间可以压缩到 10 分钟以内。

第四，给攻击做告警。流量用量超过月度配额的 60% 告警，超过 80% 再告警一次；源站入向带宽超过 100Mbps 告警；5xx 错误率超过 5% 告警。这三条里任何一条触发，就该去看是不是被攻击了。

第五，做一次模拟演练。找个低峰时段，自己用压测工具向自己的机器打 1 Gbps 的流量，观察十分钟，确认告警真的会响、CDN 确实在挡、限流规则确实生效。演练的收益在于把"配置正确"和"配置有效"区分开——很多团队的限流规则写错了却从未验证，直到真被攻击时才发现。演练时提前把 TTL 降到 60 秒，这样万一打到自己还能快速恢复。

查 spinservers 在售套餐与库存

第六，把源站 IP 视为机密。源站 IP 不写进任何前端代码、不出现在图片链接里、不放在 DNS 记录的历史截图里。很多团队是长期运营后才被翻出来的：一张含源站 IP 的旧截图发在论坛，一封带服务器地址的邮件进了垃圾箱，都足够让攻击者拿到目标。

九、被攻击后的取证清单，这些东西决定你能不能追责

技术处置和取证是两件事，很多人只做前者，结果攻击者被查到后什么证据都没有，损失只能自己扛。攻击发生后 24 小时内的取证清单如下。

第一类是流量证据。立即开始抓包并存档，这是最关键的证据：

tcpdump -i eth0 -w /var/tmp/ddos-$(date +%Y%m%d-%H%M).pcap -C 1000

抓包文件大小限制在 1000MB，避免撑爆磁盘。抓到之后立刻复制到另一台机器上，不要留在被攻击的服务器上。

第二类是日志证据。完整保存攻击时段前后的 Nginx 访问日志、系统日志、以及任何监控截图。日志的时间戳要能对上，用 UTC 统一时区，避免不同机器时区不一致导致证据链断裂。

第三类是服务商记录。向你的 VPS 商家和 CDN 服务商索取该时段的流量统计和滥用处理记录，这些是第三方出具的证明，比你自己截的图有力得多。

第四类是攻击特征归纳。写清楚攻击类型、峰值带宽、来源网段分布、被打的路径特征、开始和结束时间。这份归纳有两个用途，一是给服务商做申诉依据，二是如果要做民事诉讼或报案，它是核心证据材料。

第五类是损失计算。把攻击时段的流量账单、订单损失、客服工单量整理成一张表。这张表在跟商家谈判减免、在报案时主张损失、在起诉时作为赔偿依据时都要用。

zenlayer 官网机型与实时报价

留存时限要注意。多数司法与行政程序要求在知道侵权行为后两年内主张权利，但网络日志的可获取性随时间迅速下降，实际经验是攻击发生后一周内固定证据最稳妥，超过一个月，很多日志已经被覆盖轮转掉了。

十、选型：按你的抗攻击需求倒推机型

最后把前面的结论落到具体机器上。判断依据是流量额度与超额规则这两条公开事实。

查 justg 在售套餐与库存

选型时有两点必须纳入考虑。第一，别忘了超额倍率：云途 HK.DS.S 套餐内每 TB 20.48 元，超额重置 500 元每 TB，倍率 24.4 倍；HK.DS.M 套餐内 35.84 元每 TB，超额 200 元每 TB，倍率 5.6 倍。如果你的业务流量曲线有明确的峰值和低谷，倍率低的那款在峰值期更省钱。第二，多机冗余比单机升级更抗打，两个 39 TB 流量的机器在 10 Gbps 下能撑 1092.3 分钟，等于多扛了 9 小时，而同样的钱买单机大配置流量额度不会变。

还要注意一条容易被跳过的规则：如果你所在行业的攻击有明显的时段性——比如竞品在促销日发起攻击——那么机型的月流量额度应该按峰值月而不是月均值来定。流量额度是自然月重置的，攻击发生在哪个月就在哪个月消耗，不存在跨月累积。这意味着你在四月遭遇的攻击会消耗四月的额度，五月的额度不受影响，这是配额制相对于按秒计费的清洗服务的一个隐性优势：被攻击的损失被隔离在单个月份内。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 iwebfusion 当前机型与价格
• 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 racknerd 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十一、常见问题

我的 VPS 被打挂了，是不是一定要买高防？ 不一定。先看攻击类型：如果是 L3/L4 带宽型，CDN 加源站隐藏通常就能解决，成本接近零；如果是 L7 应用层，限流加验证码通常也能解决。只有当攻击强度远超单节点的清洗能力、且你的业务不能中断时，才需要考虑付费的高防产品。

我的站点只有几十个用户，有必要防 DDoS 吗？ 有必要，但目的不是保护收入，是保护可用性。你的站点如果是某个项目的落地页、或者给合作方看的演示环境，一次 DDoS 就可能让合作方认为项目不可靠。成本最低的做法是加 CDN，把源站藏好，一次配置长期有效。

CDN 开了以后源站 IP 还是被打，是哪里做错了？ 三种可能。一是你在别处还留了源站 IP 的 DNS 记录，比如测试环境、旧邮箱配置、旧子域名；二是安全组放行了 0.0.0.0/0 段而不是只放行 CDN 回源段；三是攻击者早就记录了你的源站 IP，在你切 CDN 之前就已经在打。用外部工具查历史解析记录就能确认。

攻击流量把月流量打光了，账单怎么算？ 按各套餐的规则来。云途系列在商品库里明确了超额流量重置价，HK.DS.M 是 200 元每 TB，HK.DS.S 和 HK.DS.P 是 500 元每 TB，DS.ES.B 是 450 元每 TB。其余套餐的商品库没有记录超额条款，以官网当日报价为准，建议直接向商家工单确认。

被打的时候应该主动停站吗？ 多数情况下不应该。主动停站只是让攻击者少打一点，你的业务还是一样不可用，而且损失从"网站慢"变成"网站没了"。正确做法是把资源全部投入防守：限流、关非核心功能、切 CDN。

怎么判断攻击已经停了？ 三个信号同时出现才算停：入向流量回落到正常峰值的 2 倍以内、5xx 错误率低于 1%、外部探测连续 20 次全部成功。只要还有一个没恢复，就不要宣布结束。

DDoS 防护的服务器一般是怎么收费的？ 常见结构是基础月费加按流量或按攻击清洗量计费，部分提供按天包天的临时防护方案，适合已经被打、需要立刻扛几天的情况。价格以官网当日报价为准，选购前重点看两点：防护带宽上限是多少，超出后的处理方式是什么。

小站有没有必要自己写防攻击脚本？ 有价值，但优先级排在最后。前面几件做完之前写脚本的收益很低：没有 CDN 就没有清洗，写脚本只是让源站少处理一点无效请求；流量配额被打满时脚本救不了你。正确的顺序是 CDN、源站隐藏、限流、多机冗余，最后才是脚本。