Cloudflare 新手教學：從 DNS、SSL 到 Workers，免費方案能做到哪

2025 年 11 月 18 日台灣時間晚上七點多，很多網站同時開不起來，回出一片 5xx 錯誤。那天 Cloudflare 自己的事後報告寫，這是他們「2019 年以來最嚴重的一次」當機。

一家公司出事，為什麼會讓這麼多網站一起倒？我 11 月 10 日打開 W3Techs 的統計頁，上面寫 Cloudflare 被 28.9% 的網站拿來當反向代理，在有用反向代理、而且 W3Techs 認得出是哪一家的網站裡占了 86.3%。換句話說，W3Techs 統計的網站裡，大約每三、四個就有一個前面站著 Cloudflare。

這篇是寫給第一次碰 Cloudflare 的人。我照四個段落走：先講它是什麼、免費能拿到什麼；再往下講接上網域之後實際發生了什麼，也就是 DNS、橘雲灰雲、SSL 和快取；接著是值得開的實用功能，包括防火牆、Tunnel、Workers；最後是總結和我的評價，包括它壞掉的時候會怎樣。

文中的價格和額度，我都是 2026 年 11 月 10 日對照 Cloudflare 官方文件和方案頁查的。Cloudflare 改版很勤，你讀到的時候如果數字不一樣，以官方頁面為準。

Cloudflare 到底是什麼？站在你網站前面的那一層

最簡單的理解方式：你的網站本來是訪客直接連到你的主機。接上 Cloudflare 之後，訪客先連到 Cloudflare 的機器，再由 Cloudflare 去跟你的主機要資料。這種架構叫反向代理，你的主機在 Cloudflare 的文件裡叫做「origin」（源站）。

站在中間有幾個直接的好處：

• 擋攻擊：惡意流量在 Cloudflare 那一層就被擋掉，到不了你的主機。
• 快取：圖片、CSS、JS 這類不常變的檔案可以存在 Cloudflare 的機房，訪客從附近的機房拿，不用每次跑回你的主機。
• 免費 HTTPS：憑證由 Cloudflare 發、自動續期。
• 藏住主機 IP：別人查你的網域，看到的是 Cloudflare 的 IP。

Cloudflare 的網路介紹頁寫，全球 95% 連得上網路的人口，離 Cloudflare 的機房在 50 毫秒以內，跟超過 13,000 家電信、雲端和企業網路互連。同一頁上的城市數量前後寫得不一致，我就不引了。

光看說明不太有感，所以我實際查了一次。我在台灣對 Cloudflare 自家的文件站 developers.cloudflare.com 做 DNS 查詢，拿到 5 個 104.16.x.189 開頭的 IP，TTL 都是 300 秒；再用 curl 看回應標頭，Server 寫的是 cloudflare，CF-RAY 的結尾一次是 TPE、一次是 KHH，代表這兩次分別是台北和高雄的機房回應我。任何接了 Cloudflare 的網站，在網址後面加 /cdn-cgi/trace，都能看到你這次連到哪個機房（colo= 那一行）。

圖：我 2026-11-10 從台灣查 developers.cloudflare.com 的結果（資料：Resolve-DnsName 與 curl 實際查詢）

除了網站代理，Cloudflare 這幾年把產品線拉得很長：Workers 讓你在它的機房跑程式，R2 是物件儲存，D1 是資料庫，Tunnel 讓家裡的服務不開 port 也能上網，另外還有網域註冊和信件轉寄。這些後面會一個一個講。

免費方案給你什麼、少了什麼？

網站代理這條線，Cloudflare 的方案頁列了四級：Free 免費；Pro 年繳每月 20 美元、月繳 25 美元；Business 年繳每月 200 美元、月繳 250 美元；最上面一級叫 Contract（企業合約），價格另議。

圖：Cloudflare 網站方案比較，價格查核於 2026-11-10（資料：Cloudflare 方案頁的 Network & CDN 分頁）

四個方案都有的東西，就是新手最需要的那幾樣：不限量的 DDoS 防護、Universal SSL 免費憑證、免費託管規則集，以及網站應用程式防火牆（WAF）。新手最怕的被攻擊、沒有 HTTPS 這兩件事，免費方案就處理掉了。

