Cloudflare 該不該掛？免費版評估、橘雲灰雲選擇與上線前檢查清單

「網站要不要掛 Cloudflare」這個問題，答案取決於網站形態多過取決於 Cloudflare 本身。如果你經營的是 WordPress 這類動態站、有表單或會員登入的品牌官網，掛上免費方案多數時候是划算的：DNS 管理、基礎 CDN 快取、自動續期的 SSL 憑證、基礎 WAF 與不按流量計費的 DDoS 緩解都包在免費層。如果你的網站已經部署在現代靜態託管平台上，邊際效益會小很多，因為平台本身就附全球分發。如果你跑的是電商或金流相關服務，可以先別急，因為結帳流程、webhook 回呼與 IP 白名單這三個環節都可能在切換當天出狀況，需要照著檢查清單走完再上。

比「要不要掛」更值得先知道的限制是：Cloudflare 的免費與 Pro 方案只支援一種接入方式，就是把網域的 DNS 權威整個搬到 Cloudflare（官方文件稱為 primary setup），在網域商那邊改 nameserver。這代表真正容易出事的環節在搬家當下 DNS 記錄有沒有補齊，開橘雲反倒相對單純，而最容易漏的就是郵件的 MX 記錄。這篇會用決策的順序把整件事走一遍：先分診、再看免費與付費的真實分界、橘雲灰雲的實務後果、切換前的防呆準備與上線當天的執行順序、挑戰頁對轉換率的影響，以及 AI 搜尋能見度的關聯。文內的方案價格、功能分界與政策，以 2026 年 10 月 12 日查核的Cloudflare 官方方案頁與開發者文件為準；這個網站本身就部署在 Cloudflare Pages 上，文中標明為本站經驗的段落來自我們自己的維運，其餘均以官方文件為依據。

先分診：三種網站形態，三種不同答案

先把「網站」這個詞拆開。同樣叫網站，純靜態站、動態站與電商站在 Cloudflare 面前遇到的問題完全不同，把三種情境混在一起討論，是大多數入門文讀完還是不敢動手的原因。分診的判準只有一個：你的頁面是事先產生好的檔案，還是每個訪客來了才即時計算。

純靜態站：掛的意義在管理與防護，不在加速

用 Astro、Hugo、Next.js 靜態輸出之類的工具產出純 HTML，部署在現代託管平台的網站，平台本身已經把檔案分發到全球節點，再疊一層 Cloudflare 對速度的提升很有限。以本站為例，整個網站部署在 Cloudflare Pages 上，DNS、憑證、快取與發佈都在同一個生態裡完成，這時候討論「要不要再掛一層 Cloudflare」幾乎是個假問題，因為你已經在裡面了。這類網站若另外有子網域服務，例如跑在別台主機上的 API、自架的表單後端或內部工具，把網域 DNS 統一搬到 Cloudflare 管理仍然有用：免費方案的自訂規則可以拿來保護那個暴露在外的 API 端點，速率限制規則能擋住暴力嘗試。但這是管理集中與防護的好處，不是加速，對外宣稱時要分清楚。

純靜態站還有一個常被忽略的實際考量：防護對象消失了。沒有登入、沒有資料庫、沒有表單提交，攻擊面本來就小，WAF 與挑戰頁能為你擋掉的東西不多。這並非要你別掛，只是掛了之後別期待看得到明顯差異，把時間花在內容與圖片優化上效益更高。

WordPress 與動態站：收益最明確的一群

每個頁面都由 PHP 與資料庫即時算出來的網站，是 Cloudflare 免費方案收益最大的族群，原因有三個。第一，圖片、CSS、JavaScript、字型檔這些靜態資產可以被邊緣快取，訪客第二次載入時不必回源站，這部分不用改任何程式碼就生效。Cloudflare 預設按副檔名快取，涵蓋常見的圖檔、字型、css、js、pdf 等數十種，連 robots.txt 都在預設快取範圍內；原始回應沒有快取標頭時，200 回應的邊緣快取時間預設是兩小時。第二，源站 IP 被遮住之後，針對主機的掃描與小規模攻擊會先撞上 Cloudflare 的邊緣，主機負擔下降，這對每月流量費按量計算的主機來說直接反應在帳單上。第三，免費方案附帶的基礎 WAF 與 DDoS 緩解，對沒有專職維運的中小網站來說，是多出來的一層保險。

