中小电商DDoS云防护低成本落地方案

中小电商做DDoS防护，最大的问题不是不知道要防，而是预算根本撑不起传统高防机房动辄几万一个月的报价。一台普通的BGP高防IP，100G防护峰值月付可能就要三五千，这还只是单IP。电商站点通常有主站、API、图片静态资源、后台管理多个入口，全上高防一年下来十几万很正常。对日订单几百单、毛利十几个点的店铺来说，这笔账算不过来。所以真正能落地的方案，核心不是堆防御峰值，而是把“必须高防的资产”和“可以低成本兜底的资产”拆开，再用云厂商的按量计费能力把固定成本压到最低。

先说清楚一个基本判断：中小电商遇到的DDoS，绝大多数不是那种持续数百G的饱和攻击，而是短时间几十G的脉冲式攻击，或者夹杂CC的混合流量。攻击者的目的往往不是彻底打死服务器，而是让站点卡顿、支付中断、触发平台处罚。这种攻击特征决定了你不需要全年买满配高防，而是需要一套能在攻击发生时快速切换、按小时甚至按天计费的防护组合。把防护当成“保险”而不是“基建”，成本就能降下来。

很多中小电商的站点架构是“一台云主机跑全部”，首页、商品图、购物车、支付回调全在一起。这种架构下，一旦被打，所有功能同时瘫痪，而且你不得不给这台主机上高防。更经济的做法是：商品图片、CSS、JS全部迁到对象存储加CDN，主站和API回源到一台低配云主机，后台管理单独一个子域名并做IP访问限制。这样DDoS打到CDN层面时，对象存储和CDN服务商自带的基础防护就能吸收大部分流量，你的源站IP不需要暴露。CDN的按流量计费在平时很便宜，攻击时产生的流量费虽然会涨，但比买固定高防带宽划算得多。

国内主流云厂商现在都有DDoS防护的按量计费或者弹性防护包。比如基础防护免费给到5G到20G，超过部分可以开启弹性防护，按天或者按攻击峰值计费。你平时不开启或者只开最低档，遇到攻击时手动或自动切换到高防线路。切换过程会有几分钟中断，但对中小电商来说，几分钟的不可用比每月多花几千块更容易接受。关键点是提前把DNS的TTL调短，最好在60秒以内，这样切换高防IP后解析能快速生效。同时准备好备用域名或者备用线路，主站被打时把流量切到备用入口，哪怕备用入口只是个静态公告页，也能保住支付通知和客服沟通的通道。

DDoS里最难防的不是流量型，而是CC攻击。攻击者模拟真实用户请求，打你的搜索接口、下单接口、验证码接口，把数据库连接池和CPU耗尽。这种攻击流量不大，但危害极强。低成本方案是在源站前面加一层开源的Nginx或者OpenResty，配合Lua脚本做频率限制和IP黑名单。比如同一个IP在5秒内请求搜索接口超过10次就直接返回403，同一个设备指纹在1分钟内尝试下单超过3次就弹验证码。这些规则不用买商业WAF，自己写几十行配置就能实现。下面是一段Nginx限制单IP访问频率的示例配置：

# 在http段定义限流区域
limit_req_zone $binary_remote_addr zone=search_limit:10m rate=2r/s;
limit_req_zone $binary_remote_addr zone=order_limit:10m rate=1r/s;

# 在server段应用限流
location /api/search {
    limit_req zone=search_limit burst=5 nodelay;
    proxy_pass http://backend;
}

location /api/order/create {
    limit_req zone=order_limit burst=3 nodelay;
    proxy_pass http://backend;
}

这段配置把搜索接口限制为单IP每秒2次请求，突发最多5次；下单接口限制为每秒1次，突发最多3次。对于正常用户来说完全够用，对于CC攻击工具来说，大部分请求会被直接拒绝，后端压力骤降。如果攻击者换了大量代理IP，再配合一个简单的IP信誉库或者让前端页面加载一段JavaScript验证，就能过滤掉大部分低端攻击工具。

