电商网站遭遇DDoS攻击时，最直接的后果不是带宽被占满，而是交易流程被切断。攻击者通常选择结算页、支付回调接口、库存查询接口作为目标，因为这些环节一旦中断，用户无法完成下单，订单状态无法同步，甚至会出现“已扣款但订单未生成”的严重故障。对于电商运营者来说，DDoS防护的核心指标不是“扛住了多少G流量”，而是“攻击期间交易成功率下降了多少”。

从攻击手法看，针对电商的DDoS已经高度场景化。攻击者会模拟真实用户的加购、下单、支付请求，混合在正常流量中打向交易接口。这类应用层攻击的单个请求完全合法，传统基于流量阈值的防护设备很难识别。更麻烦的是，大促期间电商平台自身的正常流量就会飙升数倍，攻击流量混在其中更难分辨。因此，电商DDoS防护必须从交易链路的角度重新设计，而不是简单堆叠带宽清洗能力。

交易链路的脆弱点在哪里

一个典型的电商交易链路包含以下关键节点：商品详情页、库存查询、购物车、订单创建、支付请求、支付回调、订单状态更新。这些节点中，库存查询和订单创建是计算资源消耗最大的环节。每次库存查询都可能触发数据库读写，每次订单创建都要写入多个数据表并调用风控接口。攻击者只要持续向这两个接口发送请求，即使请求不完整，也能迅速耗尽后端资源。

支付回调接口则是另一个高危点。很多电商系统对支付回调的验签逻辑复杂，涉及与第三方支付平台的通信。攻击者可以伪造大量回调请求，迫使系统反复进行验签和查询操作。一旦回调处理队列堆积，正常支付的订单无法及时确认，用户就会看到“支付成功但订单待确认”的异常状态，进而引发大量客诉和退款。

基于交易场景的防护策略

第一层防护是交易接口的准入控制。对库存查询、订单创建、支付回调这类高消耗接口，必须启用严格的频率限制和行为校验。例如，同一个用户会话在短时间内只能发起有限次库存查询，订单创建接口必须携带有效的CSRF Token和会话签名。对于支付回调，除了验签之外，还应校验回调来源IP是否在第三方支付平台公布的IP段内。这些措施虽然不能完全阻止攻击，但可以大幅提高攻击成本。

第二层是异常流量识别。电商平台需要建立交易基线模型，记录每个时段正常的下单量、支付量、库存查询量。当某个接口的请求量突然偏离基线超过阈值时，触发告警并自动切换至防护模式。防护模式下，系统可以对可疑请求进行人机验证，或者将请求导入独立的验证池进行延迟处理。关键是这个切换必须足够快，最好在秒级完成，否则攻击已经造成影响。

第三层是资源隔离。将交易核心服务与商品展示、内容浏览等非核心服务进行物理或逻辑隔离。即使攻击者打垮了商品详情页的服务器，交易服务仍然可以正常运行。很多电商平台已经采用微服务架构，但服务之间的依赖关系仍然复杂。需要重点检查交易服务是否依赖其他服务的可用性，例如订单创建是否依赖会员服务的同步调用。如果存在强依赖，攻击者可以通过打垮会员服务间接瘫痪交易。

大促期间的动态防护

大促期间电商平台面临的DDoS攻击规模往往是平时的数十倍，而且攻击时间点高度集中。此时的防护策略需要从静态防御转向动态调整。一方面要提前扩容交易链路的各个节点，确保有足够的冗余资源吸收攻击流量。另一方面要准备多套降级方案，当某个环节被攻击时，可以快速切换到备用路径。

一个实用的做法是设置交易熔断机制。当订单创建接口的失败率超过预设阈值时，自动触发熔断，暂时拒绝新的订单请求，同时保留已进入流程的订单继续处理。这听起来像是主动放弃交易，但实际上比让整个系统崩溃要好得多。熔断期间可以展示“系统繁忙，请稍后再试”的提示，并引导用户稍后重试。配合消息队列，熔断期间用户提交的订单请求可以先进入队列排队，待系统恢复后再异步处理。