代價是這類網站也最容易踩到快取與登入的坑：快取規則把登入後的頁面快取住、挑戰頁打斷了 AJAX 請求、加密模式選錯造成轉址迴圈。這些都有標準解法，後面的切換前準備會逐項展開。已經在用頁面快取外掛（例如快取型效能外掛）的 WordPress 站要多想一層：外掛在源站產生的快取，與 Cloudflare 在邊緣產生的快取，是兩層不同的副本，清除快取時要意識到自己清的是哪一層，改版後訪客看到舊內容時也要分別排查；多數快取外掛都有與 Cloudflare 的整合設定，讓你在 WordPress 後台就能同步清除邊緣快取，裝了比沒裝省事。若你對 CDN 本身的選擇還在猶豫，例如不確定自己的站到底是頻寬瓶頸還是程式瓶頸、該不該上任何 CDN，站上的CDN 運作原理指南有從瓶頸判斷出發的完整決策框架，那套「地域、資源、命中、成本」四個檢查點適用於所有 CDN 服務商；這篇不重複那套判斷，直接聚焦在 Cloudflare 這個特定平台的導入。

電商與金流相關站：可以掛，但檢查清單要加倍

有購物車、結帳、會員系統或串接第三方金流的網站，同樣能從 Cloudflare 獲得快取與防護的好處，但三個環節需要額外對待。結帳與購物車頁面絕對不能被快取，這類帶有個人資料的頁面一旦被存成邊緣的共用副本，兩個訪客可能看到彼此的訂單內容，這不只是體驗問題而是交易安全問題。金流服務的 webhook 回呼若在你主機的防火牆上有 IP 白名單，開橘雲之後回呼來源會變成 Cloudflare 的 IP 範圍，白名單不改就會漏單，而漏單的排查通常要同時看金流商後台與主機日誌，中間隔著一層代理時難度會上升。支付頁面對挑戰頁特別敏感，結帳到一半被要求證明自己是真人，轉換率直接受傷，行動裝置上的舊版瀏覽器又比桌面更容易卡關。切換後的前幾天也建議安排幾筆小額的測試訂單，把完整的下單到收款流程走一遍，webhook 有沒有準時到、訂單狀態有沒有正確更新，都是帳面看不出來、要實際跑一次才知道的事。這些都有解，但每一項都該在切換前確認，等切換後再補救的代價高得多。

還有兩種情況建議先緩一緩。源站主機老舊到無法安裝任何可信憑證的，會卡在加密模式的選擇上，先換主機或先解決憑證再談 Cloudflare。已經向主機商加購 CDN 或 WAF 套裝的，先盤點兩邊功能重疊的程度，兩層快取疊在一起時，命中率互相污染、快取標頭互相改寫，除錯時很難判斷問題出在哪一層，多數時候留一層就夠。

掛上之後，實際改變的三件事

把行銷頁面的形容詞全部拿掉，接入 Cloudflare 之後你的基礎設施實際上發生三個變化，後面所有的好處與麻煩都從這三件事衍生。理解了這三件事，遇到任何怪現象時你會知道往哪個方向查。

第一，DNS 權威搬家。免費與 Pro 方案只有 primary setup 一條路：在網域商把 nameserver 改成 Cloudflare 指定的兩組，之後全世界的 DNS 查詢都以 Cloudflare 上那張記錄表為準。舊的 DNS 後台從此只是備份，之後改記錄要改新的地方，在舊後台改是不會生效的。Cloudflare 加入網域時會掃描舊記錄自動帶入，但官方設定文件明講這個快速掃描不保證找齊所有記錄，需要人工逐筆核對，這是後面切換前準備的第一項。切換後網域會先進入 pending 狀態，Cloudflare 要向舊的權威確認擁有權，官方說最多可能需要 24 小時才完全生效，期間新舊兩邊的記錄並存。DNS 本身的運作機制（記錄類型、四層委派、TTL 傳播）不是這篇的重點，站上DNS 設定教學有完整說明。

第二，流量路徑改變。訪客的瀏覽器不再直接連到你的主機，而是連到 Cloudflare 的邊緣節點，由邊緣決定用快取回應還是回源站拿資料。快取、WAF 規則、DDoS 緩解、速率限制、挑戰，全部發生在這一段。這也是為什麼同樣的設定問題，在這條新路徑上的後果會被放大：一條寫錯的規則影響的是所有訪客而不只是某個地區，而規則生效是即時的，沒有漸進發布的緩衝。反過來說，這也是防護價值的來源：攻擊流量有機會先在邊緣被緩解，源站負擔跟著下降，前提當然是流量真的經過邊緣，源站 IP 外洩的直連路徑不在此列。

