摘要：# LVS和Nginx抗DDoS：别光看PPT，实战配置才是硬道理 我前两天刚翻过一个客户的配置，好家伙，源站前面挂了个Nginx，后面又接了个LVS，问为啥这么配？答曰：“别人都说这么配安全。”结果一压测，流量稍微大点就502，真绝了。 说白了，很多…

LVS和Nginx抗DDoS：别光看PPT，实战配置才是硬道理

我前两天刚翻过一个客户的配置，好家伙，源站前面挂了个Nginx，后面又接了个LVS，问为啥这么配？答曰：“别人都说这么配安全。”结果一压测，流量稍微大点就502，真绝了。

说白了，很多所谓“高可用、抗攻击”的方案，PPT上画得天花乱坠，链路清晰得跟教科书似的，真等攻击流量打过来的时候，该露馅还是露馅。问题往往不是你没上防护，而是配错了，或者压根没想明白这俩玩意儿到底该在哪儿干活。

今天咱就抛开那些云山雾罩的行业黑话，聊聊负载均衡里的两位老伙计——LVS和Nginx，在抗DDoS这个让人头疼的场景下，到底该怎么用。我保证，不跟你扯“双剑合璧、天下无敌”那种正确的废话。

LVS：抗在阵前的“钢铁大门”，但别让它干细活

先说说LVS（Linux Virtual Server）。这东西在业内有个绰号，叫“四层负载均衡器”。啥意思？你可以把它想象成邮局里分拣包裹的巨型机器。它不看包裹里具体是情书还是账单（应用层内容），它只看包裹外头的地址和端口（IP和端口号），然后以极高的效率，按照你设定的规则（轮询、最小连接数等），把包裹（网络数据包）扔到后面不同的处理窗口（真实服务器）去。

它的核心优势就一个字：快。

因为工作在网络协议的底层（传输层），几乎不对数据包做拆解分析，所以性能损耗极低，吞吐量惊人。我见过单台精心调优的LVS，扛住几十Gbps的流量跟玩儿似的。在抗DDoS，尤其是那种海量SYN Flood、UDP Flood攻击时，它能顶在最前面，用自己强悍的转发能力，把大部分垃圾流量先消化掉，或者导向专门的清洗设备。

但是（这里必须有个大转折）—— 你千万别指望LVS能帮你识别攻击。它就是个“铁憨憨”，只负责转发，不负责鉴别。你告诉它往哪儿转，哪怕是攻击包，它也照转不误。

所以，LVS的典型抗D配置思路是这样的：

• 位置： 放在整个架构的最前端，紧挨着你的高防IP或者防火墙。
• 角色： 做流量分发和初步的“扛压”。利用它的DR模式（Direct Routing）或者TUN模式，将正常请求和经过清洗后的“干净”流量，高效地分发给后端的Nginx集群或应用服务器。
• 配置要点（说人话版）：
  • 连接超时调短： 对于Web服务，把tcp_fin_timeout、tcp_keepalive_time这些参数调低点。攻击中会有大量半开连接，早点释放资源。
  • 限制单IP连接数： 用iptables配合LVS，限制单个IP地址到VIP（虚拟IP）的新建连接速率。这招对付CC攻击的雏形有点用，但别指望它万能。
  • 与上层联动： 这是关键！LVS自己傻，但它可以和后端的“聪明人”（比如Nginx）或者专门的抗D设备联动。比如，后端Nginx发现某个IP异常，可以通过脚本动态更新LVS前端的iptables规则，把它临时拉黑。

说白了，LVS是你的第一道物理防线，靠蛮力吃饭。它的任务是把流量洪水分流成几条可控的河，别让洪水一下子冲垮你的后院（Nginx或应用服务器）。

Nginx：后方的“智能调度员”，心眼多但力气小

再来看看Nginx。这位是“七层负载均衡器”，也就是应用层负载均衡。它不像LVS那么“底层”，它会把“包裹”拆开，看看里面的“信”到底写了啥（HTTP头、URL、Cookie等），然后再做决定。

它的核心优势是：聪明。

正因为能看懂内容，所以它能做很多精细活：

• 根据URL路径转发： /api/的请求去A组服务器，/static/的请求去B组服务器。
• 识别慢速攻击： 比如Slowloris攻击，一点点地发HTTP头，耗死你。Nginx可以设置client_header_timeout和client_body_timeout，超时就断开。
• 限制请求速率： 这是抗CC（应用层DDoS）的利器！limit_req_zone和limit_req模块，能严格限制单个IP在单位时间内的请求数。超过？直接返回503或丢进队列慢慢等。
• 缓存静态资源： 把图片、CSS、JS缓存起来，攻击者请求这些静态资源时，Nginx直接返回，根本不用麻烦后端的应用服务器，大大减轻压力。