对于支付环节，大促期间应启用支付结果异步确认机制。用户支付完成后，支付平台异步通知电商系统，电商系统将确认任务放入队列，由后台任务逐步处理。这样即使支付回调接口被攻击，也不会影响正常支付结果的最终确认。用户端可以显示“支付处理中，请稍后查看订单状态”，避免用户重复支付。

技术层面的具体实现

在Web服务器层面，Nginx和OpenResty可以通过Lua脚本实现精细的访问控制。以下是一个针对订单创建接口的限流示例：

location /api/order/create {
    access_by_lua_block {
        local limit = ngx.shared.limit_req
        local key = ngx.var.remote_addr .. ngx.var.http_user_agent
        local req_count = limit:get(key) or 0
        
        if req_count > 10 then
            ngx.status = 429
            ngx.say('{"code":429,"msg":"请求过于频繁"}')
            ngx.exit(429)
        end
        
        limit:incr(key, 1)
        if req_count == 0 then
            limit:expire(key, 60)
        end
    }
    proxy_pass http://order_service;
}

这段代码的作用是限制每个IP地址结合User-Agent在60秒内最多请求10次订单创建接口。实际部署时需要根据业务情况调整阈值，并且要考虑到移动端用户可能共享出口IP的情况。更精细的做法是结合用户登录态进行限流，对未登录用户和已登录用户设置不同的阈值。

在应用层，可以使用Redis实现分布式限流。对于库存查询这类高频接口，可以采用令牌桶算法。每个用户会话维护一个令牌桶，桶的容量和填充速率根据用户行为动态调整。正常用户浏览商品时，令牌消耗速度平稳；攻击脚本发起大量查询时，令牌很快耗尽，后续请求被直接拒绝。

对于支付回调接口的防护，除了验签之外，还可以增加时间戳校验和随机数防重放。以下是一个简化的验签逻辑示例：

public boolean verifyCallback(Map params, String signature) {
    // 1. 校验时间戳，防止过期请求
    long timestamp = Long.parseLong(params.get("timestamp"));
    long now = System.currentTimeMillis();
    if (Math.abs(now - timestamp) > 300000) {
        return false; // 超过5分钟的请求视为无效
    }
    
    // 2. 校验随机数，防止重放攻击
    String nonce = params.get("nonce");
    if (redis.exists("callback_nonce:" + nonce)) {
        return false; // 该随机数已处理过
    }
    redis.setex("callback_nonce:" + nonce, 600, "1");
    
    // 3. 验签
    String expectedSign = generateSign(params, secretKey);
    return expectedSign.equals(signature);
}

这段代码展示了支付回调验签的三个关键步骤：时间戳校验、随机数防重放、签名验证。实际生产环境中还需要增加IP白名单校验和金额一致性校验，确保回调中的金额与订单金额完全一致。

监控与应急响应

DDoS防护不是一劳永逸的事情，必须配合完善的监控体系。电商平台需要实时监控交易链路的各项指标：订单创建成功率、支付回调处理延迟、库存查询响应时间、数据库连接池使用率。当这些指标出现异常波动时，即使没有触发DDoS告警，也应该立即进入应急状态。

建议建立分级响应机制。一级响应：某个交易接口响应时间超过正常值2倍，持续5分钟，此时运维人员介入排查。二级响应：订单创建成功率下降超过10%，或支付回调延迟超过30秒，此时启动限流和降级措施。三级响应：交易核心服务不可用，此时切换至备用集群，并启动熔断机制。每一级响应都要有明确的触发条件和执行动作，避免在紧急情况下手忙脚乱。

应急响应中最重要的原则是保交易。当资源有限时，优先保障订单创建和支付确认这两个环节。商品浏览、搜索、推荐等功能可以暂时降级甚至关闭。很多电商平台在遭受大规模攻击时，会主动关闭非核心功能，将全部资源集中到交易链路。这种做法虽然影响用户体验，但能最大程度减少交易损失。

电商DDoS防护的本质是保障交易连续性。攻击者的目标不是让网站完全打不开，而是让用户无法完成购买。因此，防护措施必须围绕交易链路展开，从接口准入、流量识别、资源隔离到动态降级，每个环节都要考虑对交易的影响。只有把DDoS防护与交易保障结合起来，才能真正做到在攻击中维持业务稳定。