第三，源站身分被遮蔽（僅橘雲）。DNS 查詢不再回傳你主機的真實 IP，而是回傳 Cloudflare 的 anycast 位址，這筆記錄從此不對外公開源站位置，這是防護的起點。但要把話說準：被隱藏的是「這筆記錄」，不是「你的 IP 已經不存在於外界」；若源站 IP 曾經透過歷史 DNS 查詢記錄、某個灰雲子網域或對外的其他服務而外洩，拿到舊 IP 的人仍然可以直接連你的主機，要真正堵死這條路，得靠源站防火牆白名單、Authenticated Origin Pulls 或 Cloudflare Tunnel 補上。遮蔽同時也是主機日誌與防火牆白名單要跟著調整的原因，下一節專門講這件事的實務後果。

免費版到底包什麼：用情境看分界

價格先講清楚：免費方案 0 元，Pro 方案年繳每月 20 美元、月繳 25 美元，Business 方案年繳每月 200 美元、月繳 250 美元，再上去是談合約的企業方案。方案頁對免費版的定位寫得直接：適合「非商業關鍵」的個人與嗜好專案。定位是一回事，實際額度是另一回事，下表把 2026 年 10 月查核的受管理規則、自訂規則與其他產品文件的分界，整理成可以直接對照的清單。

這張表要怎麼用？把它當成「你以為需要付費、其實免費就有」與「你以為免費、其實要付費」兩個方向的對照。往前者看，多數中小網站最需要的三樣東西（靜態快取、SSL、基礎防護）都在免費層，而且不是閹割版。Universal SSL 是自動簽發、自動續期的正式憑證，不是試用，所有方案一致；DDoS 緩解在官方方案對照表上列為 Unmetered（不按用量計費），同樣是全方案一致，被攻擊的防護量不會反映在帳單上。同一張對照表上，CDN 也列為全方案內建，整張表沒有任何按流量或頻寬計量的欄位，「流量成長要多付錢」這件事在Cloudflare 的方案對照表上不存在；免費與付費的差異不在流量或頻寬，而是主要落在功能、規則數與上傳上限。免費方案也拿得到 WAF：能部署官方維護的 Free Managed Ruleset，它的定位是防「高影響、被廣泛利用」的漏洞，官方描述這組規則在多數應用上可以安全開啟；外加五條自訂規則，做「擋特定路徑的惡意請求、給管理後台掛挑戰」這類常見需求足夠。WAF 在邊緣層實際檢查什麼、規則命中後有哪些處置方式，站上的WAF 原理指南有完整拆解。

一個反直覺的細節值得記下：受管理規則檢查請求內文的大小上限，免費方案是 1 MB，付費方案預設反而更低（要聯絡支援調升，企業版是 128 KB）。這提醒我們方案比較不能靠直覺堆疊，額度差異的方向有時跟價格相反，實際需求（你的表單會不會送超過 1 MB 的請求內文）才是判準。

往後者看，最常被誤會的是三個。其一是完整版受管理規則集：Cloudflare Managed Ruleset 與 OWASP Core Ruleset 都從 Pro 開始，免費方案只有 Free Managed Ruleset，覆蓋範圍比完整版窄（官方也註明部署過完整版就不需要再開免費版規則集）。對沒有登入與資料庫的官網，免費規則集通常夠用；對有會員系統、暴露攻擊面大的站，這就是要不要升 Pro 的主要評估點。其二是 Polish：自動壓縮圖片、去除中繼資料的一鍵優化，Pro 起才有（官方行銷頁把它寫成 lossless image optimization，從 Pro 開始出現），它的特色是不改圖片網址、不需要改頁面原始碼，邊緣取圖時自動處理。其三是圖片即時縮放，這個能力現在屬於 Images transformations 產品，計價跟網站方案層級脫鉤：每個月前 5,000 次唯一轉換免費（所有方案都一樣），超過之後新的轉換會回 9422 錯誤，已經產生的快取版本照常供應、不收費，要繼續就得升級 Images 付費方案，費用是每 1,000 次轉換 0.5 美元。這裡的「唯一轉換」定義對成本很關鍵：同一張圖用同一組參數，一個月內重複被請求只計一次，所以小站做響應式圖片通常貼著免費額度就能運作，真正做到多尺寸多情境輸出時才會碰到付費線。

