快速答案：企业导入 Cloudflare，不应直接把所有 DNS 纪录一起打开代理。先导出并核对完整 DNS、确认来源站 HTTPS 凭证与防火墙、列出不能缓存的登录、付款、表单及 API 路径，再以测试网域验证 WAF 与缓存规则。正式切换 nameserver 前还要准备监控、责任人与回复步骤，才能在不影响邮件与内核交易的前提下上线。
1先盘点 DNS，不要把邮件与验证纪录一起代理
Cloudflare 官方文档说明，A、AAAA 与 CNAME 等用于 IP 解析的纪录可设为 Proxied，让 HTTP/HTTPS 流量经过 Cloudflare；MX、TXT 等其他类型则维持 DNS-only。切换前应把既有 DNS 导出备份，逐笔确认网站、API、邮件、第三方验证与内部服务用途，避免只拷贝主网域与 www，却漏掉邮件或 SaaS 验证纪录。
| 项目 | 切换前要确认 | 常见风险 |
|---|---|---|
| 网站与 API | 哪些 A、AAAA、CNAME 需要 Proxied | 服务未经代理，无法套用缓存与 WAF |
| 邮件纪录 | MX、SPF、DKIM、DMARC 是否完整 | 邮件收发或验证失败 |
| 来源站 | 真实 IP、主机名称与健康检查方式 | 切换后出现 5xx 或连接逾时 |
| 第三方服务 | 网域验证、Webhook 与 callback 是否受影响 | 登录、付款或集成流程中断 |
2HTTPS、缓存与来源站要一起设计
若使用 Full (strict) 加密模式，来源站必须提供有效且符合主机名称的凭证。缓存则应从静态图片、CSS、JavaScript 等低风险内容开始；登录后页面、购物车、个人数据、表单结果与多数 API 回应，需依应用程序行为明确排除或测试。上线后也要保留单一 URL 或指定范围的 purge 流程，避免每次更新都清除全部缓存。
- 来源站凭证：确认凭证有效期、主机名称与更新责任，不以 Flexible 模式掩盖来源站问题。
- 缓存边界：先列出可缓存与不可缓存路径，再用实际登录身分验证回应内容。
- 来源站保护：限制不必要的公开连接，同时保留健康检查与维运通道。
- 清除流程：把网站发布、紧急修正与 cache purge 的负责人及操作方式写进 SOP。
3WAF 不要一次全开，先观察再收紧
Cloudflare 的 Managed Rules 与 Custom Rules 可用来比对并处理进站请求，但规则有运行顺序，过早使用 Block 可能让后续规则无法运行，也可能误挡搜索引擎、付款回呼或企业固定来源。建议先针对管理后台、登录、表单与 API 设计情境，在测试环境或以 Managed Challenge 等可观察方式验证，再依事件数据调整例外与封锁条件。
管理后台
限制不必要地区或来源，并确认公司 VPN、维运人员与自动化工具不被误挡。
公开表单
观察异常频率、机器人与重复提交，同时验证正常客户仍能完成送出。
API 与 Webhook
逐一核对方法、路径、来源与验证机制，不使用一条过宽规则处理所有 API。
DDoS 与流量尖峰
确认网站流量实际经过代理，并创建事件查看、来源站负载与告警检查方式。
4零停机切换与上线验收清单
切换前是否已完成备份与测试？
保存 DNS 导出档、来源站设置与原 nameserver，并用测试主机名称验证首页、登录、表单、付款及 API。
切换窗口是否有人监看？
指定 DNS、网站、资安与业务窗口，持续检查解析、TLS、HTTP 状态、来源站负载与关键交易。
回复条件与操作是否写清楚？
事先定义哪些错误要关闭特定代理或规则、何时回复原设置，以及如何通知内外部用户。
维运文档也要纳入验收：至少保存 DNS 清册、代理状态、SSL/TLS 模式、缓存规则、WAF 规则与例外、API token 权限、告警收件人、变更纪录及回复进程；每次网站改版、添加 SaaS 或 API 时，也要把 Cloudflare 验证纳入上线流程。
想规划 Cloudflare 导入与网站切换？
提供目前 DNS、网站架构、来源站、关键表单与 API 范围，朔云可协助整理导入检查、规则测试与上线验收项目；实际功能与可用范围仍以 Cloudflare 当期官方文档及方案为准。