DDoS打到后面，压力一定会传导到数据库。中小电商常用的MySQL或者PostgreSQL在连接数被打满后，整个站点就彻底不可用。低成本的做法是在应用层和数据库之间加一层Redis缓存，把商品详情、分类列表、库存查询这些高频读操作全部缓存起来，数据库只处理写操作和缓存未命中的情况。Redis本身是单线程内存模型，抗并发能力远超关系型数据库。同时给数据库连接池设置合理的最大连接数和超时时间，避免慢查询堆积。如果预算允许，把数据库放到云厂商的RDS服务上，利用其自带的基础防护和自动备份能力，比自己维护裸数据库省心很多。

防护做得再好，如果攻击来了你还在睡觉，等第二天发现订单全丢，那前面都白做。所以必须有一套简单的监控和自动切换机制。中小电商不需要复杂的可观测性平台，用云监控加一个Shell脚本就能实现。思路是：每分钟检查一次主站HTTP状态码和响应时间，如果连续3次超时或者返回5xx，就调用云厂商的API把DNS解析切换到备用高防IP，同时发短信或者企业微信通知。下面是一个简化的检查脚本示例：

#!/bin/bash
# 检查主站可用性，失败则切换DNS
URL="https://www.example.com"
CHECK_COUNT=0
for i in 1 2 3; do
    STATUS=$(curl -o /dev/null -s -w "%{http_code}" --connect-timeout 5 --max-time 10 "$URL")
    if [ "$STATUS" == "200" ]; then
        CHECK_COUNT=$((CHECK_COUNT+1))
    fi
    sleep 10
done

if [ "$CHECK_COUNT" -lt 2 ]; then
    # 调用云厂商API切换DNS到高防IP
    curl -X POST "https://dns.api.example.com/switch" \
         -H "Authorization: Bearer YOUR_TOKEN" \
         -d '{"domain":"www.example.com","ip":"高防IP地址"}'
    # 发送告警通知
    curl -X POST "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY" \
         -H "Content-Type: application/json" \
         -d '{"msgtype":"text","text":{"content":"主站异常，已切换高防IP"}}'
fi

这个脚本逻辑很简单，但实际效果很好。关键是提前把备用高防IP准备好，并且测试过切换流程。很多电商的教训是：攻击来了才发现备用方案没验证过，切换过去发现证书不对、数据库连不上、CDN回源配置错误，结果比不切换还糟。所以切换方案一定要在平时演练至少一次。

中小电商很多流量来自电商平台或者社交渠道，这些平台本身有流量清洗能力。如果你的店铺页面被打，可以第一时间联系平台客服，说明情况，平台通常会给店铺页面加一层临时防护或者把流量引导到平台自己的高防节点。同时，如果你用的是SaaS建站工具或者托管电商平台，它们的防护能力往往比你自己买高防要强，因为平台可以聚合多个商家的流量做统一清洗。所以不要一上来就自建独立站，先评估平台托管方案能不能满足需求。对于独立站，也可以考虑接入第三方的免费或低价CDN，比如一些国内CDN服务商提供基础DDoS防护的免费套餐，虽然峰值不高，但配合前面的限流和缓存策略，能挡住大部分中小规模攻击。

以一个日均UV五千、日订单两百的中小电商为例：对象存储和CDN按流量计费，平时一个月大概两三百元；云主机用4核8G的配置，月付三百到五百元；Redis和RDS用最低配，加起来一个月两百元左右；弹性高防平时不开，遇到攻击按天开启，假设一个月遇到两次攻击，每次开三天，按100G峰值计费，大概花费五百到八百元；监控脚本和自动化切换用云函数或者一台最低配的轻量服务器，一个月几十元。总计下来，固定成本一个月一千出头，攻击时的额外成本控制在千元以内。相比传统方案动辄三五千的固定高防费用，这套方案能把总成本压到三分之一甚至更低，而且防护效果并不差。

最后强调一个容易被忽略的点：DDoS防护不是一次性配置完就结束了。攻击者的手法在变，你的业务也在变。每个月花半小时检查一下日志，看看有没有新的攻击特征，更新一下限流规则和黑名单，比买再贵的防护设备都管用。中小电商的资源有限，把精力花在“攻击发生时能快速响应”上，比追求“永远打不死”更现实。