核心用法
cloudflare-guard 是一款面向基础设施工程师的 Cloudflare 配置管理技能，通过标准化的 API v4 调用实现 DNS、SSL、缓存、安全规则及边缘计算的自动化编排。其核心工作流遵循强制规划协议（Planning Protocol）：任何 API 调用前必须完成需求理解、现状勘测、执行计划构建、风险识别、顺序执行及结果汇总六个步骤，从机制上杜绝因配置错误导致的站点宕机。
技能覆盖六大功能域：
- DNS 管理：支持 CNAME/A 记录的增删改查，默认代理至 Vercel（
cname.vercel-dns.com或根域 A 记录76.76.21.21） - SSL/TLS：强制
Full (Strict)模式并启用 Always Use HTTPS，解决 522 连接超时及混合内容问题 - 缓存策略：浏览器缓存 TTL 设置、全站/URL 级缓存清除，配合 Page Rules 对 Next.js 静态资源（
_next/static/*）实施 30 天边缘缓存 - 安全防御：HTTP 速率限制（Rate Limiting）规则、Bot Fight Mode 启用，针对
/api/*路径提供 IP 级频率管控 - 标准项目初始化：七步式自动化流程，一键完成 Vercel 项目的 Cloudflare 完整接入
- 故障排查指南：522 错误、混合内容、缓存失效等典型场景的诊断清单
显著优点
1. 生产级安全机制：强制规划协议将 DNS 变更风险（如 A/CNAME 误删导致的全球解析失效）前置暴露，执行顺序强制单步验证，避免批量 API 调用的级联故障
2. Vercel 场景深度优化：预置根域 A 记录、_next/static/* 缓存规则、Full Strict SSL 等配置，减少 80% 以上的手动调研成本
3. 零凭据残留设计：明确禁止文件存储 API Token，全程依赖环境变量注入，符合最小权限原则
4. 故障可观测性：每个 API 调用均要求 jq 格式化输出验证，DNS 变更后强制传播检测，降低"配置已下发但未生效"的静默失败概率
潜在缺点与局限性
- API 版本锁定：严格绑定 Cloudflare API v4，未覆盖 v2025-01-13 等新版 Rulesets 语法，未来可能存在迁移成本
- Rate Limiting 规则粒度较粗：当前示例仅支持 IP 源特征（
ip.src），无法直接实现基于用户标识或请求头的复杂计费策略 - Workers 能力未展开：技能名称提及 Workers，但正文仅提供 DNS/缓存/安全等配置能力，边缘计算代码部署需补充
- 多区域（Multi-Zone）操作缺失：所有命令依赖单
CLOUDFLARE_ZONE_ID，批量域名管理需外部循环封装 - 回滚机制未内置：规划协议识别风险但未提供自动回滚或配置快照功能，误操作后依赖手动修复
适合人群
- SRE / DevOps 工程师：负责多项目域名接入、SSL 证书统一治理、边缘安全策略标准化
- 全栈开发者：使用 Vercel 部署 Next.js 应用，需快速配置自定义域名及性能优化
- 安全运维人员：需实施基础 DDoS 防护、Bot 管理及 API 滥用拦截，但无复杂 WAF 规则编写需求
常规风险
| 风险类型 | 场景 | 缓解措施 |
|---------|------|---------|
| **DNS 传播延迟** | 修改 proxied 记录后 5 分钟内全球解析不一致 | 强制协议第 5 步要求执行 `dig`/`nslookup` 验证 |
| **SSL 模式降级** | 误设为 Flexible 导致 522 错误或中间人攻击 | 标准化流程强制 `Full (Strict)` 并校验 Vercel 证书链 |
| **速率限制误杀** | API 限流规则阈值过低影响正常业务流量 | 规划协议要求识别"合法流量特征"，建议初始阈值 ≥100 req/min |
| **Token 泄露** | 环境变量注入不当导致 CI/CD 日志暴露 | 禁止文件存储 + 建议启用 Cloudflare Token 的 IP 白名单与有效期限制 |
| **缓存污染** | 全站清除后源站突发流量导致过载 | 技能提供 URL 级精准清除，建议优先使用而非 `purge_everything` |