Hostease 独立服务器遇到大流量攻击时，先处理业务连续性再谈拦截

很多团队在独立服务器遇到 DDoS（分布式拒绝服务攻击）时，第一反应是急着调防火墙、配黑洞路由，结果核心业务还是崩了。因为大流量攻击带来的问题不只是带宽（网络传输容量的上限）被打满，而是连带影响管理后台、数据库连接、监控告警和客服入口。这篇文章帮助你梳理 DDoS 应急响应的正确优先级：先保证核心服务还能工作，再进入拦截和清洗阶段。

大流量攻击的第一个小时该做什么

攻击发生后的前 60 分钟是最关键的窗口期。这个时候团队往往处于混乱状态，信息不完整、影响范围不确定、管理层在问”能不能先顶住”。正确的做法是按以下顺序处理：

1. 确认攻击类型和影响范围：用 `netstat -an | grep ESTABLISHED | wc -l` 快速查看连接数，`iftop` 或 `vnstat` 查看实时带宽（网络传输容量的上限）占用。判断是 SYN flood、UDP flood、HTTP flood 还是混合型攻击
2. 保护核心业务入口：优先保证首页、登录入口、管理面板和关键 API（应用程序接口）可访问。用 iptables 临时限制非必要端口的入站流量，把带宽（网络传输容量的上限）让给核心服务
3. 通知相关方：告知团队攻击情况、当前影响和应对措施。如果是商业站点，客服需要提前准备用户安抚话术
4. 联系机房支持：提交工单说明攻击类型和规模，请求上游清洗或临时黑洞策略

关键原则是：先让核心服务能跑，再全面拦截。把所有流量都挡掉看似安全，但如果业务已经彻底中断，拦截本身就没有意义。

一个常见的误区是在攻击初期就启用全局限速，试图”平均分配”资源。实际上这会让核心 API 和外围静态资源抢同一份带宽（网络传输容量的上限），反而拖垮了本该优先保护的服务。正确的做法是先分层、再限速——对不同服务设置差异化阈值，让核心通道获得绝对优先权。

核心业务与非核心服务的分层

DDoS 应急响应的核心思路是分层保护，不是全量拦截。把业务分成三层：

• 核心层（必须保住）：首页、登录/注册、关键 API 端点、管理后台。这些服务中断直接影响营收和用户信任
• 支撑层（尽量保住）：搜索功能、用户中心、数据导出。这些中断不影响核心流程，但会降低体验
• 外围层（可以暂时牺牲）：静态资源 CDN 回源、图片上传、非关键后台功能。攻击期间临时关闭这些服务可以释放大量带宽（网络传输容量的上限）和连接数

分层之后，你在 iptables 里可以用以下策略快速实现：

// 临时放行核心端口
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j DROP
iptables -A INPUT -p tcp --dport 443 -m connlimit --connlimit-above 50 -j DROP
// 临时封锁非必要端口
iptables -A INPUT -p tcp --dport 3306 -j DROP
iptables -A INPUT -p tcp --dport 8080 -j DROP

这样在攻击高峰期，核心服务仍然有带宽（网络传输容量的上限）可用，而非核心服务暂时牺牲。关于 DDoS 防护边界的更深入讨论，可以参考同价位主机在 DDoS 防护能力上的差异对比。

机房支持能做什么，不能做什么

很多站长以为提交工单后机房就能立刻解决问题，但实际响应链路是这样的：

1. 机房收到工单后通常 15-30 分钟内开始排查
2. 确认攻击类型和规模后，会根据你的套餐决定是否启用上游清洗
3. 如果攻击流量超过清洗能力上限，机房可能对目标 IP 做临时黑洞（所有流量丢弃），直到攻击减弱
4. 黑洞期间你的服务器对外完全不可达，需要等待机房解除

这意味着：你不能完全依赖机房。在机房响应之前的 15-30 分钟，你的服务器状态完全取决于你自己的应急准备。

另外一个经常被忽略的细节是：机房的黑洞策略一旦生效，你的服务器就变成了”孤岛”——不仅外部用户无法访问，连你自己的 SSH 连接也可能被切断。所以在提交工单之前，务必确认你有备选管理通道（比如带外管理 IP 或 KVM over IP），否则一旦进入黑洞你连服务器都无法操作了。

在美国服务器租用选购指南中可以看到独服选型的完整指标体系，DDoS 防护能力也是其中关键一项。

攻击前必须做好的五项准备

如果你的独立服务器承载的是正式业务，以下准备应该在攻击发生之前就做好：

• 基础监控和告警：安装 Prometheus + Grafana 或 Netdata，设置 CPU、带宽（网络传输容量的上限）和连接数阈值告警。不要等到用户投诉才发现服务器被打了
• 访问日志归档：确保 Nginx/Apache 的 access_log 和 error_log 定期归档。攻击后需要分析日志才能确定攻击类型和来源
• 关键服务分层：提前用 iptables 或云防火墙分好核心/支撑/外围三层，攻击时只需激活预设规则
• 备选访问入口：配置一个备用域名或 CDN（内容分发网络）入口，主站被打时团队仍能通过备用通道访问管理面板
• 应急分工文档：明确谁负责监控、谁负责联系机房、谁负责通知用户。攻击时临时分工是最常见的失误

这些准备不需要很多预算，但攻击发生时能省下大量混乱中的决策时间。关于 DDoS 缓解策略的更系统化讨论，可以参考 Cloudflare 的DDoS Mitigation Best Practices，其中详细列举了从流量识别到清洗分发的完整步骤。

这里有一个实战经验值得分享：很多团队做了监控，但告警阈值设得太高，等告警触发时服务器已经处于半瘫痪状态。建议将告警阈值设为日常峰值的 1.5 倍，而不是服务器硬件上限的 80%。因为一旦连接数或带宽（网络传输容量的上限）用量突然跳升到 1.5 倍以上，基本可以确认异常，这时候干预还有回旋余地。

攻击后的复盘与加固

攻击结束后不要立刻回到日常运维，应该做一次完整复盘。复盘的核心目的不是追责，而是找到防护体系里的盲区，让下次响应更快更准。

1. 日志分析：确认攻击类型、峰值流量、持续时间、受影响的服务
2. 漏洞检查：确认攻击期间是否有数据泄露或未授权访问
3. 规则优化：根据攻击特征调整 iptables 规则、连接数限制和黑洞阈值
4. 监控补盲：检查告警是否及时触发，是否有监控盲区
5. 方案升级评估：如果本次攻击超过当前防护能力，评估是否需要升级到高防方案。更多选型参考可以看美国服务器租用避坑清单，其中也涉及防护方案选择的常见误区

特别要关注的是：复盘不仅要分析”攻击怎么进来的”，还要分析”恢复为什么这么慢”。很多时候恢复缓慢不是因为防护不够，而是因为分工不清、备选通道没提前测试、或者应急文档写完就再也没演练过。

总结与行动建议

大流量攻击面前，先保业务再谈拦截是更务实的应对策略。具体建议：

1. 攻击发生后第一个小时：确认类型、保护核心、通知团队、联系机房
2. 提前做好服务分层，攻击时只需激活预设规则，不需要临时决策
3. 不能完全依赖机房清洗，自己的应急准备决定了前 30 分钟的走向
4. 攻击后必须复盘，补监控、调规则、评估方案升级

只要你的站点已经是正式业务，就应该把应急顺序提前想清楚。等攻击来了再从零开始判断，远不如提前分层和演练来得有效。