方案之外還有加值服務：Smart Shield 與 Argo Smart Routing 在 Cloudflare 的網路加值方案頁上是合售套裝，每月 5 美元起，走智慧路徑與分層快取降低延遲，適合源站在海外、訪客集中在台灣的站再評估。還有一個不屬於方案比較、但常與免費評估一起出現的產品：R2 物件儲存。它跟網站方案分開計費，免費額度是每個月 10 GB 的標準儲存空間、一百萬次 Class A 與一千萬次 Class B 操作，而且直接從 R2 流出到網際網路的流量不收費，WordPress 圖床與備份是很常見的用途，站上的R2 完整指南有額度拆解與三種規模的費用試算。把 R2 當成「免費生態的另一塊拼圖」來理解，會比把它跟 Pro 方案放在一起比價更清楚。

實務建議是：先免費跑一陣子再決定升級。開通後讓事件紀錄累積幾週，看你實際被什麼攻擊、五條規則夠不夠用、快取命中率如何、免費額度的圖片轉換吃掉多少，再判斷 Pro 的 20 條規則、完整規則集與 Polish 對你有沒有具體意義。讓資料說話，別憑「感覺付費比較安全」的直覺做決定。

橘雲與灰雲：同一張記錄表上的兩種後果

DNS 記錄列表裡那朵雲的顏色，控制的是「這筆記錄的流量要不要經過 Cloudflare」。橘雲（Proxied）代表經過：訪客解析到的是 Cloudflare 的 anycast 位址，快取、WAF、挑戰都作用在這段流量上。灰雲（DNS only）代表不經過：Cloudflare 只代管解析，回應的是你源站的真實 IP，其餘一切照舊。規則本身很簡單：官方的代理狀態文件寫明只有 A、AAAA、CNAME 三種記錄能開橘雲，MX、TXT 這類永遠是灰雲；用儀表板接入網域時，橘雲預設是打開的，所以「掛了之後流量就經過 Cloudflare」是預設狀態，不是額外選項。這段講的是「開與不開各自發生什麼」，查詢層的機制細節同樣不展開。

開橘雲之後，有三個具體後果會在你沒注意的地方發生。第一個是源站看到的來源 IP 全變成 Cloudflare 的位址。主機的存取日誌、fail2ban 這類按 IP 封鎖的工具、分析報表裡的訪客地理分佈，通通會失真。解法是改讀 Cloudflare 附加的 CF-Connecting-IP 請求標頭，官方標頭文件說明它攜帶真實訪客 IP、全方案都有；另一個名字類似的 True-Client-IP 標頭是企業方案限定，一般站用不到。Apache 與 Nginx 都有官方對應的設定寫法可以把這個標頭還原成日誌裡的客戶端 IP，WordPress 也有現成外掛做同一件事，設好之後日誌與分析就回到原本的樣子。這一步不做的話，後果不只是報表難看：你的安全分析會把所有流量看成來自少數幾個 IP，異常偵測基本失效。

第二個是源站防火牆的白名單邏輯要反過來想。開橘雲後，所有進到主機的請求都來自 Cloudflare 的 IP 範圍，這範圍官方在Cloudflare 的 IP 清單頁公佈，IPv4 與 IPv6 都有，而且會不定期變動，寫進白名單前要先有「這份清單將來要跟著更新」的心理準備。想鎖死「只有 Cloudflare 能連我」的站，白名單就放這份清單。另一個方向則要把兩種連線拆開講，這是最多人搞混的地方：你的主機「對外」發起的連線（例如主機主動呼叫金流服務的 API）不經過 Cloudflare，來源 IP 就是主機自己的位址，橘雲不會改變它，所以「交易對象鎖我的源站 IP」這類白名單不需要動。會變的是「打進來」的方向：金流服務回呼你的 webhook 網址時，若那個主機名稱開了橘雲，你的主機看到的回呼來源就是 Cloudflare 的 IP 範圍，源站防火牆要嘛允許這段範圍進來，要嘛讓 webhook 專用的子網域維持灰雲直連。極端一點的防護還有 Authenticated Origin Pulls（用 mTLS 憑證證明請求來自 Cloudflare）與 Cloudflare Tunnel（主機根本不開對外埠）兩條路，這篇點到為止。

第三個常見疑慮：Google Search Console 的驗證會不會受影響。Google 官方說明寫明網域資源（Domain property）必須用 DNS 記錄驗證、也是唯一方法（網站本身架在 Google 產品上的情況除外），而橘雲改寫的是 A 與 AAAA 的回應值，TXT 記錄不在影響範圍內，所以「開橘雲」這個動作本身不會弄掉驗證。真正的風險點在搬家那一步：nameserver 切過去之後，舊後台裡的 TXT 驗證記錄若沒有搬進 Cloudflare 的記錄表，Google 定期複查時找不到記錄，驗證就會失效，通知信常在幾天後才到。網址前置字元類型的資源驗證方式選擇較多（HTML 檔案、meta 標籤等），同樣不受橘雲影響。所以對策在於搬家時把 TXT 一併搬齊，不必因為擔心驗證而不敢開橘雲，這又回到切換前準備的第一項。順帶一提，Google 文件也明講新增資源這件事本身不會影響網站在搜尋結果中的呈現，驗證只是取得資料的鑰匙。

