网站遭遇DDoS攻击时应急响应流程与节点切换策略

服务器突然打不开，流量监控图上的曲线像坐了火箭一样往上窜，带宽瞬间被塞满，正常的用户请求全部被淹没。这就是DDoS攻击，它不需要攻破你的防火墙，不需要窃取你的密码，它只需要用海量的垃圾流量把你的服务器活活撑死。遇到这种情况，你第一件要做的事不是去查是谁攻击你，也不是去优化代码，而是立刻进入应急响应流程，同时准备执行节点切换策略，把业务损失降到最低。

登录服务器的第一件事不是看日志，而是用命令行快速看一眼当前的网络连接状态。执行 netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20 这条命令，它会告诉你当前哪些IP地址建立的连接数最多。如果看到某个或某几个IP有数百甚至上千个连接，那很可能是攻击源。但更多时候，你看到的不是单一IP，而是成千上万个不同的IP，每个IP只有寥寥几个连接，这就是典型的分布式拒绝服务攻击。此时再用 iftop 或者 nload 这类工具看一下实时带宽占用情况，如果带宽已经跑到上限，说明攻击流量已经塞满了你的网络出口。同时用 top 或者 htop 查看CPU和内存使用率，判断攻击是否已经导致服务器资源耗尽。这一步必须在三分钟内完成，目的是搞清楚攻击的规模、类型和当前服务器承受的压力程度。

确认遭受攻击后，不要犹豫，立刻在服务器层面执行基础的流量限制策略。如果你用的是Linux服务器，iptables 是最直接的武器。执行 iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j DROP 这条规则会限制单个IP对80端口的并发连接数不超过50个，超过的直接丢弃。但这只是权宜之计，对于大规模的DDoS攻击，iptables 规则本身就会消耗大量CPU资源。更有效的做法是执行临时性的SYN Cookie防护，通过 sysctl -w net.ipv4.tcp_syncookies=1 开启SYN Cookie，同时调整 net.ipv4.tcp_max_syn_backlog 的值，减少SYN半连接对系统资源的占用。如果你使用的是Nginx作为Web服务器，立刻修改配置，增加 limit_req_zone 和 limit_conn 模块的限制参数，设置合理的请求频率和并发连接数上限，然后执行 nginx -s reload 平滑重启。这些操作虽然不能完全阻挡大规模攻击，但能为你争取到宝贵的决策时间，防止服务器瞬间宕机。

服务器层面的防护在大流量攻击面前基本是杯水车薪。当你发现入向流量已经超过1Gbps甚至更高时，必须立刻联系你的机房运维或者IDC服务商，要求他们启动流量清洗服务。你需要准确告诉他们被攻击的目标IP、攻击流量的特征以及当前的带宽占用情况。大部分正规的IDC都具备基础的流量清洗能力，他们会在骨干网络层面通过BGP路由将流量牵引到清洗中心，过滤掉明显的攻击流量后再将正常流量回注到你的服务器。这个过程通常需要5到15分钟才能生效。在等待清洗生效的这段时间里，你的服务器可能仍然处于无法访问的状态，这时候你需要做出一个关键决策：是继续硬扛等待清洗完成，还是立即执行节点切换。

节点切换不是简单的换个IP地址，而是一套需要提前规划好的战术动作。它的核心思想是：当主节点遭受攻击导致不可用时，将业务流量快速切换到备用节点上，同时将被攻击的IP地址从业务体系中暂时剥离。这个策略能否成功，取决于你事先是否做好了以下准备：第一，备用节点的服务器环境必须与主节点保持实时同步，包括代码版本、数据库内容、静态文件等。第二，备用节点必须具备独立的IP地址段，且该IP段没有被暴露在公开的DNS记录或业务接口中。第三，DNS解析的TTL值必须提前设置为较低的值，通常建议在遭受攻击前就将TTL调整为300秒甚至更低，这样切换节点后解析生效的延迟才会足够短。如果你等到攻击发生时才去改DNS的TTL，那缓存生效的时间可能长达几个小时，切换就失去了意义。

当你决定切换节点时，第一步是修改DNS解析记录，将域名的A记录指向备用节点的IP地址。如果你的DNS服务商支持API调用，建议提前写好切换脚本，实现一键切换。脚本内容大致如下：

#!/bin/bash
# 使用云解析服务商的API修改A记录
curl -X POST "https://dns.api.com/record/update" \
-H "Authorization: Bearer your_api_token" \
-d "domain=example.com&type=A&value=备用节点IP&ttl=300"

