中小站点低成本抵御DDoS洪水攻击的完整方案

中小站点遭遇DDoS攻击，最致命的不是带宽被塞满，而是成本。大厂可以靠高防IP和清洗中心硬扛，但中小站长往往连每月几千块的高防费用都觉得吃力。真正的难题在于：攻击者的成本远低于防御者，一个几十块的Boots（僵尸网络）就能让没有准备的站点瘫痪数小时。所以，低成本抵御DDoS，核心思路不是“硬抗”，而是“巧躲”和“借力”。

DDoS不是一种攻击，而是一类攻击的统称。对于中小站点，必须分清三种主要类型，因为防御手段和成本天差地别。第一种是流量耗尽型，也就是常说的洪水攻击，通过UDP Flood、ICMP Flood或伪造的SYN包撑满你的服务器带宽。第二种是资源耗尽型，比如CC攻击（Challenge Collapsar），它模拟正常用户请求动态页面，让服务器CPU或数据库连接池耗尽，带宽可能没跑满，但网站已经打不开了。第三种是漏洞利用型，利用应用层漏洞，一个数据包就能让服务崩溃。分清类型后，你会发现很多攻击根本不需要昂贵的清洗设备。

最省钱的方式是从架构上做文章。如果你的站点是动态生成的，每个请求都要查数据库，那一个简单的CC攻击就能让你数据库挂掉。把能静态化的页面全部静态化，生成HTML文件直接由Nginx或OpenResty返回，单台1核2G的云服务器就能扛住数万并发连接。动态接口必须做缓存，在Nginx层用proxy_cache或FastCGI cache把数据库查询结果缓存起来，设置合理的过期时间。更彻底的方案是“源站分离”：源站只负责生成静态文件和提供API，前端用CDN分发。国内很多CDN厂商提供免费的静态加速服务，攻击流量会被分散到各个边缘节点，真正到达源站的请求量级会大幅下降。源站甚至可以只允许CDN回源IP访问，其他IP一律在防火墙层面丢弃，这样攻击者根本找不到你的真实服务器地址。

国内主流云厂商的轻量应用服务器或ECS都自带免费的基础DDoS防护，一般在5Gbps到20Gbps之间。这个量级对于绝大多数中小站点已经足够。关键是要配置好安全组规则。安全组是云服务器的第一道防火墙，完全免费。你应该只放通必要的端口，比如80和443，其他端口全部拒绝。对于SSH远程管理端口22，设置仅允许你固定的办公IP或家庭IP访问，彻底杜绝暴力破解和基于端口的攻击。如果你的业务面向国内用户，直接在安全组里拒绝所有境外IP的入站流量，这能过滤掉大量来自海外僵尸主机的攻击。云厂商的控制台通常还提供“DDoS防护阈值”设置，把清洗阈值调到你正常业务带宽峰值的1.5到2倍，一旦超过就触发黑洞或清洗，虽然会短暂影响业务，但能避免产生天价带宽费用。

Nginx和OpenResty是中小站点的标配，它们的默认配置远不是最优。针对DDoS防御，有几个参数调整后效果立竿见影。首先是限制连接数和请求速率。在http块或server块中配置limit_conn_zone和limit_req_zone，对单个IP的连接数和请求频率做严格限制。比如限制每个IP每秒最多10个请求，同一时间最多20个并发连接，超过就返回503或直接丢弃。这个配置对CC攻击有奇效。其次是缩短超时时间。client_body_timeout和client_header_timeout设置到10秒以内，避免攻击者建立连接后慢速发送请求头占用连接资源。keepalive_timeout降低到30秒甚至更短，让空闲连接尽快释放。还有一个容易被忽略的参数是worker_connections和worker_rlimit_nofile，根据服务器内存大小调大这两个值，确保Nginx能处理更多并发连接而不至于耗尽文件描述符。

Linux内核本身提供了抵御SYN Flood的能力，但默认没有开启或配置保守。编辑/etc/sysctl.conf文件，启用SYN Cookie保护：net.ipv4.tcp_syncookies = 1。这个机制在SYN队列满时，不会直接丢弃新连接，而是用加密算法生成一个Cookie响应，只有收到合法ACK才建立连接，对伪造源IP的SYN Flood极其有效。同时，缩短SYN队列的等待时间：net.ipv4.tcp_synack_retries设置为1或2，让半开连接尽快超时释放。减少TIME_WAIT状态连接的影响：net.ipv4.tcp_tw_reuse = 1，并适当调大net.ipv4.tcp_max_tw_buckets的值。还可以开启net.ipv4.tcp_fastopen = 3，允许TCP快速打开，减少握手延迟。这些内核层面的调整完全免费，却能让服务器在遭受攻击时保持更高的服务可用性。

