网站老被盯上？聊聊我是怎么用Cloudflare把攻击挡在门外的

不少站长第一次意识到自己的站被人盯上，往往不是因为数据泄露，而是某天发现后台打不开、CPU跑满、带宽图直接拉成一条直线。去查日志，一堆来自各地的IP在刷同一个接口。这时候才想起来问：要不要上Cloudflare？我的看法是，CF确实是最省事的起点，但它不是万能药，什么时候该用它、什么时候得换思路，得分开说。

这篇文章不堆概念，主要讲我平时给站点做防护时的实际顺序：先把CF接上挡掉大部分噪音，再看哪些攻击CF兜不住，最后判断什么情况下必须落到一台带硬防的独立服务器上。

先把DNS交给Cloudflare，这一步几乎零成本

很多人的站是直接A记录指向源站IP的，等于把家门钥匙挂在门口。攻击者扫一遍全网IP就能找到你，然后慢慢试端口、试接口。把域名NS改到Cloudflare，源站IP就藏到CF后面了，这一步不需要花钱，免费版就能用。

接入之后记得做两件事。一是把源站防火墙设成只放行CF的回源IP段，别让攻击者绕过CF直接打源站，不然前面白做。二是把SSL模式调成Full (Strict)，别用Flexible，否则CF到源站这一段是明文的，等于前面加密后面裸奔。

我一般会先观察一周的流量图，看正常请求的分布长什么样。有了这个基线，后面配规则才知道哪些是异常。

WAF和限速规则，才是真正干活的部分

光套CF不够，默认规则比较宽松。真正拦得住CC和扫描的，是自定义规则。我通常按这个顺序配：

• 对登录页、后台路径、搜索接口单独加Rate Limiting，比如同一IP每分钟超过20次就挑战或拦截。
• 对已知的恶意UA、空UA、异常Referer做Block，这类请求正常用户基本不会发。
• 开启Bot Fight Mode，把明显的爬虫和自动化工具挡掉，代价是部分正常爬虫也会被挑战。

这里有个取舍：规则越严，误伤正常用户的风险越高。我见过把挑战设得太激进，结果海外真实访客也要过验证码，跳出率直接涨。所以规则上线后要盯着拦截日志看几天，把误伤的IP段加白。

另外5秒盾（Under Attack Mode）别长期开，它是应急用的。真被打的时候开一下能续命，平时开着等于给所有访客加一道门槛。

CF兜不住的那部分，得靠源站自己扛

这是最容易被忽略的一点。Cloudflare免费版对流量型攻击（比如UDP反射、大流量SYN Flood）的清洗能力有限，而且它保护的是HTTP层，如果你的站还跑着游戏、语音、自定义TCP服务，这些流量CF根本管不到，攻击直接打到源站IP上。

这种时候，源站是不是放在带硬防的机房里，就决定你是被打挂还是被打一下没事。我一般会建议这类业务直接上独立的高防服务器，防御能力是实打实标在配置里的，不是靠软件层挡。比如做美国业务的站，美国洛杉矶高防服务器17这种E5 2620*2配32G内存、100M带宽、月付$219的方案，防御量对中小型业务够用，价格也比想象中低。

如果攻击量级更大，比如持续被几十G的流量压着，那就得往美国洛杉矶高防服务器33这个档看，E5 2698V4*2加64G内存，月付$479，处理能力和防御上限都高一截。选哪个不是看谁便宜，而是看你被打的时候能不能扛住那几分钟。

日常维护里几个容易漏的口子

防护做完了不代表就安全了。我见过不少站CF配得好好的，结果因为一个漏洞被从内部打穿。几个常被忽略的点：

• 后台路径别用默认的/wp-admin或/admin，改掉能挡掉一大半自动化扫描。
• 插件和CMS版本及时更新，很多入侵就是从过期组件开始的。
• 数据库别开公网端口，只允许本机或内网访问。

还有一点，定期导出日志。真被打的时候，日志是判断攻击来源和调整规则的唯一依据，没有日志只能干瞪眼。

总结一下我的建议：普通展示站、博客，Cloudflare免费版加几条限速规则基本够用，成本几乎为零。有交互接口、容易被CC的站，把WAF规则配细一点，再配合源站防火墙只放行CF回源。跑游戏、语音或者被打过好几次的站，别犹豫，直接上带硬防的独立服务器，月付两三百美元换的是业务不中断，这笔账很好算。别等到站挂了才想起来买防御，那时候损失的订单远不止一台服务器的钱。