执行完DNS切换后，立刻登录主节点服务器，执行 iptables -A INPUT -j DROP 或者直接关闭主节点的公网网卡，让主节点从公网彻底消失。这一步很重要，因为攻击者可能已经知道了你的备用节点IP，如果你不把主节点下线，攻击流量可能会转向攻击你的备用节点。同时，检查备用节点的负载情况，确保它能够承接所有正常的业务流量。如果备用节点也出现负载过高的情况，需要立即在备用节点上执行前面提到的iptables和Nginx限流策略，优先保证核心业务的可用性。

如果你的业务架构中已经接入了CDN或者反向代理服务，节点切换的难度会大幅降低。以CDN为例，你的源站IP地址隐藏在CDN节点后面，攻击者只能看到CDN的IP地址。当CDN节点遭受攻击时，CDN服务商通常会自动进行流量分散和清洗，你几乎不需要做任何操作。但如果攻击流量大到连CDN服务商都扛不住，或者攻击者通过某种方式获取了你的源站真实IP并直接攻击源站，你就需要执行源站IP的切换。这时候的操作是：在CDN控制台中修改源站配置，将源站地址指向备用节点IP，然后CDN会自动将请求转发到新的源站。对于使用Nginx反向代理的架构，你可以在反向代理层配置多个上游服务器，并设置健康检查。当主节点不可用时，Nginx会自动将流量切换到备用节点，配置示例如下：

upstream backend {
    server 主节点IP max_fails=3 fail_timeout=30s;
    server 备用节点IP backup;
}
server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_connect_timeout 3s;
        proxy_read_timeout 3s;
    }
}

这种架构的优势在于，切换过程对用户完全透明，不需要等待DNS生效，故障转移在秒级完成。但前提是你的反向代理服务器本身没有被攻击波及。

节点切换不仅仅是Web服务层的切换，数据库和缓存层的同步与切换同样关键。如果你的主节点和备用节点共用同一个数据库实例，那么数据库本身就是一个单点故障风险。在遭受DDoS攻击时，数据库的连接数可能会被异常的查询请求打满，导致即使Web服务恢复了，数据库也无法正常响应。因此，建议在备用节点部署独立的数据库从库，并配置好主从同步。切换时，需要将备用节点的数据库从库提升为主库，或者至少确保备用节点的应用能够读取到最新的数据。对于Redis这类缓存服务，同样需要在备用节点部署独立的实例，并提前将热点数据预热进去。如果切换过程中发现缓存命中率骤降，不要慌张，这是正常现象，可以在备用节点上临时关闭缓存穿透保护机制，让请求直接穿透到数据库，同时密切监控数据库的负载情况。

当攻击流量消退，IDC的流量清洗报告显示攻击已经停止，或者你通过监控工具确认入向流量恢复正常水平后，不要立刻把流量切回主节点。先让备用节点继续运行一段时间，观察是否还有残留的攻击流量。同时，登录主节点服务器，检查系统日志、应用日志和网络连接记录，分析攻击者是否在服务器上留下了后门或者恶意程序。使用 last 命令查看登录记录，用 find / -mtime -1 查找最近一天内被修改过的文件，用 netstat -tlnp 确认是否有异常的端口在监听。确认主节点完全安全后，再选择一个业务低峰期，通过修改DNS记录或者调整反向代理配置，逐步将流量迁回主节点。迁回的过程建议采用灰度策略，先切10%的流量观察一段时间，确认无异常后再全部切回。最后，必须对整个事件进行复盘，回答几个核心问题：攻击者是如何找到你的真实IP的？你的DNS配置是否存在信息泄露？备用节点的切换时间是否达到了预期目标？流量清洗的效果如何？根据复盘结果，调整你的网络架构和安全策略，比如增加多层代理隐藏源站、使用Anycast技术分散流量、与IDC签订更高级别的防护协议等。

一次成功的应急响应和节点切换只是解决了当下的危机，要真正降低DDoS攻击的威胁，必须从架构层面进行改造。首先，永远不要将你的源站真实IP暴露在公网上。所有DNS的A记录都应该指向CDN或者高防IP，源站只允许CDN的回源IP地址访问，在iptables或者安全组中严格限制入站流量的来源。其次，业务系统应该采用多节点、多机房的分布式部署架构，利用智能DNS解析或者全局负载均衡，将用户请求分散到不同的节点上。这样即使单个节点遭受攻击，其他节点仍然可以正常服务。再次，建立完善的监控告警体系，对带宽使用率、连接数、请求频率等关键指标设置阈值告警，一旦触发告警，自动执行预设的防护脚本，甚至自动触发节点切换。最后，定期进行攻防演练，模拟不同类型的DDoS攻击，检验团队的响应速度和切换流程的有效性。只有把应急响应变成肌肉记忆，当真正的攻击来临时，你才能做到从容不迫。