被CC攻击时静态资源与动态接口分离降级

遭遇CC攻击时，最怕的不是带宽被占满，而是动态接口和静态资源混在一起，导致整个站点瞬间瘫痪。很多人第一反应是买高防IP或者加带宽，但这就像给漏水的桶不停加水，治标不治本。真正有效的思路，是把静态资源和动态接口从架构层面剥离开，让它们走不同的通道，甚至让静态资源具备独立存活的能力。

CC攻击本质上是通过大量看似合法的请求，耗尽服务器资源。攻击者通常会混合请求你的首页、搜索接口、登录接口以及各种静态图片、CSS、JS文件。如果你的Nginx或Apache把所有请求都透传给后端的PHP、Java或者Node服务，那么当动态请求被拖垮时，静态资源也会跟着返回502或503错误。用户看到的就是白屏或者破图，体验极差。

动静分离不仅仅是把图片放到另一个域名下那么简单。它要求你的静态资源完全不经过后端应用服务器。最理想的架构是：静态资源走CDN，动态接口走源站，两者域名也不同。比如主站用 www.example.com，静态资源用 static.example.com 或者 cdn.example.com。这样即使源站被打垮，只要CDN缓存还在，静态资源依然能正常加载。

但很多中小站点没有自建CDN的条件，或者静态资源和动态接口混在同一个域名下。这时候就需要在Web服务器层面做精准的流量切分。以Nginx为例，你可以通过location指令，把特定路径或后缀的请求直接交给本地文件系统处理，而不需要转发到FastCGI或代理层。

# Nginx配置示例：静态资源直接读取，不经过后端
location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2|ttf|eot)$ {
    root /data/www/static;
    expires 30d;
    add_header Cache-Control "public, immutable";
    try_files $uri =404;
}