免費少了什麼？從方案頁看，差在這幾件事：

• 規則數量：Free 是 70 條規則加 1 萬條批次轉址，Pro 是 225 條。個人網站通常用不完。
• 機器人防護：Free 只處理「簡單的機器人」，Business 才擋得了進階的爬蟲和自動化工具。
• 圖片最佳化：無損圖片最佳化從 Pro 開始。
• SLA：Free 和 Pro 都沒有正常運作保證，Business 才有 100% SLA 和服務補償。
• 客服：Free 只有社群論壇和文件，Pro 才能開工單。

我自己的看法是，最後兩項才是真正的分界。功能上，個人部落格、作品集、小型專案用 Free 綽綽有餘；可是如果網站掛了會直接少賺錢，Free 方案出事的時候你沒有人可以找，只能等。這點後面講當機時會再提。

把網域交給 Cloudflare，實際上換掉了什麼？

這是新手最容易卡住的一步，因為它不是在 Cloudflare 按幾個按鈕就好，還要回到你買網域的地方改設定。

Cloudflare 的文件把這個做法叫「full setup」（完整設定），也就是把你網域的名稱伺服器（nameserver）換成 Cloudflare 的。文件寫得很清楚，這是最常見的做法，也是 Free 和 Pro 方案唯一能用的做法。

照官方文件，步驟是這樣：

1. 在 Cloudflare 加入網域：控制台選「Onboard a domain」，輸入主網域（例如 example.com，不要加 www），選方案。
2. 檢查 DNS 紀錄：Cloudflare 會掃描你現有的紀錄帶進來。這一步一定要逐筆看，特別是 www、子網域和信件相關的紀錄（MX、SPF、DKIM 這類 TXT）。少一筆，那個服務就會在切換後斷掉。
3. 到註冊商換名稱伺服器：在 Cloudflare 的網域總覽頁拿到兩個名稱伺服器，登入你買網域的地方，刪掉原本的名稱伺服器，換成 Cloudflare 給的這兩個。名稱伺服器是 Cloudflare 指派的，不能自己挑。
4. 等它生效：文件說註冊商更新最多可能要 24 小時。
5. 重新開 DNSSEC：網域生效之後，再從 Cloudflare 這邊把 DNSSEC 開回來。

第 3 步有一個坑，文件特別標出來：如果你的網域在註冊商那邊開著 DNSSEC，要先關掉再換名稱伺服器，不然網域可能整個解析不到。DNSSEC 是幫 DNS 回應加簽章的機制，上層登記的金鑰還是舊 DNS 服務商的，換了名稱伺服器之後簽章對不上，解析就會失敗。

那名稱伺服器到底是什麼？可以把它想成網域的「總機」。別人要找 example.com，會先問總機這個網域的 IP 是多少。換成 Cloudflare 的名稱伺服器，就等於把總機交給 Cloudflare，之後所有的 DNS 紀錄都在 Cloudflare 的控制台改，原本註冊商那邊的 DNS 設定就不再生效了。

如果網域是在 Cloudflare Registrar 買的，第 3、4 步可以跳過，因為它本來就用 Cloudflare 的名稱伺服器。

橘雲和灰雲：這個開關決定 Cloudflare 有沒有在幫你

進到 DNS 設定頁，每一筆紀錄旁邊都有一朵雲。我覺得這是整個 Cloudflare 最重要、也最常被誤解的開關。

• 橘雲（Proxied，代理）：流量經過 Cloudflare。別人查這個名稱，拿到的是 Cloudflare 的 anycast IP，看不到你主機的真實 IP。快取、防火牆、DDoS 防護、HTTPS 憑證，全部要在橘雲底下才會作用。
• 灰雲（DNS only，只做 DNS）：Cloudflare 只負責回答 DNS 查詢，回的是你主機的真實 IP，網站流量不經過 Cloudflare。這時 Cloudflare 什麼都幫不了你，也看不到網站流量的統計，只有 DNS 查詢的數據。

