网站突然访问变慢，甚至完全打不开，服务器CPU或带宽占用率飙升，这很可能是遭遇了流量攻击。别慌，先别管攻击类型是CC还是DDoS，当务之急是让网站先恢复访问。最直接有效的临时措施是：立即启用你的CDN（内容分发网络）服务，并将其安全防护等级调整到最高或“Under Attack”模式。 这就像给正在被围攻的城堡紧急拉上了一道坚固的防护门，把恶意流量挡在外面，让正常用户还能从安全通道进入。

第一步：快速启用并切换CDN防护模式

如果你已经使用了CDN服务（这是现代网站运维的标配），登录管理后台。以主流服务商为例，找到“安全”或“DDoS防护”设置区域。你会看到一个通常名为“安全级别”或“模式”的选项，将其从“低”或“默认”直接切换到“高”或“我正遭受攻击”。这个模式会强制所有访问者（包括搜索引擎爬虫）先经过一个验证页面（通常是JavaScript挑战），只有通过验证的合法浏览器请求才能访问你的源站服务器。它能瞬间过滤掉绝大部分由模拟请求、脚本发起的CC攻击和部分应用层DDoS。

第二步：紧急配置IP黑名单与限流规则

在调整CDN模式的同时，立刻分析实时访问日志或CDN控制台提供的攻击数据。寻找攻击特征：是大量来自某个国家/地区的IP？还是集中访问某个特定URL（如登录页、搜索接口）？发现后，立即在CDN防火墙或WAF规则中设置紧急拦截。例如，如果攻击IP段来自海外，而你的业务仅面向国内，可以临时屏蔽所有海外IP访问。如果攻击针对 "/wp-login.php"，可以临时对该路径设置访问频率限制，如单个IP每60秒只能请求5次。这些操作都能在几分钟内生效，为服务器减负。

// 示例：在Nginx中紧急限流某个路径（需源站服务器可操作）
http {
    limit_req_zone $binary_remote_addr zone=attackpath:10m rate=5r/m;

    server {
        location /wp-login.php {
            limit_req zone=attackpath burst=10 nodelay;
            // ... 其他配置
        }
    }
}

第三步：临时更换服务器IP或启用备用IP（如有条件）

如果攻击是直接针对你的源站服务器IP的DDoS流量攻击（即攻击者可能已经知道了你的真实IP），那么CDN可能已经部分失效。此时，最硬核的临时措施是更换服务器公网IP。联系你的云服务商或IDC，请求他们为你分配一个新的弹性公网IP，并将域名解析记录（A记录）快速指向这个新IP。同时，确保CDN的回源地址也更新为新IP。这相当于给服务器“隐身”，让攻击者暂时失去目标。注意，DNS解析全球生效需要时间（TTL），因此提前设置较短的TTL值（如300秒）在此时显得至关重要。

第四步：利用云服务商的弹性带宽与清洗服务

几乎所有主流云平台都提供免费的基础DDoS流量清洗服务。当检测到超大流量攻击时，流量会被自动牵引到清洗中心，过滤掉恶意流量后再将正常流量回注到你的服务器。如果你的服务器在云上，立即登录控制台，检查“DDoS防护”或“安全中心”面板，确认清洗服务是否已自动启用。如果攻击流量超过了免费配额，考虑临时升级带宽峰值或购买一次性的高防IP服务。高防IP作为一个中间代理，拥有巨大的带宽和清洗能力，可以将清洗后的流量转发给你的源站，这是应对大规模流量攻击的“特效药”。

第五步：操作系统与Web服务层紧急优化

在外部防护生效的同时，对服务器内部做“急救手术”，释放资源。首先，通过命令快速分析消耗资源的进程。立即停止非关键的后台进程、定时任务。其次，优化Web服务配置：对于Apache，可临时降低 "MaxClients" 数量；对于Nginx，调整 "worker_processes" 和 "worker_connections"，并启用对单个IP的连接数限制。最后，修改关键服务的默认端口，例如将SSH端口从22改为非常用端口，并在防火墙中只允许管理IP访问，这能阻断攻击者利用服务器资源发起后续攻击。

# 示例：Linux下快速分析网络连接和进程的命令
netstat -anp | grep :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20
top -c
ss -tunlp | grep :443

第六步：临时降级或关闭动态交互功能

很多CC攻击瞄准的是搜索、登录、评论、API接口等需要调用数据库的动态功能。作为“断腕求生”的临时措施，可以考虑暂时关闭网站评论功能、将搜索功能替换为静态页面或第三方工具、对登录页面实施严格的验证码策略。更激进一点，如果网站有静态缓存，可以暂时将全站设置为纯静态模式，所有动态请求返回503状态码并引导用户稍后访问。这能最大程度减少数据库和应用程序服务器的压力。

第七步：监控、分析与记录，为后续防御做准备

当上述措施让网站访问暂时恢复正常后，危机并未解除。你需要立刻开始深度监控和取证。使用日志分析工具，仔细研究攻击开始前后的日志，定位攻击源、攻击向量和利用的漏洞。记录下攻击的持续时间、峰值流量、攻击IP池等特征。这些信息至关重要，它不仅能帮助你向ISP或执法部门报告，更是你后续部署长期、稳固安全防护方案的直接依据。考虑部署更专业的WAF（Web应用防火墙），并制定详细的应急响应预案。

记住，以上所有方法都是“缓解症状”的临时措施，旨在争取宝贵的响应时间。它们不能根除攻击，也不能替代一个包含高防CDN、稳健的架构设计、代码安全审计和常态化监控的完整安全体系。在实施这些临时措施后，你必须立刻着手调查攻击根源，加固系统，防止下一次更猛烈的攻击。网站安全是一场持久战，快速有效的应急响应能力是每个运维和站长的必修课。