遇到 CC 攻击，最直接的止损方式是立即在 Cloudflare 后台开启「Under Attack Mode」，并确认域名 DNS 记录已开启代理（橙色云），确保流量先经过 Cloudflare 清洗再到达你的 VPS。
先说结论：防护的核心在于隐藏源站 IP 并利用 Cloudflare 的边缘节点吸收流量，而不是在 VPS 上硬抗。
- 先判断：确认域名 DNS 是否已接入 Cloudflare 代理，源站 IP 是否已暴露。
- 优先做：开启「Under Attack Mode」临时拦截，随后配置 WAF 自定义规则限制请求频率。
- 再验证：观察 VPS 负载是否下降，Cloudflare 分析面板是否有拦截记录。
快速处理思路
Cloudflare 主要是界面配置，不需要在 VPS 上执行复杂命令，重点在于后台开关和 DNS 状态检查。
1. 检查 DNS 代理状态
登录 Cloudflare 控制台，查看 DNS 记录列表，确保网站域名旁的云图标是橙色（Proxied）。如果是灰色，流量会直连源站，防护无效。
2. 开启紧急防护模式
在 Security -> Settings 中找到「Under Attack Mode」，将其切换为 On。这会强制所有访客通过 JS 挑战页面，能立刻阻断大部分自动化攻击脚本。
3. 查看源站连接
在 VPS 上使用 netstat -an | grep :80 | wc -l 或 ss -s 查看当前连接数，作为基线参考，开启防护后该数值应明显回落。
为什么会这样
CC 攻击（Challenge Collapsar）本质是应用层洪水攻击，攻击者模拟正常请求耗尽服务器资源（如 CPU、内存或数据库连接）。VPS 性能有限，直接暴露在公网时，少量高频请求就能导致服务不可用。
Cloudflare 作为反向代理，将你的源站 IP 隐藏在背后。攻击流量先到达 Cloudflare 的全球边缘节点，被其防火墙规则拦截或挑战，只有合法的流量才会回源到你的 VPS。公开资料中没有看到可靠的量化数据说明具体能抗多少 QPS，但架构上确实实现了流量清洗。
分步处理
第一步：确认源站 IP 是否已泄露
如果攻击者已经知道你的真实 IP，他们可能绕过 Cloudflare 直接攻击源站。检查历史 DNS 记录、邮件头或服务器日志。如果 IP 已泄露，建议联系服务商更换 IP，并确保新 IP 不再公开。
第二步：配置 WAF 自定义规则
进入 Security -> WAF -> Custom rules。创建一条规则，例如当「Request Path」匹配网站路径且「Requests per minute」超过阈值时，执行「Block」或「Challenge」。
注意：阈值需要根据正常业务流量设定，公开资料中没有统一的标准值，建议先观察正常时段的请求量再设定。
第三步：调整 SSL/TLS 模式
在 SSL/TLS 设置中，确保模式与源站配置匹配。如果源站没有证书，选「Flexible」；如果有自签名选「Full」；如果有可信证书选「Full (strict)」。配置错误会导致 522 或 525 报错。
怎么验证是否生效
1. 服务器负载检查
在 VPS 终端运行 top 或 htop，观察 CPU 和内存使用率。开启防护后，异常的高峰应趋于平稳。
2. Cloudflare 分析面板
查看 Security -> Events 或 Analytics 面板。如果看到大量的「Managed Challenge」或「Block」记录，说明规则正在起作用。
3. 网站访问测试
使用正常浏览器访问网站，确认能正常加载（可能会经历一次 JS 挑战）。同时检查网站功能（如登录、提交表单）是否受影响。
常见坑
1. 源站 IP 未隐藏
这是最常见的问题。如果 DNS 云图标是灰色，或者服务器主动向外请求时泄露了 IP（如发送邮件），防护会失效。
2. 误伤正常用户
过于严格的 WAF 规则或频率限制可能阻止真实用户访问。建议初期动作设为「Challenge」而不是「Block」，给真人验证的机会。
3. 管理员后台被锁
配置频率限制时，别忘了排除管理员 IP 或特定路径。建议添加一条允许规则，放行管理后台的 IP 段。
参考来源
- Cloudflare Official Documentation, "Under Attack Mode", https://developers.cloudflare.com/
- Cloudflare Official Documentation, "WAF custom rules", https://developers.cloudflare.com/waf/
原文链接：https://www.zjcp.cc/ask/10099.html