文件上有幾條規則值得記住：

• 只有 A、AAAA、CNAME 可以開橘雲，而且要是跑 HTTP 或 HTTPS 的服務。MX、TXT 這類紀錄永遠是灰雲。
• 用控制台加入網域時，預設就是開橘雲。
• 橘雲紀錄的 TTL 固定是 Auto，也就是 300 秒，不能改。我前面查到的 TTL 300，就是這個設定。
• 信件、網域驗證、非網頁服務，文件建議用灰雲。有些第三方服務的 CNAME（文件舉了 Mailchimp、Zoho、Amazon SES、Microsoft 的部分網址）如果開橘雲，會直接連不上。
• 網站用非標準的 port，或是跑 TCP、UDP 的服務（例如遊戲伺服器），一般的橘雲代理不支援，要用付費的 Spectrum。

接下來是我自己的推論，不是文件上的話：橘雲的「藏住主機 IP」很容易破功。最常見的情況是，你把 www 開了橘雲，但 mail.example.com 或某個測試用子網域是灰雲，而且指向同一台主機。別人只要查那筆灰雲紀錄，就拿到你的真實 IP，可以繞過 Cloudflare 直接打你的主機。文件也提到，網域剛加入、還在等待生效的那段時間（最多 24 小時），橘雲紀錄會暫時表現得像灰雲，回的是真實 IP。

所以如果你在意主機 IP 被看到，比較穩的做法是：網頁和信件放不同的主機，或是後面會講的 Tunnel，讓主機根本不需要公開的 IP。

SSL 模式為什麼會讓網站轉不停？

HTTPS 這件事，在 Cloudflare 底下其實是兩段連線：訪客到 Cloudflare 一段，Cloudflare 到你的主機一段。SSL/TLS 模式決定的，就是這兩段各自有沒有加密。

Cloudflare 現在的預設叫 Automatic SSL/TLS（自動）：它會掃描你的主機，自動挑主機支援的最安全模式。文件說它「不會把你的設定改成比較不安全的模式」，大約每個月掃一次。不過這個功能還在逐步推出，還沒輪到的網域，只會看到手動（Custom）的幾個選項：

• Off（關閉）：兩段都不加密，全部走 HTTP。
• Flexible（彈性）：訪客到 Cloudflare 是 HTTPS，Cloudflare 到主機是 HTTP，不加密。給根本裝不了憑證的主機用。
• Full（完整）：兩段都是 HTTPS，但 Cloudflare 不檢查主機憑證是不是有效的。自簽憑證也能過。
• Full (strict)（完整、嚴格）：兩段都是 HTTPS，而且會驗證主機的憑證，要是公開憑證機構發的，或 Cloudflare 自己的 Origin CA 憑證。
• Strict (SSL-Only Origin Pull)：不管訪客用 HTTP 還是 HTTPS，Cloudflare 一律用 HTTPS 連主機，並驗證憑證。

Cloudflare 的原文是：可以的話，「強烈建議」用 Full 或 Full (strict)。

新手最常遇到的問題是瀏覽器顯示「重新導向次數過多」（ERR_TOO_MANY_REDIRECTS）。Cloudflare 的疑難排解文件把原因寫得很直白：你開了 Flexible，Cloudflare 用 HTTP 去連主機；可是主機設定了「HTTP 一律轉到 HTTPS」，於是主機叫 Cloudflare 改用 HTTPS；Cloudflare 照 Flexible 的規則還是用 HTTP 去連，主機又叫它轉……就這樣無限循環。如果你的網站程式或主機面板有「強制 HTTPS」的選項而且開著，搭配 Flexible 就會中。

文件給的解法有兩個：拿掉主機上的 HTTPS 轉址，或是把模式改成 Full 以上（前提是主機上要有憑證）。反過來也會出事：開 Full 或 Full (strict)，主機卻把 HTTPS 轉回 HTTP，一樣會循環。

主機上的憑證怎麼來？如果你的主機只接受從 Cloudflare 過來的流量，最省事的是 Cloudflare Origin CA 憑證。四個方案都能免費申請，裝上去之後就能用 Full (strict)。但有兩件事要知道：