location / {
    # 动态请求转发到后端应用
    proxy_pass http://backend_cluster;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

这样配置后，哪怕后端应用完全崩溃，只要Nginx进程还在，静态资源就能正常返回。这是最基础的一层降级保障。但仅仅这样还不够，因为CC攻击如果打的是动态接口，你的后端依然会挂。

动态接口不能像静态资源那样完全脱离后端，但可以通过缓存机制让它变得“相对静态”。在遭遇攻击时，对于非登录态、非实时性要求极高的接口，可以直接返回缓存内容，而不是每次都去查询数据库。

常见的做法是在Nginx层面引入缓存模块，比如proxy_cache或者fastcgi_cache。你可以在攻击期间临时调整缓存策略，把原本缓存1分钟的内容延长到10分钟甚至1小时。这样即使后端响应变慢或者部分宕机，Nginx依然可以用过期的缓存内容来响应请求，保证核心页面的可用性。

# Nginx代理缓存配置
proxy_cache_path /tmp/nginx_cache levels=1:2 keys_zone=my_cache:100m max_size=10g inactive=60m use_temp_path=off;

server {
    location /api/ {
        proxy_cache my_cache;
        proxy_cache_key "$scheme$request_method$host$request_uri";
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404 1m;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
        proxy_cache_lock on;
        proxy_cache_background_update on;
        proxy_pass http://backend_cluster;
    }
}

proxy_cache_use_stale这个指令非常关键。它允许在后端返回错误、超时或者500系列状态码时，Nginx直接使用已过期的缓存内容来响应。这意味着即使你的后端被CC攻击打到完全不可用，只要缓存里还有数据，用户就能看到页面内容。proxy_cache_lock则能防止缓存失效瞬间的大量请求同时穿透到后端，这在攻击期间尤为重要。

如果你的静态资源和动态接口共享同一个域名，那么所有请求都会携带相同的Cookie。CC攻击产生的海量请求中，哪怕只有10%是静态资源，这些请求也会把Cookie信息传递给Web服务器，增加不必要的解析开销。更糟糕的是，如果攻击者故意请求不存在的静态文件，你的应用服务器可能会收到大量404错误，进一步消耗资源。

将静态资源迁移到独立域名，并且设置该域名不接收Cookie，可以减少请求体积和服务器处理压力。更进一步，你可以为静态资源域名配置单独的限流规则，甚至将其解析到对象存储服务或者第三方CDN上，让它完全脱离源站的束缚。

在降级场景下，独立域名还有一个巨大优势：你可以通过DNS快速切换静态资源的指向。如果主站服务器IP被打得不可用，你可以在DNS层面把静态资源域名指向一个备用的静态文件服务器，甚至是一个临时的云存储Bucket，而主域名则可以通过其他方式做流量清洗。

动静分离降级不仅仅是后端架构的事，前端代码也需要配合。在页面加载时，如果主站接口响应缓慢或者失败，前端应该有相应的超时处理和降级展示。比如导航栏的数据如果来自接口，可以在本地存一份静态的默认菜单数据，接口超时后直接渲染本地数据。

对于静态资源的引用，可以使用CDN域名作为主域名，同时准备一个备用域名。当主CDN不可用时，前端可以通过onerror事件触发资源重试逻辑，切换到备用域名加载。这种多级容错机制能让你的页面在极端情况下依然保持基本的可读性。

// 前端静态资源降级加载示例
function loadScript(src, fallbackSrc) {
    var script = document.createElement('script');
    script.src = src;
    script.onerror = function() {
        if (fallbackSrc) {
            var fallback = document.createElement('script');
            fallback.src = fallbackSrc;
            document.head.appendChild(fallback);
        }
    };
    document.head.appendChild(script);
}

// 主CDN加载失败时切换到备用CDN
loadScript('https://cdn1.example.com/app.js', 'https://cdn2.example.com/app.js');

在遭受CC攻击时，简单的IP频率限制往往不够精确，容易误伤正常用户。更好的做法是结合请求类型做分层限流。静态资源请求可以设置较高的频率阈值，因为它们对服务器资源消耗小；而登录、注册、搜索等动态接口则需要更严格的限制。

你可以在Nginx层用limit_req和limit_conn模块来实现这种差异化控制。对于静态资源，甚至可以完全不做限制，因为它们的处理成本极低。对于动态接口，则根据接口的重要性和资源消耗程度，设置不同的限流参数。核心交易接口即使在被攻击时也要尽量保障可用，可以给它分配独立的限流区域和更高的阈值。

# 分层限流配置
http {
    # 动态接口严格限流
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;
    # 登录接口更严格
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;
    
    server {
        location /api/ {
            limit_req zone=api_limit burst=10 nodelay;
            proxy_pass http://backend;
        }
        
        location /api/login {
            limit_req zone=login_limit burst=3 nodelay;
            proxy_pass http://backend;
        }
        
        location ~* \.(jpg|png|css|js)$ {
            # 静态资源不限流
            root /data/static;
        }
    }
}

对于真正需要高可用保障的场景，可以把静态资源完全托管到对象存储服务上。无论是阿里云OSS、腾讯云COS还是华为云OBS，它们都具备原生的高并发处理能力和CDN加速功能。你的源站服务器甚至不需要保存任何静态文件，所有图片、样式、脚本都直接从对象存储加载。

这样做的好处是，即使你的源站服务器全部宕机，只要对象存储服务正常，用户看到的页面样式和交互功能就不会受影响。如果你的前端应用是单页面应用，甚至可以做到整个应用壳子都托管在对象存储上，只有数据接口依赖源站。这种架构下，CC攻击能影响的范围被压缩到了最小。

降级策略不能只靠人工触发。你需要一套自动化的监控和切换机制。当监控系统检测到后端响应时间超过阈值、错误率上升或者服务器负载过高时，自动触发降级策略。这些策略可以包括：延长缓存时间、启用静态化页面、关闭非核心功能接口、切换静态资源域名等。

具体实现上，可以在Nginx前面加一层Lua脚本或者使用OpenResty，根据实时监控数据动态调整配置。也可以使用专门的负载均衡设备或者云服务商提供的健康检查功能，在后端不可用时自动切换到静态降级页面。

# OpenResty动态降级示例
location /api/ {
    access_by_lua_block {
        local redis = require "resty.redis"
        local red = redis:new()
        red:connect("127.0.0.1", 6379)
        
        -- 从Redis读取降级开关状态
        local degraded = red:get("degrade:api")
        if degraded == "1" then
            -- 降级模式下直接返回缓存或静态数据
            ngx.exec("/static/fallback.json")
        end
    }
    proxy_pass http://backend;
}

这种动态降级能力让你可以在几秒钟内切换整个站点的运行模式。当攻击流量突然爆发时，系统自动进入降级状态，优先保证静态资源和核心接口的可用性，非核心功能暂时关闭。攻击结束后再自动恢复。

动静分离降级的本质，是把系统中不同特性的组件解耦，让它们各自拥有独立的容错能力。静态资源天然适合缓存和分发，就应该让它尽可能远离源站；动态接口虽然依赖后端逻辑，但也可以通过缓存和熔断机制获得一定的韧性。两者结合，你的站点在面对CC攻击时就不再是一损俱损的局面，而是能够有层次地降级，始终给用户保留一个可用的基本体验。