灰雲不是次等公民，它有明確的用途，也有一個要誠實面對的代價。郵件相關記錄天生就是灰雲；拿來證明網域擁有權的 CNAME（例如部分雲服務的驗證）官方明確建議不要代理；金流回呼若只想讓它直連主機、不想經過邊緣的快取與規則，讓那個子網域保持灰雲是最省事的做法。代價是官方文件直說的：灰雲記錄會把源站真實 IP 回應給任何查詢的人，源站因此失去一層針對性攻擊的保護，而且 Cloudflare 對這些流量只有 DNS 層的分析，沒有 HTTP 層的分析。換句話說，灰雲換到的是單純，失去的是隱藏與可觀測性，關鍵子網域要不要灰雲，就是在這兩者之間取捨。

還有兩個容易忽略的行為。同一主機名稱下有多筆 A/AAAA 記錄時，只要其中一筆開了橘雲，全部都會被視為橘雲處理，想做「同名的其中一筆直連」行不通，要拆成不同子網域名稱。開橘雲的記錄 TTL 固定是自動的 300 秒、不能改，這是為了 Cloudflare 更換 anycast 位址時能快速生效，對一般站沒有實際影響，但對有特殊 TTL 需求的服務（某些舊系統會快取 DNS 很久）要先知道這一點。

想在切換前後親眼確認橘灰雲的差別，用 dig 就看得到。灰雲狀態下查你的網域，回應是源站主機的 IP；點成橘雲後同樣的查詢會換成 Cloudflare 公佈的 anycast 網段裡的位址，跟你源站的 IP 完全無關。這個一分鐘的觀察比讀十頁文件更有感：你親眼看到這個主機名稱從此回應的是 Cloudflare 的位址，而不再公開你的源站。後面所有關於日誌、白名單與快取的調整，都是在適應這個新事實；也記得前面那句但書：被隱藏的是這筆記錄，若源站 IP 早已外洩，針對性的防護要另外補。

切換前的準備：按「出事後多快被發現」排序

準備清單怎麼排順序？用的原則不是「哪個主題重要」，而是「出了事多久才會被發現」。越晚浮現的問題越要往前面攔，因為等你察覺時，傷害往往已經擴散了好幾天；當場就炸的問題反而相對好處理，至少你立刻知道是哪個動作造成的。照這個原則，切換前的準備從最晚爆雷的郵件與非網頁記錄開始，接著處理不定時浮現的快取與個人化內容污染，立刻會被發現的加密模式錯誤放在壓軸，因為它至少會當場告訴你錯在哪裡。

幾天後才會被發現的：郵件與其他非網頁記錄

整個導入流程中後果最嚴重的一步，是 nameserver 切換當下記錄表不完整。網站掛了訪客會看到，郵件斷了往往要幾天後才有人發現信沒收到，而免費方案強制走 primary setup，這一步躲不掉。照下面的順序做。

第一，切換前在舊 DNS 後台把整張記錄表匯出或截圖，包含你平常根本不看的那堆 TXT。第二，加入 Cloudflare 讓它掃描帶入記錄之後，逐筆比對，官方文件明講快速掃描不保證找齊，並且把郵件記錄列在需要特別注意的清單上。第三，重點核對五類：MX（郵件收信，注意優先權數字與郵件主機位址都要一致）、SPF 的 TXT（授權哪些服務代寄）、DKIM 的 CNAME 或 TXT（簽章金鑰）、DMARC 的 TXT（政策與回報信箱）、各種網域驗證 TXT（Google、Microsoft、網域商轉移鎖之類）。第四，切換前用 dig 指令把現有 MX 與 TXT 的回應存一份下來，例如 dig MX yourdomain.com +short 與 dig TXT yourdomain.com +short，切換後再 dig 一次比對，值有漂移就是搬漏了。第五，切換前到網域註冊商確認網域是否啟用 DNSSEC（表現為一組 DS 記錄）：有的話先在註冊商端停用，否則 nameserver 一改，網域可能整個不可達，Cloudflare 官方設定文件對此有明文警告；等 Cloudflare 端的 zone 生效後，再照 Cloudflare 儀表板給的 DS 記錄回註冊商重新啟用 DNSSEC。第六，上線當天從外部信箱寄一封測試信進來、再回一封出去，兩個方向都通才算過關。郵件記錄的值都向你的郵件服務商拿，Google Workspace 與 Microsoft 365 都有完整的 DNS 對照表可以照抄。還有一個能降低切換風險的小動作：改 nameserver 之前，先在舊 DNS 服務把現有記錄的 TTL 調短（例如降到五分鐘），萬一切換後發現有問題需要改值，新值生效的速度會快得多；至於橘雲記錄在 Cloudflare 這邊的 TTL 固定是自動的 300 秒，不受這個影響。

