记录下为了R2防盗搞的安全规则 踩坑之后

坑点 亲测 确实
为什么 GUI 填选会失败，而直接复制表达式能成功？
这是 Cloudflare（以及很多其他云厂商的 WAF 控制台）可视化界面的一个常见通病。原因主要有两点：

逻辑分组（括号）的丢失与错乱
当你直接输入 (A) AND (B) AND (C) 时，底层引擎非常清楚这几个条件的平级关系。但在 GUI（图形界面）中，如果你不小心点错了“Add AND”和“Add OR”的层级，或者 UI 自身渲染逻辑组合时出现了偏差，它在后台生成的实际代码可能变成了 A AND (B AND C) 或者其他奇怪的结构，导致判定条件变形。

“空字符串”的判定 Bug
在处理 http.referer ne ""（来源不为空）这个条件时，GUI 界面要求你把值“留空”。但很多时候，浏览器前端在提交表单时，会直接把这个“空框”忽略掉，或者将其解析为 null 而不是 ""（空字符串）。这导致这条关键的防误杀规则在保存时并没有真正生效。

结论： 可视化界面只是为了方便新手点选的“皮囊”，“编辑表达式（Expression Editor）”才是真正的底层灵魂。对于涉及多重 AND/NOT 以及包含空值的复杂安全规则，直接写表达式永远是最准确、最不容易出 Bug 的方式。
在这里输入 第一行和最后一行是关键。第一行避免了搜索引擎等来源，因为refer不为空，而导致拦截。最后一行是白名单，不能省略。如果有其他子域名，也在后面加上

ends_with(http.host, ".mydomain.com") 
and (http.referer ne "") 
and (not http.referer contains "domain-A.com") 
and (not http.referer contains "domain-B.com") 
and (not http.referer contains "img.mydomain.com")

示意图

用 AND（与） 把这 5 个条件串联起来
在 AND 逻辑的死规定里：必须 5 个条件 100% 全部为 True（命中），防火墙才会执行最终的“拦截 (Block)”动作。 只要中间有任何一个条件断掉了（变成了 False），整条链条就断了，请求就会穿透这条规则，被直接放行 (Pass)。