快速答案：企業導入 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 當期官方文件及方案為準。