• 這種憑證只有 Cloudflare 認，瀏覽器不認。哪天你暫停 Cloudflare 或把紀錄改成灰雲，訪客會看到憑證不受信任的錯誤。
• 文件寫明 Cloudflare 不會寄到期通知，到期日要自己記。

最後是訪客那一段的憑證：Universal SSL。網域一生效，Cloudflare 就自動發一張免費憑證，涵蓋主網域（example.com）和第一層子網域（www.example.com、blog.example.com）。第二層以下，例如 api.dev.example.com，Universal SSL 不涵蓋，要另外用 Advanced Certificate Manager（方案頁寫每月 10 美元起）或 Total TLS 這類進階憑證功能。子網域命名的時候，盡量只用一層，可以省掉這個麻煩。

為什麼開了 Cloudflare，網站卻沒有變快？

很多人以為接上 Cloudflare 網站就會變快，結果測速沒什麼差別。原因通常是這條寫在文件裡的規則：Cloudflare 預設不快取 HTML 和 JSON。

它判斷要不要快取，看的是副檔名，不是檔案類型。預設會快取的是下面這張表裡的副檔名，圖片、影音、字型、CSS、JS、壓縮檔、文件檔都在裡面，另外它預設也會快取 robots.txt。

圖：Cloudflare 預設會快取的副檔名清單（來源：Default cache behavior）

也就是說，你的網頁本身（HTML）每次都還是回到你的主機拿。如果主機慢、或網頁是 PHP 動態產生的，接了 Cloudflare 也一樣慢；省下來的是圖片和靜態檔案的流量。

要確認某個檔案有沒有被快取，用 curl -I 網址 看回應裡的 CF-Cache-Status。照 Cloudflare 的文件：

• HIT：從 Cloudflare 的快取拿到。
• MISS：可以快取，但這次快取裡沒有，所以回主機拿。
• DYNAMIC：Cloudflare 判斷這個請求不能快取，「沒有查快取就直接到主機」。沒設規則的 HTML 通常就是這個。
• BYPASS：本來可以快取，但主機的回應不讓快取，例如帶了 Cache-Control: private、no-store 或 Set-Cookie。

有趣的是，我查 developers.cloudflare.com 的首頁，HTML 回的是 HIT。這代表這個站另外做了設定，不是預設行為；它是怎麼設的，從外面看不出來。

想讓 HTML 也被快取，就要用 Cache Rules（快取規則）。Free 方案可以建 10 條，Pro 25 條，Business 50 條，而且規則只對橘雲紀錄有效。要小心的是，會員頁、購物車、後台這種每個人看到的內容不一樣的頁面，千萬不能被快取，不然 A 的頁面可能被 B 看到。規則要寫成「只快取公開頁面、排除登入後的路徑」。

其他幾個數字也順便記一下：

• 預設快取時間：200、206、301 回應存 120 分鐘，302、303 存 20 分鐘，404、410 存 3 分鐘。
• 單一檔案能快取的上限：Free、Pro、Business 都是 512 MB，企業版預設 5 GB。
• 上傳大小上限：Free 和 Pro 是 100 MB，Business 200 MB。如果你的網站讓使用者上傳影片或大檔案，超過 100 MB 的請求會被 Cloudflare 擋下來，這個新手很常踩到。

免費版就有的防護：DDoS、WAF、Turnstile

這三樣是我覺得免費方案最值得的地方。

DDoS 防護。文件寫明「所有方案都有」，Free 也包含從網路層到應用層（L3 到 L7）的不限量 DDoS 防護，自動偵測、自動處理，不用你設定。Free 的限制是只能做 1 個規則覆寫，自適應防護也只有一部分。對個人網站來說，這樣的預設已經夠用。

WAF（網站應用程式防火牆）。WAF 會檢查請求內容，擋掉看起來像 SQL 注入、利用已知漏洞的攻擊。託管規則集的開放情況，文件上有一張表：

圖：WAF 託管規則集在各方案的開放情況（來源：WAF Managed Rules）

