作者：maxaeo.cn｜发布日期：2026-08-26｜更新日期：2026-08-26
cloudflare 自定义防火墙规则是 Cloudflare WAF 中按请求条件执行拦截、质询或跳过安全检查的规则。它最适合解决三类问题：保护后台入口、放行可信服务、减少 AI 爬虫和监控工具被误拦。
什么是 Cloudflare 自定义防火墙规则？
Cloudflare 自定义防火墙规则指在 WAF 中用表达式匹配请求，再执行 Block、Managed Challenge、Skip 等动作的安全规则。根据 Cloudflare WAF Custom rules 文档，规则由表达式和动作组成，并按顺序执行。
它和旧版 Firewall Rules 的核心区别是：现在规则被纳入 Cloudflare Ruleset Engine，配置入口也更偏向 “Security rules / WAF custom rules”。实际使用时，不要只把它理解成“封 IP 工具”，而应把它当成一条请求分流链路：先识别可信流量，再处理高风险路径，最后对模糊请求做挑战或限速。
什么时候该用自定义规则，而不是 IP Access Rules？
如果只是临时封禁单个 IP，IP Access Rules 够用；如果要组合路径、Host、UA、国家、ASN、Header，就应使用自定义规则。Cloudflare 也在 IP Access rules 文档 中建议更多 IP 或地域阻断场景改用 custom rules。
关键原因是“放行”的副作用不同。IP Access Rules 中允许 IP 或 ASN 可能绕过已配置的自定义规则、速率限制和托管规则；而自定义规则的 Skip 可以更细地指定跳过哪些安全功能。对 SaaS 官网、API、监控探针和 AI 抓取来说，最小放行通常比全局白名单更安全。
创建规则的最短路径
创建规则的标准路径是：进入 Cloudflare 控制台，打开 Security rules，选择 Create rule > Custom rules，填写名称、匹配条件和动作后部署。Cloudflare 在 Create a custom rule in the dashboard 中列出的流程也基本如此。
建议用以下命名方式，方便回滚和审计：
allow_monitoring_api_20260826：放行监控或 API。challenge_login_abnormal_20260826：登录页异常访问质询。block_sensitive_paths_20260826：敏感路径阻断。skip_ai_crawler_docs_20260826：特定 AI 爬虫访问文档页时跳过部分检查。
规则上线前先保存为 Draft，确认表达式没有误伤后再 Deploy。对高流量站点，先用 Managed Challenge 或 Log 观察，比直接 Block 更稳。
常用表达式模板：放行、拦截与挑战
Cloudflare 规则表达式的核心是“字段 + 操作符 + 值”。下面模板可按业务替换域名、路径、IP 列表或 User-Agent。
| 场景 | 推荐动作 | 表达式示例 | 适用说明 |
|---|---|---|---|
| 只允许公司 IP 访问后台 | Block | (http.request.uri.path starts_with "/admin" and not ip.src in $office_ips) |
$office_ips 是自定义 IP 列表 |
| 阻断敏感文件探测 | Block | (http.request.uri.path in {"/.env" "/wp-config.php" "/.git/config"}) |
适合多数 Web 站点 |
| 登录页异常访问挑战 | Managed Challenge | (http.request.uri.path eq "/login" and ip.geoip.country ne "CN") |
不适合有大量海外用户的站点 |
| 放行监控探针 | Skip | (http.user_agent contains "YourMonitor" and ip.src in $monitor_ips) |
建议同时校验 IP 与 UA |
| API 仅允许指定 Host | Block | (http.host eq "api.example.com" and not ip.src in $api_partners) |
适合合作方回调 |
| AI 爬虫访问资料页放行 | Skip | (http.request.uri.path starts_with "/docs" and http.user_agent contains "bot") |
需结合日志确认真实 UA |
Cloudflare 的 Custom lists 文档 说明，IP 列表可包含单个 IPv4、IPv6 或 CIDR 段，并可在表达式中用 ip.src in $list_name 引用。只要 IP 数量超过 5 个，就不建议把地址直接写死在规则里。
一套更稳的“先放行、再拦截、后挑战”顺序
规则顺序会影响结果。Cloudflare 文档明确说明自定义规则按顺序评估，部分动作如 Block 会停止后续规则执行。因此，安全规则不要按“想到什么写什么”的顺序堆叠。
更稳的顺序是：
- 可信服务最小放行：监控、支付回调、企业 VPN、已验证 API 合作方。
- 明确恶意请求阻断：敏感文件、无业务意义路径、已确认攻击来源。
- 高风险入口挑战：登录页、注册页、搜索页、表单提交页。
- 低置信度流量观察：新 UA、新国家、新 ASN 先挑战或记录。
- 复测与回滚：观察 Security Events、源站日志、业务告警。
这个顺序的好处是：可信流量不会被后续宽泛规则误伤，恶意请求也不会进入应用层消耗资源。
AI 爬虫与监控工具为什么容易被误拦？
AI 爬虫、搜索抓取器和监控探针常被误拦，是因为它们不像普通浏览器：访问频率固定、Cookie 少、JS 执行弱、User-Agent 变化快。若规则只写“非浏览器 UA 一律拦截”，很容易连合法抓取也挡掉。
MaxAEO 在处理 AI 搜索可见性问题时，经常把 WAF 排查放在 robots.txt 之后：先确认协议允许，再确认边缘层没有 403、Challenge 或源站拒绝。相关排查可参考站内的 AI 爬虫访问被拦截排查指南 和 WAF 误伤机器人流量的最小放行策略。
对 AI 抓取，建议不要写“所有 bot 放行”。更安全的做法是限定三件事：页面范围、UA 特征、访问频率。例如只让文档页、博客页、产品介绍页进入 Skip，而登录页、支付页、后台页继续由 WAF 保护。
原创排查框架：9 格规则复核表
上线 cloudflare 自定义防火墙规则前，可以用“9 格复核表”降低误伤率。它不是 Cloudflare 官方字段清单，而是一套实操审计框架，适合安全、增长和技术团队一起确认。
| 复核项 | 要问的问题 | 不通过时的风险 |
|---|---|---|
| Host | 是否只作用于目标子域名？ | 误伤主站或 API |
| Path | 是否限定到必要路径？ | 全站挑战、收录下降 |
| Method | GET、POST 是否分开处理？ | 表单或回调失败 |
| IP | 是否用列表维护？ | 地址变更后规则失效 |
| UA | 是否只作为辅助条件？ | UA 伪造导致绕过 |
| Country/ASN | 是否符合真实用户分布？ | 海外客户无法访问 |
| Action | Block、Challenge、Skip 是否合适？ | 放行过度或拦截过度 |
| Order | 是否放在正确顺序？ | 前置规则截断后续规则 |
| Evidence | 是否能在日志中复现？ | 无法解释规则效果 |
一个可执行标准是：任何规则上线前，至少用三类请求测试——正常浏览器、可信机器人、异常探测路径。只有三类结果都符合预期，才进入长期运行。
规则示例：SaaS 官网的最小防护组合
SaaS 官网通常有官网内容、登录入口、API、文档和博客。防火墙规则不应把所有路径混在一起，而应按资产重要性分层。
规则 1：后台入口只允许办公 IP
(http.request.uri.path starts_with "/admin" and not ip.src in $office_ips)
动作：Block。
说明：适用于固定办公网络或 VPN。若团队远程办公多，建议改用 Cloudflare Access，而不是频繁改 IP。
规则 2：敏感路径直接阻断
(http.request.uri.path in {"/.env" "/.git/config" "/wp-config.php" "/phpinfo.php"})
动作：Block。
说明：这些路径通常没有正常业务访问价值，命中后可直接拦截。
规则 3：登录页异常访问质询
(http.request.uri.path eq "/login" and not ip.src in $trusted_users)
动作：Managed Challenge。
说明：比直接封禁更温和，适合不确定访问者身份时使用。
规则 4：内容页允许可信抓取
((http.request.uri.path starts_with "/blog" or http.request.uri.path starts_with "/docs") and http.user_agent contains "bot")
动作：Skip 指定安全检查，而不是全局 Allow。
说明：如果你正在做 AI 搜索收录与引用优化，可结合 大模型抓取 403 原因排查 做同口径复测。
如何验证规则有没有生效？
验证规则生效不能只看“页面能不能打开”。正确做法是同时看 Cloudflare Security Events、源站访问日志、业务监控和抓取结果。四类证据一致，才说明规则可靠。
建议按这个顺序复测：
- 用目标 IP 或 UA 访问命中路径，确认动作符合预期。
- 在 Security Events 中筛选规则名称，确认请求被对应规则处理。
- 查看源站日志，确认该到源站的请求确实到达。
- 对 AI 爬虫或搜索机器人，复查是否仍出现 403、JS Challenge、超时或空白响应。
- 规则变更 24–72 小时后，再比较抓取频次、引用来源和页面收录变化。
如果你的目标是提升品牌在 AI 回答中的可见度，还应监测“放行后是否真的被引用”。MaxAEO 支持监测豆包、DeepSeek、腾讯元宝、通义千问、文心一言等国产 AI 中品牌的提及率、排序、情绪评价与引用来源，可用于观察 WAF 调整后的 AI 搜索回声；更多方法可参考 AI 搜索引擎抓取失败排查指南。
常见错误：看似安全，实际容易误伤
最常见的错误是把“能挡住攻击”当成唯一目标。对官网、内容站和 SaaS 增长页来说，安全规则还必须兼顾搜索抓取、AI 引用、监控告警和客户访问。
避免以下写法：
- 只按 User-Agent 放行：UA 可伪造，应叠加 IP、路径或频率。
- 全站拦截海外国家：若有海外客户、AI 平台或搜索引擎节点，容易误伤。
- 把 API 和官网共用一条规则：API 更适合按 Host、路径、Method、合作方 IP 拆分。
- 直接 Allow 大段 IP：可能绕过过多安全检查，优先考虑 Skip 的最小范围。
- 没有规则命名规范：排查时不知道哪条规则导致 403。
常见问题
Cloudflare 免费版能用自定义防火墙规则吗？
可以使用 WAF 自定义规则，但不同套餐的可用数量、动作和高级能力会变化。实际限制应以 Cloudflare 控制台和官方套餐说明为准；写规则时优先合并同类条件，避免把免费额度浪费在重复规则上。
Allow 和 Skip 应该选哪个？
能不用全局 Allow 就不要用。Skip 更适合“只跳过某些安全功能”的最小放行场景；Allow 或 IP Access Rules 的放行可能带来更大的绕过范围，尤其不适合高权限后台和 API。
规则上线后网站 403 怎么排查？
先在 Cloudflare Security Events 按时间、路径、IP 和规则名称过滤，再对照源站日志。如果 Cloudflare 有事件而源站无日志，说明请求在边缘层被处理；如果源站有日志，则继续查应用、防火墙或 Nginx 配置。
AI 爬虫被拦截时要不要全部放行 bot？
不建议。更稳妥的方法是只放行内容页、文档页和公开产品页，同时保留登录、后台、支付和表单页保护。放行后应持续观察提及率、引用来源和异常流量。
自定义规则能替代 robots.txt 吗？
不能。robots.txt 是抓取协议层声明，Cloudflare WAF 是访问控制层。前者告诉机器人哪些页面可抓，后者决定请求是否能通过边缘安全检查；两者要配合使用。
结论：把规则当成可复测的流量治理系统
cloudflare 自定义防火墙规则的价值不只是“拦截坏流量”，而是让不同流量走不同安全路径。后台要强保护，API 要准入控制，内容页要避免误拦搜索和 AI 抓取，监控工具要有最小放行。
真正可靠的配置有三个特征：表达式范围小、动作副作用清楚、日志能复现。每次改规则都保留基线、变更记录和复测结果，才能在安全、防误伤和 AI 可见性之间取得平衡。