但是（又一个但是来了）—— Nginx的“聪明”是需要消耗CPU和内存资源的。每解析一个HTTP请求，都比LVS单纯转发一个IP包要累得多。所以，它的性能天花板比LVS低得多。你让它去直面几十Gbps的SYN Flood，它瞬间就趴窝了。

所以，Nginx的典型抗D配置思路是：

• 位置： 躲在LVS（或硬件防火墙/高防IP）后面，作为第二道防线。
• 角色： 做精细化的流量管控和攻击识别。处理那些已经过了第一道粗筛的流量，把伪装成正常请求的CC攻击、慢速攻击给揪出来。

• 配置要点（实战干货）：

  • 限速限流是灵魂：

    # 定义限制区，10MB空间记录IP的请求频率，速率是每秒10个请求
    limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
    
    location / {
        # 应用限制，突发请求不超过20个
        limit_req zone=one burst=20 nodelay;
        proxy_pass http://backend;
    }

  • 关掉非必要功能： 在nginx.conf里，把server_tokens调成off，别告诉别人你的Nginx版本号。攻击者就爱找特定版本的漏洞。
  • 调整连接参数： worker_connections（每个worker能处理的连接数）根据你的机器配置调大点。keepalive_timeout别设太长，减少资源占用。
  • 善用ngx_http_realip_module： 因为前面有LVS或者代理，后端Nginx看到的客户端IP都是LVS的IP。这个模块能帮你获取到真实的用户IP，这样你做的限流、拉黑才能对准真人。

Nginx是你的业务逻辑防线，靠策略吃饭。它的任务是在LVS分流的基础上，把混在好人里的“特务”给甄别出来。

他俩到底怎么配？一个真实场景的推演

好了，道理讲完了，我们来点实在的。假设你有一个电商网站，既要应付大促的秒杀（高并发），又要提防同行的黑手（DDoS/CC攻击）。

一个比较靠谱的架构是这样的：

用户 -> [ 高防IP / 云清洗 ] -> [ LVS集群 ] -> [ Nginx集群 ] -> [ 应用服务器集群 ]

1. 第一层（高防IP/云清洗）： 买服务或者用云厂商的。这是“专业对口”，专门应对超大流量的DDoS攻击，进行初步的流量清洗。很多攻击在这一层就被化解了。
2. 第二层（LVS集群）： 接收经过清洗后的“较干净”流量。利用其高吞吐能力，将流量均匀、高效地分发给后端的几十甚至上百台Nginx服务器。这里LVS主要解决高并发连接数的问题。
3. 第三层（Nginx集群）： 每台Nginx接收到LVS转发的流量后，开始施展它的“智能”。进行精细的限速、缓存、路由，并把请求转发给最终的应用服务器（如Tomcat, PHP-FPM）。这里Nginx主要解决应用层恶意请求和静态资源卸载的问题。

这种组合的精髓在于：让专业的工具做专业的事。

LVS负责“抗量”，Nginx负责“识坏”。如果你把顺序搞反了，或者让Nginx直接暴露在最前面，结果就是攻击一来，Nginx光顾着解析海量垃圾请求的HTTP头，CPU就100%了，真正的用户请求反而进不来——这种感觉你懂吧？钱没少花，效果却差得离谱。

最后说点大实话

1. 没有银弹： 别指望单靠调整LVS或Nginx配置就能防住所有DDoS。面对Tb级别的流量型攻击，最终还得靠带宽和专业的清洗中心。LVS+Nginx这套组合，更多是帮你在成本可控的情况下，提升架构的韧性和自救能力，尤其是应对CC攻击和中小规模的混合攻击。
2. 监控是眼睛： 配得再好，不看监控也是瞎子。务必监控LVS的连接数、包转发速率，Nginx的活跃连接数、请求拒绝数（503）、后端响应时间。警报响了，才知道该往哪儿调。
3. 定期演练： 和平时期的配置，打仗时未必好使。有条件的话，定期做做压力测试和攻防演练，看看你的配置在真实压力下会不会掉链子。

行了，不废话了。配置参数是死的，业务场景是活的。理解原理，摸清自家业务的脾气，比照抄一百份配置都强。回去看看你的架构图，LVS和Nginx的位置，放对了吗？