Free 拿得到的是「Cloudflare Free Managed Ruleset」，文件說它防的是「影響大、被大量利用的漏洞」。比較完整的 Cloudflare Managed Ruleset 和 OWASP 核心規則集，要 Pro 以上才有。

WAF 有用，但不要把它當成修漏洞的替代品。我之前寫 php2shell 漏洞的時候，Cloudflare 當天就推了對應的 WAF 規則，但他們自己也說那只是「STOPGAP only」的權宜之計，而且只保護有經過 Cloudflare 的流量。另一篇 PaperCut 被 AI 代理攻破的報告裡，也有 Cloudflare WAF 擋下攻擊的例子，但前提是那台主機前面真的有 Cloudflare。規則擋得住一次，漏洞還在，主機該更新還是要更新。

Turnstile。這是 Cloudflare 的驗證碼替代品，放在註冊、登入、留言表單上擋機器人。它有三種模式：Managed（推薦，依風險決定要不要顯示勾選框）、Non-interactive（訪客不用做任何操作）、Invisible（完全看不到）。重點是兩件事：

• 它不需要網站接 Cloudflare 代理，任何網站都能嵌入。
• 免費方案的驗證次數不限，每個帳號最多 20 個小工具，每個小工具最多綁 10 個網域。

如果你的網站還在用那種要人點紅綠燈的驗證碼，Turnstile 值得換。

家裡的服務不開 port 也能上網：Tunnel

假設你家裡有一台 NAS、一台跑著小專案的電腦，想讓外面連得到。傳統做法是在路由器開 port、設定轉發，等於在你家網路上開了一扇對外的門，而且不少家用網路根本沒有固定 IP。

Cloudflare Tunnel 反過來做：你在那台機器上裝一個叫 cloudflared 的小程式，它主動往外連到 Cloudflare，建立一條只有出站的加密連線。外面的訪客連到 Cloudflare，Cloudflare 再透過這條連線把請求送進來。文件說得很明白：你可以把防火牆設成只允許這些出站連線、擋掉所有進站流量。主機不需要公開 IP，路由器也不用開 port。

Tunnel 的文件標示「所有方案都可用」，支援 HTTP、HTTPS、TCP、SSH、RDP。前提是你要有一個已經接上 Cloudflare 的網域。官方文件的步驟大致是：

1. 控制台進到 Networking > Tunnels，按 Create Tunnel。
2. 選你的作業系統，照頁面上的指令安裝並啟動 cloudflared。Windows 是用系統管理員身分執行 cloudflared.exe service install <TUNNEL_TOKEN>，Linux 和 macOS 是 sudo cloudflared service install <TUNNEL_TOKEN>，也有 Docker 的版本。
3. 等狀態變成 Healthy。
4. 在這條 tunnel 裡選 Routes > Add route > Published application，填一個子網域（例如 nas.example.com），服務網址填本機的位置，例如 http://localhost:80。

SSH、RDP 這類不是網頁的服務，連線的那一端也要裝 cloudflared。

如果只是想臨時給朋友看一下本機正在開發的網站，還有更快的 Quick Tunnel：一行 cloudflared tunnel --url http://localhost:8080，就會拿到一個臨時的 trycloudflare.com 網址，不用帳號也不用網域。但文件列了它的限制：官方定位是測試和開發用、沒有正常運作保證、每次網址都會變、同時最多 200 個進行中的請求（超過回 429）、不支援 Server-Sent Events，而且預設是任何拿到網址的人都能連進來（可以加 --allowed-mail 參數改成要 email 驗證碼）。分享完記得關掉。

想寫程式的話：Workers、R2、D1 的免費額度

這一段是給會寫一點程式的人。Cloudflare 的開發者平台，免費額度給得相當大方，拿來做小專案、個人工具很適合。

Workers 是在 Cloudflare 機房跑的程式碼，寫 JavaScript 或 TypeScript，部署之後全球的機房都能執行。免費版和付費版的差別，定價頁的表格寫得最清楚：

圖：Workers 免費版與付費版的請求與 CPU 時間（來源：Workers Pricing）