不定時才會浮現的：快取、挑戰與個人化內容

先講讓人安心的事實：Cloudflare 的預設快取行為不包含 HTML 與 JSON，只按副檔名快取圖片、CSS、JS 這類靜態檔，而且回應帶 Set-Cookie 時不快取、Cache-Control 是 private 或 no-store 時也不快取。這代表什麼都不設定的情況下，WordPress 的頁面、登入流程、購物車都是直達源站的，預設行為是安全的。不過「帶 Set-Cookie 就不快取」的保護只存在於預設行為：一旦用規則讓回應變成可快取、又指定了明確的邊緣 TTL，Cloudflare 可能改寫 Set-Cookie 標頭後照樣快取，這正是登入與結帳路徑必須明確 bypass、不能只靠預設的原因。出事的案例幾乎都是同一種：站長或外掛為了追求速度，開了「快取所有內容」的規則，把 HTML 也快取了，然後某個訪客看到的頁面裡有別人的資料，或後台的 AJAX 請求回傳了被快取的舊回應。這類問題的麻煩在於它不會全站同時爆發：被快取到的是特定組合的頁面與特定時段的訪客，你收到第一封客訴之前，可能已經跑了好幾天。

正確做法不是不快取，而是把「不可快取清單」列清楚再開規則。WordPress 站至少包含：wp-admin 整個路徑、wp-login.php、購物車與結帳頁、會員帳號頁、所有表單提交端點、任何 /wp-json/ 開頭的動態端點。做法用 Cache Rules 的 bypass 動作，條件可以直接按路徑列，也能按 cookie 存在與否判斷（例如偵測到登入 cookie 就繞過快取），兩種寫法都夠用。規則上線後，檢查某個 URL 實際快取狀態的方法是看回應標頭的 cf-cache-status 欄位，HIT 代表邊緣快取、MISS 代表回源後存入、DYNAMIC 代表這個請求根本不走快取路徑，這是排查「為什麼被快取／為什麼沒被快取」的第一站。上線當天的驗收動作：用無痕視窗走一次登入、走一次結帳到最後一步（不真的付款）、送出一張測試表單，三個流程都正常，這個準備才算過。

挑戰的排除跟快取是兩件事，但清單是同一份：對這些路徑不要設定任何帶挑戰性質的動作，原因在後面的挑戰頁章節展開。表單的垃圾流量防護交給表單層的 Turnstile（同樣在後面的挑戰頁章節），挑表單外掛時可以把「有沒有內建 Turnstile 整合」列入挑選條件，省得自己刻前端。順帶一提速率限制：免費方案的一條規則搭配 10 秒計數週期，拿來保護登入頁抵禦暴力嘗試剛好夠用，是免費層裡投資報酬率很高的設定，各方案能用的欄位與週期差異官方有完整對照。

當場就會炸開的：加密模式與源站憑證

Cloudflare 的加密模式控制兩段連線裡的第二段（邊緣到源站）怎麼加密。Flexible 模式下這段走 HTTP 明文；如果你的源站本身設了「把 HTTP 全部 301 到 HTTPS」，就會形成迴圈：Cloudflare 用 HTTP 回源，源站叫它改走 HTTPS，Cloudflare 仍然用 HTTP 回源，訪客端看到的是 ERR_TOO_MANY_REDIRECTS，整站打不開。官方的 Flexible 模式文件對這個組合的建議寫得明白：源站強制 HTTPS 就不要用 Flexible，改用 Full 或 Full (strict)。

