**当请求经过 Cloudflare，而且应用能承受过滤后剩余的流量时，防护效果才好。**开启一个选项，并不能保护通往服务器的所有路径。
以网店为例，攻击者可能大量请求商品图片、反复调用昂贵的搜索接口，或者直接访问服务器。这些行为消耗的资源不同，需要多层处理。
将网站支持的 DNS 记录设为 proxied。访问者会先到 Cloudflare，再到 origin，也就是实际运行网站的源站。DNS-only 记录只解析名称，不会让 HTTP 流量经过这条防护路径。
Browser -> Cloudflare -> Origin -> Database
这是基础：Cloudflare 只能过滤到达它的请求。要检查网店所有公开主机名，包括 API，而不是只检查主域名。
如果攻击者仍能直接访问源站，就能绕过过滤。将公网 Web 入站限制为适当的 Cloudflare IP 段，并保持更新。也可以评估 Cloudflare Tunnel，通过出站连接避免暴露公网入站 Web 端口。
管理入口应走独立受保护路径，数据库不要直接暴露在公网。既要测试经过 Cloudflare 的正常访问，也要测试直连会被拒绝。仅隐藏 IP 地址是不够的。源站保护。
检查托管 DDoS 防护及套餐提供的控制能力，添加合适的 WAF 规则。WAF 会在转发前检查 HTTP 请求中的可疑模式。DDoS 防护与 WAF 处理的问题有交集但不相同，任何一项都不能证明通过的请求一定成本很低。
从能够解释的规则开始，观察受影响流量；如果误拦真实客户，应有针对性地调整。拦截数量大，本身并不等于成功。参见 Cloudflare 的 DDoS 配置与调优。
请求缓存图片对源站的成本，通常远低于扫描大量数据库记录的搜索。应根据正常使用情况和后端服务能力，为昂贵接口设置速率限制。
不存在适合所有系统的安全阈值。观察正常高峰，谨慎引入限制，同时衡量后端压力下降和正常请求被拒绝的情况。
缓存公开图片和静态文件，让重复请求不必到达源站。对网店而言，这减少了反复发送同一商品图片的资源消耗。
个人购物车和账户页面需要不同规则，不能把其他用户的数据返回给当前用户。缓存动态响应前，应检查缓存键和绕过条件。缓存减少重复工作，但不会自动保证登录或结账在高负载下安全。
Under Attack mode 可以在事件期间加入浏览器挑战。应针对受影响的浏览器路由评估，并在适当时机撤销临时措施。机器客户端和支付 webhook 可能无法完成浏览器挑战，因此需要合适的认证和针对性控制。
最后，一边观察源站延迟、CPU、数据库压力和错误，一边验证真实客户可以浏览和完成结账。如果直连网络攻击占满源站链路，应联系托管商进行上游防护。目标是持续提供有用服务，而不是承诺任何攻击都不会造成中断。
一个包含详细解答的 IT 面试题库——从初级到高级。
捐赠