如果攻击已经穿透了前面的防线，你需要在应用层做更精细的识别和拦截。OpenResty集成了Lua脚本引擎，可以编写自定义的WAF（Web应用防火墙）逻辑。一个典型的低成本方案是：在Nginx的access阶段用Lua脚本检查请求特征。比如，攻击流量通常带有特定的User-Agent字符串，或者请求路径集中在某个动态接口。你可以维护一个黑名单列表，匹配到就直接返回403。更智能的做法是结合Redis做频率统计，对访问过于频繁的IP自动拉黑一段时间。下面是一个简单的Lua脚本示例，用于限制单个IP对某个接口的访问频率：

-- 需要在nginx.conf的http块中引入lua_shared_dict
-- lua_shared_dict limit_req_store 10m;

local limit_req = ngx.shared.limit_req_store
local key = "req:" .. ngx.var.binary_remote_addr .. ":" .. ngx.var.uri
local reqs, err = limit_req:incr(key, 1)

if reqs == nil then
    ngx.log(ngx.ERR, "failed to incr: ", err)
    return
end

if reqs == 1 then
    limit_req:expire(key, 1)  -- 1秒过期
end

if reqs > 20 then  -- 每秒超过20次请求
    ngx.exit(403)
end

这个脚本不需要外部依赖，直接在Nginx内部完成高频IP的封堵，延迟极低。你可以根据业务特点调整阈值和统计窗口，把攻击请求挡在业务逻辑之外。

即使不购买高防服务，你仍然可以利用一些免费的基础设施来分散攻击。国内多个云厂商提供免费的CDN服务，虽然带宽有限，但用于静态资源和首页缓存足够。关键操作是修改DNS解析策略：默认线路指向CDN的CNAME地址，同时设置一条“搜索引擎”线路或特定运营商线路直接指向源站，保证爬虫和重要用户能回源。更隐蔽的做法是，在CDN前面再加一层DNS调度，使用支持分线路解析的免费DNS服务，把攻击高发地区的流量指向一个空的或仅返回静态页面的地址，实现地域层面的流量隔离。源站IP必须严格保密，一旦泄露，攻击者就能绕过CDN直接打源站。如果源站IP已经泄露，更换IP是唯一选择，并在更换后立即配置安全组仅允许CDN回源。

防御DDoS不能只靠静态配置，攻击手法在变，你的规则也要动态调整。中小站点没有专职安全团队，所以必须建立简单的自动化响应机制。写一个Shell脚本或Python脚本，定时分析Nginx访问日志，统计最近1分钟内访问量最高的前20个IP，如果某个IP的请求数超过阈值，自动调用云厂商的API将其加入安全组黑名单，或者直接通过iptables封禁。iptables封禁命令很简单：iptables -I INPUT -s 攻击IP -j DROP。但要注意，iptables规则太多会影响性能，可以配合ipset使用，ipset支持哈希存储大量IP，匹配效率极高。脚本还可以检测日志中特定状态码的比例，比如403或503错误占比突然飙升，就触发告警通知你人工介入。这套自动化工具完全开源，部署在服务器上几乎不消耗额外资源。

如果攻击强度超过了所有免费防御手段的承受能力，你还需要一个终极兜底方案。准备一台配置极低的备用服务器，甚至是一个虚拟主机，上面部署一个纯静态的“维护页面”或“降级页面”。当主服务器因攻击被云厂商黑洞路由时，立即修改DNS解析将域名指向这台备用服务器。这个页面可以包含你的联系方式、重要公告，甚至一个简化的下单表单，数据提交到第三方表单收集服务。这样即使主站完全不可访问，核心业务线索不会完全中断。这种“降级运营”思路，比硬扛攻击要务实得多，也便宜得多。

当攻击真的来了，慌乱是大忌。第一步，登录云控制台查看监控，确认是带宽被打满还是CPU/连接数飙升，判断攻击类型。第二步，如果带宽被打满且超过了免费防护阈值，服务器可能已经被黑洞，此时不要反复尝试重启，立即执行DNS切换，将流量引到CDN或备用静态页面。第三步，如果服务器还能登录，快速检查Nginx访问日志，找出攻击特征，比如相同的URL参数、相同的User-Agent，在Nginx配置中用if语句或map模块临时封堵这些特征。第四步，联系云厂商工单支持，即使是免费用户，厂商通常也会提供基础的攻击分析帮助，他们能告诉你攻击流量的大致组成。第五步，攻击结束后复盘，加固薄弱环节，更新你的防御脚本和规则库。

低成本防御DDoS的本质，是把有限的预算花在刀刃上，用开源技术、云厂商免费资源、架构优化和自动化脚本，构建一个多层次、可弹性伸缩的防御体系。这套体系不一定能挡住所有攻击，但足以让攻击者的成本大幅上升，让绝大多数自动化的扫描和攻击脚本无功而返，为你的站点争取到宝贵的生存空间。