Full (strict) 與 Full 的差別在於前者會驗證源站憑證的有效性，來源可以是 Let's Encrypt 這類公開 CA，也可以是 Cloudflare 免費提供的 Origin CA 憑證。所以這個準備的前置條件是源站先裝好一張可信憑證，這也正是前面說「老舊主機先緩一緩」的原因。憑證類型怎麼挑、在 cPanel 與 Cloudflare 上怎麼裝，站上的SSL 憑證指南有完整流程。還要知道一個現況：新加入的網域現在預設走 Automatic SSL/TLS，Cloudflare 會派爬蟲探測你的源站（同時抓 HTTP 與 HTTPS 內容比對一致性）、從 1% 流量開始漸進切換到它判斷最安全的模式，出錯會自動回滾，而且只升級不降級。這個預設仍在漸進推出，若儀表板還沒出現 Automatic 選項、只看得到 Custom SSL/TLS 的手動設定，就直接手動選 Full (strict)；想自己掌控的人也隨時可以在儀表板改成手動指定，選擇相同。一個低風險的驗證順序是：改 nameserver 之前，先把主記錄從預設的橘雲手動切成灰雲（儀表板接入時橘雲是預設開啟的，不主動關掉就沒有灰雲狀態可用），直接用 https 連到源站確認憑證正常，再開橘雲，這樣憑證問題與代理問題不會疊在一起排查。

挑戰頁與轉換率：防護的摩擦成本

「請確認您是真人」那個整頁畫面，是 Cloudflare 防護裡對一般訪客最有感的存在。官方文件把挑戰分成三種強度。非互動式挑戰只靠瀏覽器執行一段 JavaScript 判斷，訪客不用做任何事，官方描述通常在五秒內完成。Managed Challenge 由 Cloudflare 依請求特徵動態決定出哪一種挑戰，多數真人會直接通過，官方把它列為大多數規則的建議選項。互動式挑戰最重，訪客一定要勾選或點擊才能過。從轉換率的角度，這三者的差別就是摩擦的大小：非互動式幾乎無感，互動式則是把「多一個步驟」直接加在你的表單或結帳流程前面，行動裝置上每一秒的等待都在折損完成率。

原則可以一句話講完：挑戰是用在規則上的手段，不是全站狀態。對特定路徑、特定特徵的可疑流量下 Managed Challenge，是低成本高效果的防護；把整站切到 Under Attack 模式讓每個訪客都過一次挑戰，是被攻擊當下的急救手段，常態開著等於對所有訪客課摩擦稅。有會員登入或結帳流程的網站還要注意兩件事。其一，挑戰頁的機制是回傳一個整頁 HTML 讓瀏覽器去解，遇到預期收到 JSON 的 AJAX 或 fetch 請求就會壞掉，官方對此的建議是改用 Turnstile 的 pre-clearance 機制，訪客在普通頁面上完成一次無感驗證後拿到 cf_clearance cookie，之後打到受保護端點的 API 呼叫不必再被挑戰頁打斷。其二，官方文件提醒挑戰與某些規則功能疊用時可能形成挑戰迴圈，訪客過了挑戰又被另一條規則攔下再出一次挑戰，所以多條規則的涵蓋範圍要互相排開，不要讓兩條規則對同一批流量同時下挑戰。

這就帶到 Turnstile 的取捨。Turnstile 是 Cloudflare 的驗證碼替代品，嵌入在你的表單裡，有三種模式：Managed（依風險決定要不要顯示勾選框）、非互動式（永不出現勾選框）與隱形（訪客完全看不到），並符合 WCAG 2.2 AAA 無障礙標準，這些能力免費與企業方案都一樣。計價對小站非常寬鬆：官方方案頁載明免費方案可以建最多 20 個 widget、每個 widget 可掛 10 個主機名稱、挑戰次數不限，官方對免費方案的適用對象描述就包含個人網站、中小企業與多數正式環境；企業方案的差異主要在企業功能：無限 widget、每個 widget 可掛 200 個主機名稱、any-hostname（widget 不受預先綁定主機名稱的限制）、analytics 留存從 7 天拉長到 30 天、Ephemeral IDs，以及品牌移除（Offlabel），一般網站的表單驗證用不到付費。實務上的分工是：邊緣層的挑戰頁負責攔截整體可疑流量，表單層的 Turnstile 負責精準保護提交端點。前者影響面大、後者摩擦局部，把驗證放在離轉換最近的那一層並保持無感，是兼顧防護與轉換率的常見組合。

SEO 的角度也值得一提。搜尋引擎爬蟲是被識別的已知流量，設定規則時把已驗證的搜尋機器人排除在挑戰之外是標準做法，不要讓 Googlebot 在你的站上排隊證明真人。WAF 誤擋對 SEO 的實際代價（403 與 429 讓搜尋引擎「讀不到就等於不存在」）在前面提過的 WAF 指南裡有完整分析，這裡只留一句結論：防護規則上線後，用 Google Search Console 的檢索統計報表確認爬蟲真的進得來，狀態碼分佈沒有異常。

掛上 Cloudflare 之後，AI 搜尋看得到你嗎