免費版每天 10 萬次請求，每次最多 10 毫秒的 CPU 時間（等待資料庫、等待外部 API 的時間不算 CPU），超過每日額度時，設成 fail closed 的路由會回 1027 錯誤（設成 fail open 則會略過 Worker 直接送到源站）。付費版每個帳號每月至少 5 美元，含 1,000 萬次請求和 3,000 萬 CPU 毫秒，單次最長可以跑 5 分鐘（預設 30 秒），沒有流量費。記憶體兩邊都是每個執行環境 128 MB。

另一個常被問的問題：Pages 和 Workers 要選哪個？ Cloudflare 的 Pages 文件開頭現在直接問「你確定要用 Pages 嗎？」，並寫 Workers 是他們「建立應用程式的主要平台」，建議新專案從 Workers 開始。Pages 沒有被宣布停用，舊專案也還能跑，但如果你現在才開始，照官方建議直接用 Workers 的靜態檔案功能就好。Workers 的靜態檔案請求是免費而且不限次數的，免費版每個版本最多 2 萬個檔案、單檔 25 MiB。唯一的例外是定價頁的註腳：如果你開了 Workers 的快取功能，從快取送出的請求（包括靜態檔案）會按次計費。

需要存資料時，幾個常用服務的免費額度整理在這張表：

圖：開發者平台的免費與付費額度，查核於 2026-11-10（資料：Cloudflare 開發者文件的 R2、D1 定價頁與 Workers、Pages 限制頁）

幾個值得特別講的點：

• R2 下載不收流量費。R2 的文件寫明流出到網路「免費」，這點跟按流量計費的儲存服務很不一樣。免費額度每月 10 GB 儲存、100 萬次 A 類操作（上傳、列出）、1,000 萬次 B 類操作（讀取），之後每 GB 每月 0.015 美元。放圖片、備份、讓使用者下載的檔案很划算。要注意免費額度只適用於標準儲存，不適用於低頻存取類別。
• D1 的免費額度每天 UTC 00:00 重置，也就是台灣時間早上 8 點。超過上限的請求會回錯誤，要等重置或升級付費版，不會自動扣錢。
• KV 適合讀多寫少：免費版每天讀 10 萬次，寫只有 1,000 次。拿來存設定、快取很好，拿來當計數器很快就會用完。
• Workers 的日誌功能（Workers Logs）會在 2026 年 12 月 1 日改成另一套計價，有在用的人可以留意定價頁的公告。

我的建議是：先用免費版做，真的碰到每日上限再升級。每月 5 美元的付費版額度很大，個人專案很少需要更多。

順手可用的兩個：網域註冊與 Email Routing

Cloudflare Registrar。Cloudflare 賣網域的方式是「成本價」：文件寫它只收註冊局收的費用，「不加價、沒有意外費用」，續約也是照註冊局的牌價。WHOIS 資料預設隱藏，DNSSEC 免費。如果你遇過第一年便宜、續約突然變貴的註冊商，Cloudflare 照牌價續約的做法會單純很多。方案頁寫的起價是 7.85 美元，實際價格看網域後綴。

Email Routing。它能讓你用自己網域的信箱（例如 hi@example.com）收信，再轉寄到你原本的 Gmail 之類的信箱，也可以交給 Workers 處理。免費方案就能用。要分清楚的是，它主要負責收信和轉寄，寄信另外算：文件寫寄信功能（Email Sending）目前還是 beta，要寄給任意收件人需要 Workers 付費版。如果你要用自己的網域寄信，還是得搭配其他郵件服務。

它也會壞：兩次大當機告訴你的事

前面講了很多優點，總結之前要先把風險講清楚。Cloudflare 站在你網站前面，它出事，你的網站就跟著出事，不管你的主機有沒有問題。

圖：兩次大當機的經過（資料：Cloudflare 部落格的 2025-11-18 與 2026-02-20 事後報告）

