核心用法
Cloudflare Guard 是一套面向 Vercel 部署场景的 Cloudflare 基础设施管理技能，通过原生 API v4 提供 DNS、SSL、缓存、安全防护的全栈配置能力。用户通过环境变量注入 API Token，执行 curl 指令完成以下操作：
- DNS 管理：添加/删除 CNAME 或 A 记录，支持根域名与子域名配置，自动启用代理（orange cloud）
- SSL/TLS 配置：强制 Full (Strict) 模式与 Always Use HTTPS，确保端到端加密
- 缓存策略：设置浏览器缓存 TTL、全站或定向 URL 缓存清除
- 安全防护：创建基于 IP 的速率限制规则、启用 Bot Fight Mode、配置 Page Rules 缓存静态资源
显著优点
1. 强制规划协议：在执行任何变更前必须完成六步规划——需求分析、现状调研、执行计划、风险识别、顺序执行、结果汇总，显著降低生产事故概率
2. Vercel 场景优化：内置 CNAME 指向 cname.vercel-dns.com 与 A 记录 76.76.21.21 的标准模板，SSL 配置与 Vercel 证书链兼容
3. 零持久化令牌：明确禁止将 API Token 写入文件，强制依赖环境变量 $CLOUDFLARE_API_TOKEN，降低凭据泄露风险
4. 原子化操作：每个 API 调用独立执行并验证响应，DNS 变更后强制验证传播状态，避免级联故障
潜在缺点与局限性
- 环境变量依赖：要求用户预先配置
CLOUDFLARE_API_TOKEN与CLOUDFLARE_ZONE_ID，缺失时无法执行任何操作 - curl 与 jq 依赖：假设执行环境已安装必要工具，未提供备用方案
- 速率限制复杂性：规则语法基于 Cloudflare Rulesets API，需理解 Expression 语法（如
http.request.uri.path matches "^/api/"），对非运维背景用户存在学习曲线 - Page Rules legacy 状态：虽然仍可用，但 Cloudflare 已转向 Cache Rules 与 Configuration Rules，长期使用可能面临弃用风险
- 无回滚机制：文档未提供自动回滚或快照恢复方案，误操作后需手动修复
适合人群
- DevOps/SRE 工程师：负责多域名、多环境的 Cloudflare 配置标准化
- 全栈开发者：使用 Vercel 部署且需要自定义边缘安全策略的独立开发者
- 技术团队负责人：需要为团队建立基础设施变更 SOP，强制引入 planning protocol 作为安全闸
常规风险
| 风险类型 | 具体表现 | 缓解措施 |
|---------|---------|---------|
| DNS 中断 | 修改 proxied 记录或误删 A/CNAME 导致解析失败 | 严格执行 planning protocol，变更前 dig/nslookup 验证当前状态 |
| SSL 降级 | Flexible 模式导致中间人攻击或 522 错误 | 强制使用 Full (Strict)，变更后验证 TLS 握手 |
| 误拦截流量 | WAF 规则过于激进导致合法用户被 block | 速率限制阈值从宽松值起步，配合日志监控调整 |
| 令牌泄露 | API Token 意外写入 shell history 或日志 | 使用 `set +o history` 或专用 secret 管理工具注入 |
| 缓存污染 | 错误 TTL 导致用户看到过期内容 | 部署后主动执行 purge_cache，关键路径设置短 TTL |
本技能不替代 Cloudflare 官方 Terraform Provider 或 Dashboard 操作，更适合快速 CLI 场景与自动化脚本编排。