掛上 Cloudflare 之後，你手邊會多出一個控制面：官方的 AI Crawl Control 提供監看 AI 服務存取狀況的儀表板，也讓你對個別爬蟲設定允許或封鎖規則，AI Crawl Control 官方說明標示它適用於所有方案，掛上後自動生效、零設定起手。這整塊與導入決策的關係很單純：這些控制的前提是「你的網站在 Cloudflare 上」，掛上之後才談得上設定，而且不需要為了這層能力升級任何方案。爬蟲分類、各種封鎖強度為什麼可能連帶影響搜尋流量、六種網站形態各該怎麼選，站上的AI 爬蟲封鎖設定指南有完整拆解，這裡不重複。對還在評估階段的讀者，真正需要先想的是政策選擇（要不要讓 AI 服務拿你的內容、拿去做什麼），而不是費用。

誰先緩一緩，以及之後想退場怎麼辦

四種情況建議把導入往後排。源站無法安裝可信憑證的舊主機，卡在 Full (strict) 的前置條件，先換主機或先解決憑證。金流或第三方服務用固定 IP 白名單回呼、且對方無法改成 Cloudflare IP 範圍的，先跟服務商確認再動。DNS 記錄由他人管理（公司 IT 或代管商）的，先把記錄表的所有權與變更流程談清楚，否則出事時你連補記錄的權限都沒有。網域即將到期或正在轉移程序中的，nameserver 變更與轉移流程互相干擾，等塵埃落定再動。

退場比導入容易，這點反而少有人講。最輕的退法是把記錄改灰雲：流量立刻回到直連源站，快取與防護同時失效，DNS 仍由 Cloudflare 管，幾分鐘內生效，連 IP 都不用改。完整的退法是在網域商把 nameserver 改回原 DNS 服務，此時要記得 Cloudflare 上那張記錄表就是唯一副本，改回去之前務必把記錄完整補回舊服務，否則退場本身就會重演一次「搬家漏記錄」的事故。做法上跟導入是同一套檢查，只是方向相反：匯出、比對、dig 驗證、郵件測試，一個都不能少。

上線當天的順序

把前面所有準備收斂成一個可以照著執行的序列。挑流量低的時段開始。第一步，匯出舊記錄表存證，dig 存下現有 MX 與 TXT 回應。第二步，確認 Cloudflare 記錄表逐筆比對通過，郵件五類記錄都在。第三步，把主記錄與你想先驗證的記錄切成灰雲；這一步常被漏掉，因為儀表板接入網域時橘雲是預設打開的，不手動關掉，nameserver 一生效流量就立刻經過邊緣，後面「直連驗證」的步驟會整個跳過。第四步，在網域商改 nameserver 之前，先確認 DNSSEC 已在註冊商端停用（準備清單的第五項，漏了這步網域可能整個不可達），然後把 nameserver 改成 Cloudflare 指定的兩組，等待生效（通常數分鐘到數小時，官方給的上限是 24 小時，期間新舊記錄並存屬正常）；這段過渡期裡部分訪客還在用舊的 DNS 服務解析，所以切換前維持兩邊記錄一致是鐵則，先補齊 Cloudflare 這邊再改 nameserver，順序反過來就會出現「有人解析到舊服務上你剛改掉或缺掉的記錄」的空窗。第五步，生效後 dig 驗證 NS 已指向 Cloudflare，寄收各一封測試信。第六步，趁主記錄還在灰雲，用 https 直連源站確認憑證與網站正常。第七步，加密模式設為 Full (strict)，或確認 Automatic 模式的判斷結果符合預期。第八步，開橘雲，建議先從圖片子網域之類的次要記錄開始，主網域最後。第九步，部署快取規則與不可快取清單，檢查關鍵頁面的 cf-cache-status，無痕視窗走完登入、結帳、表單三個流程。第十步，視需要加速率限制保護登入頁；挑戰類規則最後再上，而且先從小範圍路徑開始。第十一步，一週後回頭看事件紀錄與快取命中率，用數據決定要不要調整規則或升級方案。

回到最初的問題。Cloudflare 該不該掛，對大多數動態站與內容站，答案是「該，而且免費方案就是個合理的起點」；對已經在現代平台上跑的純靜態站，答案是「你已經在類似的位置上，別為掛而掛」；對電商與金流站，答案是「可以，但照清單走完再切」。真正分出好壞的從來不是掛或不掛這個決定，而是切換那天你的記錄表完不完整、加密模式對不對、不可快取清單列得清不清楚。把這幾件事做對，Cloudflare 的免費層就是大多數網站能拿到的最便宜的一段基礎設施升級。