2025 年 11 月 18 日那次影響最大。照 Cloudflare 的事後報告，一次資料庫權限的調整，讓機器人管理功能使用的「特徵檔」多出重複的資料，檔案大小翻倍，超過了代理程式設定的上限（上限是 200 個特徵，平常只用大約 60 個），代理程式就失敗了。報告開頭寫問題從 UTC 11:20 開始，14:30 核心流量大致恢復，17:06 所有系統恢復正常。從開始到全部恢復，我算起來大約 5 小時 46 分鐘。報告也強調這不是網路攻擊造成的。

這次有一個細節很值得新手記住：Turnstile 也壞了，而 Cloudflare 控制台的登入頁用的就是 Turnstile，所以多數人當下連控制台都登不進去。我從這段推論：真的出事的時候，就算你想把紀錄改成灰雲、讓流量繞過 Cloudflare，也可能根本做不到。

2026 年 2 月 20 日那次範圍小很多，受影響的是一部分使用 BYOIP（自帶 IP）服務的客戶。一個清理程式送出了空白的參數，伺服器把它解讀成「全部的 BYOIP 網段」，結果撤掉了 1,100 個網段，約占 BYOIP 網段的 25%。全程 6 小時 7 分鐘，最後大約 300 個網段是工程師手動恢復的。一般用免費方案的網站不會用到 BYOIP，所以沒有受影響。

這兩份報告我都覺得寫得很坦白，原因、時間點、哪裡判斷錯了都有交代，這是 Cloudflare 讓我比較放心的地方。但它也提醒一件事：W3Techs 那個 28.9% 的數字，同時也是風險有多集中的數字。

我的評價：誰該用、該怎麼用

先講結論：個人網站、部落格、作品集、小型專案，我會直接推薦用 Cloudflare 免費方案。DDoS 防護、免費憑證、WAF 基本規則、Tunnel、Turnstile、Workers 的額度，這些全部不用付錢就拿得到。

但有幾件事，我覺得決定之前要想清楚：

• 它不是「開了就變快」。HTML 預設不快取，主機慢的話還是慢。真的要加速，要自己寫快取規則，而且要小心不要把登入後的頁面快取起來。
• 它是一個集中的單點。Cloudflare 壞的時候，你的網站跟著壞，而且免費方案沒有 SLA、只有社群論壇可以問。如果網站停一小時就會直接少賺錢，至少要評估 Business 方案的 SLA，或是準備好不經過 Cloudflare 的備援方案。
• 換名稱伺服器是比較深的綁定。DNS 全部搬進 Cloudflare 之後，要離開就得把紀錄一筆一筆搬出去。Free 和 Pro 又只能用這種方式接，這點要有心理準備。
• 它擋得住流量，擋不住漏洞。WAF 只是其中一道防線，主機、外掛、框架該更新還是要更新。

我會因為什麼改變看法？如果 Cloudflare 的大當機變得頻繁，或是免費方案開始砍 DDoS、憑證這類核心功能，我就不會這麼輕易推薦。到 2026 年 11 月我查核的時候，這份免費清單仍然很長。

最後，如果你今天第一次設定，我建議照這個順序做：

1. 加入網域前，先在原本的 DNS 把所有紀錄截圖或匯出，特別是信件相關的。
2. 註冊商那邊如果開著 DNSSEC，先關掉，再換名稱伺服器。
3. 網站的 A、AAAA、CNAME 開橘雲；MX、TXT、驗證用的紀錄保持灰雲；指向網站主機的其他子網域也不要留灰雲，免得洩漏主機 IP。
4. SSL/TLS 模式選 Full (strict)，主機裝 Origin CA 憑證或一般的公開憑證；不要用 Flexible。
5. 用 curl -I 看 CF-Cache-Status，確認靜態檔案有 HIT，再決定要不要為 HTML 寫快取規則。
6. 有表單的話換上 Turnstile；家裡有服務要對外的話用 Tunnel，不要開 port。
7. 把 Cloudflare 的狀態頁（cloudflarestatus.com）加進書籤，出事時先確認是不是它的問題。

Cloudflare 的功能多到一篇寫不完，但新手第一天會碰到的東西，大概就是這些。剩下的，等你真的需要再去翻文件就好。