CDN 要不要用？原理、台灣連線實測與小型網站的成本效益

我第一次認真研究 CDN，是因為有人在留言區丟了一句「你的網站好慢」。當下我做的第一件事，是把 Cloudflare 打開、把 DNS 指過去，然後心滿意足地去睡覺。隔天早上重測，速度一模一樣。

那次之後我花了很長一段時間，才把一件事想清楚：CDN 不是一顆「網站加速」的按鈕，它是一組針對特定問題的工具，而那些問題不見得是你的問題。更麻煩的是，網路上關於 CDN 的討論，習慣把「延遲」「頻寬」「抗攻擊」三件完全不同的事混在一起講，講到最後變成一種信仰：裝了就是好。

這篇文章想做的事情很直接。我在 2026 年 8 月 6 日這天，用同一台電腦、同一條台灣家用線路，實際量了一輪連線數字；同時把 Cloudflare、Bunny、KeyCDN 的官方定價與官方技術文件逐頁翻過一次。然後我要誠實回答一個台灣中小型站長最想問、但最少人願意正面回答的問題：如果我的讀者幾乎都在台灣，CDN 是不是白花錢？

先說結論的形狀：答案不是「要」或「不要」，而是「你的主機放在哪裡」決定了 CDN 對你有沒有用；而「你怕不怕被打」決定了就算沒用你也可能還是想裝。中間所有的細節，都在下面。

CDN 到底在解什麼問題？延遲、頻寬、抗攻擊是三件事

把這三件事拆開，是整篇文章最重要的第一步。它們的成因不同、症狀不同、解法也不同，只是剛好都能被同一類產品沾到邊。混在一起講，就會出現「我裝了 CDN 為什麼還是慢」這種永遠得不到答案的問題。

問題一：延遲（latency）

延遲是「距離」造成的。訊號在光纖裡跑，速度大約是真空光速的三分之二，台北到美國西岸來回一趟，光是物理極限就要一百多毫秒，再加上路由器轉送、跨海纜線繞路，實際往返時間（RTT）會落在兩百毫秒上下——我等一下的實測數字會證明這件事。

延遲最惡毒的地方在於它會被「乘」上去。一次 HTTPS 連線至少要三個來回：TCP 三方握手一個來回、TLS 交握再一到兩個來回、最後才送出 HTTP 請求並等回應。也就是說 200 ms 的 RTT，不是讓你多等 200 ms，而是多等六百到八百毫秒。這正是 CDN 最有價值的地方：把「握手」這件事拉到離使用者最近的節點完成。

問題二：頻寬與主機負載

第二件事完全是另一回事：你的主機每個月能送多少資料出去、送出去要花多少錢、同時開幾個連線就會撐不住。CDN 在這裡的角色是「擋在前面吃掉重複的請求」，讓同一張圖只從你的主機拿一次、之後由邊緣節點發給所有人。

對共享主機用戶來說，這件事的價值常常被低估。共享主機真正的瓶頸往往不是頻寬，而是同時連線數與 PHP 執行緒；CDN 把靜態檔全部接走之後，主機只需要處理真正需要動態運算的請求。想更完整地評估主機端瓶頸，可以參考我整理過的共享主機、VPS 與託管型主機的取捨與續約陷阱，那篇把主機端的限制條件列得比較細。

問題三：抗攻擊

第三件事跟速度一點關係都沒有。DDoS 是有人用大量流量把你的主機打到回應不了，WAF 則是攔截針對應用層的攻擊字串。CDN 之所以能防，是因為流量在打到你之前必須先經過它的網路，而它的網路比你的主機大很多個數量級。

依 Cloudflare 官方 DDoS 文件（2026-08-06 查核），免費方案就包含「Standard, unmetered DDoS protection (layers 3-7)」，且第 3/4 層與第 7 層防護在 Free、Pro、Business、Enterprise 四種方案上都有。這是免費方案裡最實在的一項，跟你的讀者在哪裡完全無關。

三個問題的對照

問題	成因	典型症狀	CDN 有沒有用	不用 CDN 的替代解
延遲	使用者與主機的實體距離	TTFB 高，但檔案下載很快	主機在海外時非常有用；主機在台灣、讀者也在台灣時效果有限	把主機搬到讀者附近
頻寬／負載	重複請求全部打到主機	流量高峰時整站變慢或 5xx	有用，靜態檔命中率高時尤其明顯	主機端快取外掛、升級主機方案
抗攻擊	惡意流量、掃描、暴力破解	主機 CPU 爆掉、被主機商停權	有用，而且是免費方案就有的部分	主機端防火牆，但量體差太多

看懂這張表之後，「要不要用 CDN」就從一個是非題變成三個獨立的判斷題。你完全可能是「延遲用不到、頻寬用不到、但抗攻擊很需要」的那種站——這種情況在台灣的個人站與小型商家站非常常見。

CDN 的運作原理：跟著一個請求走一趟

在判斷值不值得之前，得先知道它到底做了什麼。我覺得最好的理解方式，是跟著一個請求從瀏覽器出發，一路走到你的主機再走回來。這一趟有四個關卡，任何一關卡住，CDN 的效果就會消失。

第一關：DNS 解析拿到的不是你主機的位址

你把網域交給 CDN 之後，別人查詢你的網域，拿到的是 CDN 的 IP，不是你主機的 IP。這件事有兩個立即的後果：一是你的主機真實位址被藏起來了，攻擊者不能直接繞過 CDN 打你（前提是你沒有在別的地方洩漏出去，例如郵件標頭或舊的子網域記錄）；二是所有流量都必須經過 CDN，它掛了你就掛了。

這也是為什麼我把「知道怎麼在十分鐘內把 DNS 改回去」列為上線前的必要條件。把網域託管搬到 CDN 業者這件事本身不難，難的是搬完之後那些沒被搬乾淨的記錄。

第二關：Anycast 決定你會連到哪一個節點

CDN 的同一個 IP 位址會在全球數百個地點同時對外宣告，網路會把你的封包送到「路由上最近」的那一個。注意「路由上最近」不等於「地理上最近」，這正是下一節實測會量給你看的現象。

先講結果：我用 curl --resolve 把案例站的網域強制指向它的兩個 IP，兩次都落在新加坡機房；而同一台電腦連 Cloudflare 自家網域則落在高雄。同一套 anycast 網路、同一條線路、不同的網域，落點就是不一樣。所以「這家 CDN 在台灣有節點」這句話，跟「你的站會被台灣節點服務」是兩件事，必須分開驗證。

第三關：節點用「快取鍵」去查有沒有現成的副本

這一關是整套機制的核心。依 Cloudflare 的 Cache Keys 官方文件（2026-08-06 查核），「A Cache Key is an identifier that Cloudflare uses for a file in our cache, and the Cache Key Template defines the identifier for a given HTTP request」，而預設的快取鍵包含完整網址（scheme、host、含查詢字串的 URI）、CORS 用的 Origin 標頭，以及數個方法覆寫與轉送相關的標頭。

「含查詢字串」這五個字，是很多人快取命中率低卻找不出原因的兇手。同一份文件說明，當查詢參數被納入快取鍵時，參數的值會被用進去，所以 file.jpg?foo=bar 與 file.jpg?foo=baz 會被當成兩個不同的檔案分別快取。實務上，各種廣告追蹤參數、社群分享參數、活動代碼都會產生無限多種變體，每一種都是一次全新的回源。

要改這件事需要自訂快取鍵，但官方的方案對照表寫明，Query String、Headers、Cookie、Host 與 User 這幾項快取鍵自訂功能只有 Enterprise 方案可用，Free、Pro、Business 都沒有。換句話說，中小型站沒辦法用設定解決這個問題，只能從源頭少產生無意義的參數。

第四關：沒命中就回源，並決定要不要把結果存起來

查不到副本時，節點會去你的主機拿一份（這動作叫「回源」），然後依據你的回應標頭決定要不要存。前面提過的 Cache-Control 與 Set-Cookie 就是在這一步發揮作用。

如果你的回應完全沒有給快取指示，Cloudflare 會套用預設的 Edge TTL。依官方預設快取行為文件（2026-08-06 查核）：狀態碼 200、206、301 為 120 分鐘；302、303 為 20 分鐘；404、410 為 3 分鐘。注意這只適用於「本來就在可快取副檔名清單裡」的資源，HTML 不在清單內，所以這組預設值對你的文章頁完全不會生效。

把四關串起來看

第一關決定風險，第二關決定延遲，第三關決定命中率，第四關決定回源量。一個「裝了 CDN 但沒有變快」的站，通常是第二關落點不理想、加上第三關幾乎全部落空，於是 CDN 退化成一個多繞了一圈的代理。這也是為什麼我堅持上線後一定要實測，而不是看儀表板上的綠燈就安心。

台灣連線實測：2026 年 8 月 6 日，同一台電腦量出來的數字

我不想引用別人的 benchmark，因為 CDN 的效果跟「你在哪裡上網」高度相關，別人的數字換到台灣家用線路上常常不成立。所以我直接量。

測量方法先講清楚，這樣你才知道這些數字能推論到什麼程度、不能推論到什麼程度。時間是 2026-08-06 上午 09:14 至 09:20（台北時間），設備是 macOS 上的 curl 8.7.1，強制走 IPv4，家用固網。每個目標連續取樣 3 到 5 次，下表列出的是最小值到最大值的區間，不是平均值。

基準數字：從台灣連到不同地方要多久

連線目標	性質	TCP 連線建立	TLS 交握完成	TTFB（首位元組）
www.cloudflare.com	Cloudflare 邊緣節點（回報 colo=KHH，高雄）	0.010–0.012 秒	0.028 秒	0.042–0.044 秒
cdnjs.cloudflare.com 上的 jquery.min.js	CDN 靜態檔（colo=KHH）	0.011–0.021 秒	0.029–0.038 秒	0.112–0.151 秒
cdn.jsdelivr.net 上的 jquery.min.js	CDN 靜態檔，回應標頭為 cf-cache-status: HIT	0.012–0.023 秒	0.031–0.042 秒	0.050–0.064 秒
fonts.gstatic.com 的字型檔	Google 自家邊緣網路	0.011–0.019 秒	0.026–0.033 秒	0.038–0.052 秒
www.ntu.edu.tw	台灣自有主機，未經 CDN	0.009–0.012 秒	0.039–0.092 秒	0.068–0.119 秒
ftp.gnu.org	美國主機，未經 CDN	0.211–0.221 秒	0.433–0.455 秒	0.661–0.686 秒
www.debian.org	歐美多台主機輪替，未經 CDN	0.159–0.302 秒	0.327–0.615 秒	0.639–1.239 秒
www.gov.br	巴西主機，未經 CDN	0.333–0.705 秒	0.673–1.042 秒	1.014–1.382 秒

這張表有三個結論，我一個一個拆。

結論一：延遲是被乘上去的，不是被加上去的

看 ftp.gnu.org 那一列：TCP 連線建立花了 0.211 秒，TLS 交握完成累計到 0.433 秒，首位元組回來累計 0.661 秒。三個數字幾乎是等差的 0.22 秒一階，這就是三個往返路徑（round trip）被一個一個疊上去的樣子。

換句話說，一條 220 ms 的線路不是讓你多等 220 ms，而是在「還沒開始傳任何內容」之前就已經燒掉 660 ms。Google 在 web.dev 的 TTFB 說明頁把 0.8 秒訂為良好門檻、1.8 秒以上為不良（2026-08-06 查核），也就是說光是把主機放在美國、又沒有任何邊緣快取，你的 TTFB 就已經站在及格線邊緣了，還沒開始算 PHP 執行與資料庫查詢的時間。

這也是為什麼 CDN 對「主機在海外」的站效果特別戲劇化：它把那三個來回從 220 ms 縮到 10 ms，等於直接省掉六百多毫秒。這個時間會原封不動地反映在 Largest Contentful Paint 上——web.dev 的 LCP 文件（2026-08-06 查核）說 LCP「includes any unload time from the previous page, connection set up time, redirect time, and other Time To First Byte (TTFB) delays」，良好門檻是 2.5 秒、不良是超過 4.0 秒。想把這三項指標一次盤過一遍，可以搭配我寫過的 Core Web Vitals 三項指標的實作順序一起看。

結論二：台灣的主機，本來就跟 CDN 邊緣一樣近

這是整篇文章最該被放大的一列數字：www.ntu.edu.tw 是一台放在台灣、沒有走任何 CDN 的自有主機，它的 TCP 連線建立時間是 0.009～0.012 秒，跟 Cloudflare 高雄機房的 0.010～0.012 秒完全一樣。

物理距離已經沒有壓縮空間了。如果你的主機在台灣、讀者也在台灣，那麼 CDN 能幫你省下的「距離成本」趨近於零。這時候還是慢，代表慢的原因在別的地方：PHP 執行時間、資料庫查詢、外掛太多、圖片太肥。這幾項我在把外掛精簡到 11 支的取捨清單與圖片壓縮與 WebP 轉檔的實作順序裡都拆過，比裝 CDN 有效得多。

結論三：掛了 CDN，不代表你會被分到最近的節點

這是我這次量到最意外、也最值得台灣站長知道的一件事。Cloudflare 的網路頁面（2026-08-06 查核）寫著「337 cities · 8 regions」，而且亞洲清單裡確實同時列了 Taipei 與 Kaohsiung City，官方也宣稱「95% of the world’s Internet-connected population is within 50 milliseconds of a Cloudflare data center」。

但同一台電腦、同一分鐘內，不同網域被分到的機房差很多。我用每個網域的 /cdn-cgi/trace 端點讀回它實際被服務的機房代碼，連續跑三輪，結果完全穩定：

網域	回報機房代碼	TCP 連線建立
www.cloudflare.com	KHH（高雄）	0.010–0.012 秒
developers.cloudflare.com	KHH（高雄）	0.012 秒
cdnjs.cloudflare.com	KHH（高雄）	0.011–0.014 秒
www.zerossl.com	TPE（台北）	0.010–0.013 秒
一個掛在 Cloudflare 免費方案上的 WordPress 站（案例站）	SIN（新加坡）	0.183–0.192 秒

同樣是 Cloudflare，同樣從台灣連過去，落點差了大約 175 毫秒。我把案例站的兩個 anycast IP 分別用 curl --resolve 強制指定再測一次，兩個 IP 都一樣落在 SIN，所以這不是 DNS 回不同 IP 造成的，而是這個 zone 在這條線路上就是被導到新加坡。

Cloudflare 沒有公布「哪個網域會被分到哪個機房」的判定規則，我也查不到任何官方文件說明免費方案與付費方案在節點選擇上有差別，所以我不會替它編一個理由。但它確實有一頁官方說明，直接回答了「為什麼沒被分到最近的機房」這個問題，值得一起讀。

Cloudflare 的支援文件〈Cloudflare traffic not being sent to the geographically closest data center〉（2026-08-06 查核）寫著：「Due to the way routing on Cloudflare’s Anycast network works, requests may be sent to data center locations that are not necessarily the closest geographically.」並且說明公司的優先序：「While we always strive to provide the best possible performance by serving traffic from the closest location, our top priority is reliability. In instances where performance and reliability are in conflict, our systems are designed to prioritize a stable connection over a local one.」

另一份〈Slow Website〉疑難排解文件（2026-08-06 查核）則把常見成因列成表，其中「Consistent routing to a distant region（持續被導到遠端區域）」對應的解釋是「ISP peering location or Cloudflare capacity management」，也就是你的電信業者在哪裡對等互連、以及 Cloudflare 當下的容量調度。我這次量到的正是「三輪都穩定落在 SIN」，符合這一列的描述。

所以官方立場可以總結成一句話：就近服務是目標，不是承諾；當穩定與速度衝突時，它選穩定。換句話說，台灣有兩個 Cloudflare 機房，不保證你的站會被服務到。而如果你的站被導到新加坡、主機又在台灣，那麼掛上 CDN 之後，讀者的連線路徑反而變成「台灣 → 新加坡 → 台灣」，延遲是被加上去的，不是被省下來的。

要補充的是，官方這兩段話解釋的是「anycast 路由與容量調度」這個一般機制，並沒有針對我這個案例做出診斷。我沒有辦法證明我量到的 SIN 就是出於上述哪一個原因，這仍然是我在單一線路上觀察到的現象，不是官方對這個 zone 的說明。

這件事你可以自己驗證，只要一行指令：把 你的網域.com/cdn-cgi/trace 用瀏覽器打開，看 colo= 那一行是什麼。這是我認為所有台灣站長在決定要不要用 CDN 之前，都應該先做的三十秒檢查。

這份實測數字的限制

我必須把話說完整：這是單一 ISP、單一地點、單一時間點的量測，不是統計上有代表性的 benchmark。不同電信業者的國際出口與對等互連狀況差很多，你在別條線路上量到的數字可能完全不同。我的建議是把上面的方法照抄一遍、量你自己的線路，而不是照抄我的數字。順帶一提，線路本身的穩定度也是變數，這部分我在遠距工作的斷網備援方案裡談過。

讀者幾乎都在台灣的站，CDN 是不是白花錢？

這一節是我覺得整篇文章最有價值、也最少人願意誠實回答的部分。先給結論，再給推導。

如果你的主機在台灣、讀者九成以上在台灣、每月流量不到幾十 GB，那麼 CDN 對「速度」這件事幾乎沒有幫助——但它對「抗攻擊」與「憑證管理」仍然有價值，而 Cloudflare 免費方案的價格是零，所以「白花錢」這個描述其實不成立，真正的成本是你要付出的複雜度。

依主機位置分成四種情況

你的情況	CDN 對延遲的幫助	對頻寬／負載的幫助	我的建議
主機在台灣，讀者在台灣	幾乎沒有，甚至可能變慢（見上面 SIN 的例子）	有，靜態檔可以卸載掉	可以用，但主要理由是安全與 SSL，不是速度；上線後務必回頭實測
主機在美國／歐洲，讀者在台灣	非常大，實測差距是六百毫秒等級	有	幾乎一定要用，或是考慮把主機搬回亞洲
主機在台灣，讀者遍布全球	對海外讀者幫助很大	有	要用，這是 CDN 最典型的適用情境
主機在新加坡／日本，讀者在台灣	有限，原本就只差幾十毫秒	有	可用可不用，先量再決定

那些「裝了 CDN 之後變快了」的體感，通常來自哪裡？

我看過很多人說裝完之後明顯變快，這些體感多半是真的，但功勞不一定屬於「就近服務」這件事。實際上常常是三個副作用在發揮效果，而這三件事你不用 CDN 也做得到。

第一，開了 Brotli 或 Gzip 壓縮。很多共享主機預設沒開，掛上 CDN 之後由邊緣統一壓縮，HTML 體積可能直接掉六成以上。第二，強制 HTTP/2 或 HTTP/3。舊主機還在跑 HTTP/1.1 的情況不少，換成多工的協定之後，同時要下載幾十個小檔的頁面會明顯順很多。第三，靜態檔被塞了長效的 Cache-Control，瀏覽器第二次進站根本不再發請求。

這三件事都可以在主機端自己做完。所以如果你的目的只是「讓網站快一點」，先把壓縮、HTTP/2、瀏覽器快取這三項做好，再回頭決定要不要 CDN，會省下很多除錯時間。

什麼情況我會直接說「不要裝」

有幾種情況我會建議先不要碰。第一種是站上有大量表單、會員登入或即時互動的功能——這類頁面本來就不能快取，CDN 只會多一層讓你除錯變困難的東西。第二種是你正在同時做網站搬家、換佈景主題或大改版；這種時候多一層快取，只會讓「改了怎麼沒生效」這個問題翻倍難查，換主題的連鎖影響我在換佈景主題的實際成本那篇整理過。第三種是你沒有能力在出事時把 DNS 切回去；CDN 是流量的單點，它掛了你的站就掛了。

快取命中率為什麼常常低到讓人懷疑人生

這是我認為最值得寫進這篇文章的技術段落。很多人以為裝上 CDN 就等於「內容被複製到全世界」，實際上絕大多數 WordPress 站的快取命中率低得驚人，而且原因是結構性的、不是設定錯誤。

官方明說：預設不快取 HTML

Cloudflare 的預設快取行為文件（2026-08-06 查核）第一句就寫得很清楚：「The Cloudflare CDN does not cache HTML or JSON by default」。也就是說，在你什麼都沒設定的情況下，CDN 幫你接走的只有靜態檔，你的每一篇文章、每一個分類頁，全部還是回你的主機拿。

官方列出的預設可快取副檔名清單是：7Z、AVI、AVIF、APK、BIN、BMP、BZ2、CLASS、CSS、CSV、DOC、DOCX、DMG、EJS、EOT、EPS、EXE、FLAC、GIF、GZ、ICO、ISO、JAR、JPG、JPEG、JS、MID、MIDI、MKV、MP3、MP4、OGG、OTF、PDF、PICT、PLS、PNG、PPT、PPTX、PS、RAR、SVG、SVGZ、SWF、TAR、TIF、TIFF、TTF、WEBM、WEBP、WOFF、WOFF2、XLS、XLSX、ZIP、ZST。注意這份清單裡沒有 HTML、沒有 PHP、沒有 JSON。對一個內容站來說，這代表最重要、最常被請求、也最吃主機資源的那一種資源，預設完全不在快取範圍內。

WordPress 自己也在踩煞車

就算你手動開了規則要求快取 HTML，還有第二道關卡。Cloudflare 的快取回應文件（2026-08-06 查核）在 BYPASS 段落列出來源回應「被視為不可快取」的常見原因，逐字是：「The origin web server returned a Cache-Control header set to no-cache, no-store, or private.」以及「The origin web server returned a Set-Cookie header.」

而 WordPress 核心的 wp_get_nocache_headers() 函式（developer.wordpress.org 官方參考頁，2026-08-06 查核）回傳的標頭長這樣：'Cache-Control' => 'no-cache, must-revalidate, max-age=0, no-store, private'，搭配 'Expires' => 'Wed, 11 Jan 1984 05:00:00 GMT'。

這裡有一個很多教學都寫錯的細節，值得你花三十秒看懂。上面那一串裡真正致命的是 no-store 與 private，不是 no-cache 或 max-age=0。依 Cloudflare 的 Cache-Control 文件（2026-08-06 查核），這些指令的行為取決於「Origin Cache Control」是否啟用，而官方寫明「Free, Pro, and Business customers have this option enabled by default and cannot disable it」——也就是說，看這篇文章的你幾乎一定是「啟用」那一欄。而在啟用的狀態下，官方指令對照表寫的是：max-age=0「Caches and always revalidates」、no-cache「Caches and always revalidates. Does not serve stale.」，只有 no-store 在啟用與停用兩種狀態下都是「Will not cache」。

換句話說，把「這串標頭同時命中四個拒絕快取條件」當成原因是不精確的：真正一槍斃命的是 no-store（以及 private），另外兩個在你的方案上其實是「照樣快取、但每次都回來源驗證」。結論不變（這種回應不會被留在邊緣），但你排查時要盯對指令，否則會把 max-age=0 當兇手、白改一輪設定。

還有 cookie 這條路。官方的條件表列出「Origin response has Set-Cookie header and default cache level is used.」在 Origin Cache Control 啟用時的行為是「Content is not cached.」，而留言表單會種 comment_author_ 開頭的 cookie、登入後會種 wordpress_logged_in_ 開頭的 cookie，只要回應帶了 Set-Cookie，這一次就不會進快取。

但要注意這個函式的作用範圍，不要以為每一次瀏覽都會送出這串標頭。WordPress 是在特定情境才呼叫它：後台頁面、登入流程、部分 REST 與 404 回應，以及已登入使用者的請求。一般訪客讀你的文章頁時，通常根本不會拿到 no-store——我在案例站上抓到的首頁回應就只有 cache-control: must-revalidate。所以對匿名讀者來說，HTML 沒被快取的主因是上一節那個「HTML 不在預設清單裡」的 DYNAMIC，而不是 WordPress 的 nocache 標頭；nocache 標頭是你「手動開了 HTML 快取之後」才會浮上來的第二道關卡。

先看懂 CF-Cache-Status，再談優化

診斷這件事其實只需要一個回應標頭。Cloudflare 的快取回應文件（2026-08-06 查核）對每個值都有明確定義，我把最常見的整理成表：

CF-Cache-Status 值	官方定義（摘要）	代表什麼／該做什麼
HIT	「The resource was found in Cloudflare’s cache.」	正常，這次請求沒有回你的主機
MISS	「The resource was not found in Cloudflare’s cache and was served from the origin web server.」	第一次被要求，之後應該會變 HIT；一直 MISS 才是問題
EXPIRED	快取裡有但過期了，改由來源主機提供	TTL 太短，可考慮拉長 Edge TTL
BYPASS	「Cloudflare considered the asset eligible for cache at request time … but the origin response was ultimately not cacheable.」	你的主機回了不可快取的標頭，去查 Cache-Control 與 Set-Cookie
DYNAMIC	「Cloudflare determined at request time that the asset is not eligible for cache, so the request went to the origin web server without a cache lookup.」	根本沒進快取查詢，通常就是 HTML；要靠 Cache Rules 才可能改變
REVALIDATED	來源以條件式請求確認未變更，由快取提供	正常且省頻寬
STALE	快取過期但連不到來源，仍先送舊的	你的主機可能出問題了

BYPASS 與 DYNAMIC 的差別，是所有除錯的分水嶺。DYNAMIC 表示 CDN 連查都沒查，這是「規則沒開」；BYPASS 表示 CDN 想快取但被你的主機回應擋掉，這是「標頭有問題」。前者要動 Cache Rules，後者要動 WordPress 或主機設定，兩者的解法完全不同。

一個實際案例：命中率 2%、73% 的請求是 DYNAMIC

我手上有一個實際運作的 WordPress 內容站，掛在 Cloudflare 免費方案上。2026-08-06 上午拉出它最近 24 小時、共 24,932 次請求的快取狀態分布，整體快取命中率大約 2%，而所有請求裡有 73% 被判為 DYNAMIC。換句話說，七成以上的請求，Cloudflare 甚至沒有去查快取，就直接轉給來源主機了。

完整的分布長這樣：DYNAMIC 18,261 次、NONE 4,569 次、MISS 908 次、REVALIDATED 575 次、HIT 493 次、EXPIRED 70 次。HIT 佔 493÷24,876 ≈ 2.0%，DYNAMIC 佔 18,261÷24,876 ≈ 73.4%。

我實際抓它的回應標頭來對照，首頁的結果是 cf-cache-status: DYNAMIC、cache-control: must-revalidate；同一個站上的一支 CSS 檔第一次抓到的是 cf-cache-status: MISS、cache-control: max-age=14400，連續再抓三次就變成 cf-cache-status: HIT，而且帶著遞增的 age 值。這完全符合官方文件描述的行為：靜態檔會被接住，HTML 不會。

所以「命中率只有 2%」這件事，本身不代表設定壞掉，它代表的是 WordPress 預設行為加上 CDN 預設行為的自然結果。真正該問的問題是：那 2% 幫你省下了什麼？如果靜態檔的絕對數量很大（圖片多、字型多），2% 的命中率仍然可能省下相當可觀的主機頻寬；如果你的站本來就很輕，那這 2% 幾乎沒有意義。

想提高命中率，有哪些正規做法

Cloudflare 的 Cache Rules 設定文件（2026-08-06 查核）提供兩個關鍵開關：「in the Cache eligibility section, select Bypass cache if you want matching requests to not be cacheable, or Eligible for cache if you want Cloudflare to attempt to cache them」，以及 Edge TTL 的「Use cache control-header if present, bypass cache if not」與「Ignore cache-control header and use this TTL」兩種模式。

也就是說，要讓 HTML 進快取，你必須做兩件事：把該路徑標為可快取，並且選擇「忽略 cache-control 標頭、改用我指定的 TTL」。但這一步非常危險，因為一旦忽略了 Cache-Control，登入中的使用者也可能拿到別人的快取頁面。正確做法是同時排除後台路徑、購物車、結帳頁，並針對登入 cookie 設定繞過規則。

另一條路是 Cloudflare 的 Automatic Platform Optimization（APO），官方產品頁的描述是「serves both static and dynamic WordPress content from Cloudflare’s network」，並宣稱「Our tests show notable improvements of 72% for Time to First Byte (TTFB) and 23% for First Contentful Paint (FCP)」。要注意這是廠商自家測試的數字，不是獨立第三方驗證，而且沒有公布樣本組成與測試條件。

APO 的收費方式要分兩種人講，這一點官方文件講得比產品頁清楚。依 Cloudflare 的 APO 官方文件（2026-08-06 查核），Pro 以上的方案本來就含 APO，不必另外付錢；只有 Free 方案要單獨購買。文件原文是「For users on the free plan, purchase APO before installing the WordPress plugin」與「For users on a Pro plan or higher, continue to Install and activate the Cloudflare WordPress plugin」，購買路徑則是後台的 Speed → Settings → Content Optimization，找到 Automatic Platform Optimization for WordPress 按 Purchase。

但金額我查不到。2026-08-06 查核時，Cloudflare 的產品頁、方案比較頁與 APO 開發者文件都沒有列出 Free 方案購買 APO 的價格，官方只給了「到後台按 Purchase 然後輸入付款資訊」這個流程。網路上流傳的數字我一律不引用，請以你自己後台訂閱頁面顯示的金額為準。這也代表一件實務上的事：如果你已經是 Pro 用戶，APO 是你已經付過錢、但很可能沒開的功能，值得回去看一眼。

順帶一提，如果你在 CDN 之外還裝了主機端的快取外掛，兩層快取疊在一起會讓「改了為什麼沒生效」變成一個很難查的問題。網站常見問題的檢查重點那篇有列出這類排查順序，可以拿來當清單用。

Cloudflare 免費方案實際包含什麼（2026-08-06 官方查核）

這一節我直接照 Cloudflare 官方方案頁（cloudflare.com/plans/）逐項抄，不做二手轉述。查核日 2026 年 8 月 6 日，所有價格為美元。

價格：務必分清楚月繳與年繳均攤

方案	官方標示價格（原文）	月繳實付	年繳均攤月價
Free	$0 /month	US$0	US$0
Pro	$20 /mo billed annually, or $25/mo billed monthly	US$25／月	US$20／月（年繳）
Business	$200 /mo billed annually, or $250/mo billed monthly	US$250／月	US$200／月（年繳）
Contract（企業約）	Custom、Billed annually	需洽詢	需洽詢

這是我一定要提醒的一點：Cloudflare 的定價頁把年繳均攤價放在前面、月繳價放在後面，只看第一個數字很容易少算兩成。Pro 方案如果你按月付，一年是 US$300 而不是 US$240。

免費方案有的、沒有的

依官方功能比較表逐列對照，免費方案包含：Fast, Easy-to-use DNS、Unmetered DDoS Protection、CDN、Universal SSL Certificate、Free Managed Ruleset、Web Application Firewall (WAF)、Single-Sign-On (SSO) Support、Role-based Account Control。

免費方案不包含（需要 Pro 以上）：Lossless Image Optimization、Accelerated Mobile Pages (AMP)。再往上還有幾項是 Business 以上才有：PCI DSS 4.0 Compliance、100% Uptime SLA 與服務點數；Network Prioritization 則只有 Contract 方案才有。

對台灣小型 WordPress 站來說，這張表的實際意義是：免費方案給的是「網路層的保護」與「基本邊緣快取」，付費方案賣的主要是影像處理、合規與服務等級保證。如果你買 Pro 的理由是「想要更快」，那你要確認的其實是影像最佳化這一項對你有多少價值——而這件事你在 WordPress 端用外掛也做得到。

一個很多人不知道的條款限制

Cloudflare 的應用服務專屬條款（Service-specific Terms — Application Services，2026-08-06 查核）在 CDN 段落寫著：

「Cloudflare reserves the right to disable or limit your access to or use of the CDN, or to limit your End Users’ access to certain of your resources through the CDN, if you use or are suspected of using the CDN without such Paid Services to serve video or a disproportionate percentage of pictures, audio files, or other large files.」

同一段的前文說明，非 Enterprise 客戶若要透過 CDN 提供影片與其他大檔，必須另外使用特定付費服務（原文舉例為 the Developer Platform、Images 與 Stream）。白話說：免費、Pro、Business 方案不是給你當免費影音空間用的。如果你打算把課程影片、大量高解析圖庫直接掛在 Cloudflare 後面，這一條你要先讀過。條款也寫明 Cloudflare 會「use reasonable efforts to provide you with notice of such action」，但那畢竟只是合理努力，不是保證。

圖片與靜態資源：CDN 之前該做的事

圖片通常佔一個內容站傳輸量的七成以上，所以很多人期待 CDN 一次解決。但免費方案並不包含影像最佳化，這件事要先講清楚。

Cloudflare 的 Polish（影像壓縮）官方文件（2026-08-06 查核）在方案可用性表格中，Free 欄位標示為「No」，只在 Pro、Business、Enterprise 上提供。也就是說免費方案的 CDN 會幫你「搬運」圖片，但不會幫你「壓縮」或「轉檔成 WebP」。

Cloudflare Images 的定價

如果要走 Cloudflare 自家的圖片服務，官方定價頁（2026-08-06 查核）列出的是：Images Transformed 為「First 5,000 unique transformations included + $0.50 / 1,000 unique transformations / month」；Images Stored 為「$5 / 100,000 images stored / month」；Images Delivered 為「$1 / 100,000 images delivered / month」。每月前 5,000 次不重複轉換是免費的，這對小型部落格其實很夠用。

但我還是建議先在自己端做完

把圖片壓好、轉成 WebP、寫上寬高屬性、加上延遲載入，這些事在 WordPress 端用外掛就能做完，而且做完之後不管你用不用 CDN 都有效。反過來說，如果你把一張 3MB 的原始照片丟給 CDN，它只會很有效率地把 3MB 送到全世界。實作順序我在網站圖片優化那篇寫得比較細，這裡不重複。

另外一個容易被忽略的細節是靜態檔的 Cache-Control。Cloudflare 的 Cache-Control 說明文件（2026-08-06 查核）指出，它會取「Browser Cache TTL in Cloudflare 或 max-age 標頭之中較高的那個值」，而且你可以用 s-maxage 指定邊緣快取時間、用 max-age 指定瀏覽器快取時間，兩者分開設。對靜態資源來說，把 s-maxage 拉長是提升命中率最直接的手段。

CDN 的常見副作用：那些沒人先告訴你的事

這一節是我踩過或看別人踩過的坑。CDN 是一層代理，只要是代理，它就會改變你的主機看到的世界。

副作用一：你的主機看到的 IP 全部變成 CDN 的

這是影響最廣、也最常被忽略的一項。Cloudflare 的官方疑難排解文件（2026-08-06 查核）寫得很直白：流量經過 Cloudflare 的反向代理之後，「your origin server returns a Cloudflare IP address」，也就是你的主機看到的來源 IP 是 Cloudflare 的，不是訪客的。

真正的訪客 IP 被放在額外的標頭裡。依 Cloudflare 的 HTTP 標頭參考文件（2026-08-06 查核）：CF-Connecting-IP「provides the client IP address connecting to Cloudflare to the origin web server」；X-Forwarded-For 在沒有前置代理時會與 CF-Connecting-IP 相同，有前置代理時則依序附加；True-Client-IP 則「is only available on an Enterprise plan」。

這件事會連鎖弄壞一整排功能：登入失敗次數限制會把所有人算成同一個人、留言防垃圾外掛的 IP 黑名單失效、統計報表裡的訪客地區全錯、主機端防火牆的封鎖規則等於白寫。Cloudflare 建議的修法是在來源主機端還原真實 IP：Apache 使用 mod_remoteip（文件也註明「Cloudflare no longer updates and supports mod_cloudflare, starting with versions Debian 9 and Ubuntu 18.04 LTS」），Nginx 則用內建的 ngx_http_realip_module 搭配 CF-Connecting-IP。這一項如果你在共享主機上、沒有權限改設定，就要靠外掛層去讀那個標頭。

順帶提醒，這也直接影響網站安全設定的有效性——登入防護、失敗次數限制那些規則如果吃到的是 CDN 的 IP，等於形同虛設。這部分可以對照WordPress 網站安全基本功那篇的檢查項目重看一次。

副作用二：地區偵測全部錯亂

承上，任何靠 IP 判斷國家的功能都會出錯：多語系自動切換、地區限定內容、貨幣自動切換、統計工具的國別報表。

Cloudflare 對此提供的官方解法是 IP Geolocation 功能，文件（2026-08-06 查核）寫著「IP geolocation adds the CF-IPCountry header to all requests to your origin server」，內容是「a two-character country code of the originating visitor’s country」，未知會回 XX、Tor 使用者會回 T1，而且 Free、Pro、Business、Enterprise 四種方案都支援。但這需要你的網站程式主動去讀這個標頭，不會自己生效。

如果你正在做多語系，這一項會直接影響自動導向的正確性；語系架構本身的取捨我在子網域、子目錄與翻譯外掛的比較那篇談過，兩件事要一起規劃。

副作用三：改了東西前台沒變

這是最常見、也最讓人抓狂的一種。你改了 CSS、換了圖、修了文案，重新整理卻什麼都沒變。原因可能是邊緣快取、可能是瀏覽器快取、也可能是主機端的快取外掛，三層都要清。

Cloudflare 的清除快取文件（2026-08-06 查核）列出五種方式：Purge by single-file（依網址）、Purge everything、Purge cache by cache-tags、Purge cache by hostname、Purge cache by prefix (URL)，而且這五種在 Free、Pro、Business、Enterprise 四個方案上都可用。

但速率限制差很多，這一點在改版當天特別關鍵。依同一份文件，hostname、tag、prefix 與 purge everything 這幾種操作的頻率上限，Free 是「5 requests per minute」、Pro 是「5 requests per second」、Business 是「10 requests per second」、Enterprise 是「50 requests per second」；單檔清除則是 Free 每秒 800 個網址、Pro 與 Business 每秒 1,500 個、Enterprise 每秒 3,000 個。單檔清除每次請求可帶的網址數上限，Free／Pro／Business 是 100 個、Enterprise 是 500 個；至於 hostname／tag／prefix 與全清那一組，四種方案一律都是 100 個。

換算成實務：免費方案一分鐘只能全站清五次。如果你在改版當天反覆微調、每改一次就清一次，很快就會撞到上限，然後開始懷疑是不是設定壞了。我的做法是改版期間先把要動的路徑設成繞過快取，改完再打開。

副作用四：HTTPS 模式設錯造成重導迴圈

Cloudflare 的 SSL/TLS 加密模式如果選了 Flexible，而你的主機同時又設定了「強制導向 HTTPS」，就會產生無限重導：Cloudflare 用 HTTP 連你的主機、主機把它導回 HTTPS、Cloudflare 再用 HTTP 連過去。症狀是瀏覽器直接顯示重導次數過多，整站完全打不開。

正確的設定是讓來源主機自己也有有效憑證，加密模式選 Full (strict)。憑證怎麼裝、裝完要收尾什麼，我在SSL 憑證安裝與 HTTPS 轉換的完整流程裡寫過完整順序，另外還有一篇比較短的SSL 快速設定筆記可以當對照。

副作用五：DNS 搬過去之後，郵件記錄跟著出事

把網域的 DNS 交給 Cloudflare 管理時，如果不小心把郵件相關的記錄也設成經過代理（橘色雲朵），郵件就會收不到。MX 記錄本身不能被代理，但 A 記錄如果被用來當郵件主機的位址、又被打開代理，寄信端解析到的會是 Cloudflare 的 IP。

原則很簡單：只有網站要走的 A／AAAA／CNAME 才開橘雲，其他一律灰雲。網域轉移與 DNS 相關的實務細節，可以參考網域名稱的選擇與轉移實務那篇。

副作用對照表

副作用	典型症狀	怎麼確認	怎麼修
訪客 IP 被換掉	登入限流失效、留言防垃圾失準、後台紀錄全是同幾個 IP	看主機存取紀錄的來源 IP 是否為 Cloudflare 網段	來源端還原真實 IP（mod_remoteip／ngx_http_realip_module）並讀 CF-Connecting-IP
地區偵測錯	自動語系或貨幣切錯、國別報表失真	檢查程式是用哪個變數判斷國家	改讀 CF-IPCountry 標頭
改版不生效	前台看到舊內容	比對 CF-Cache-Status 與 age 標頭	依序清邊緣、主機外掛、瀏覽器三層快取
重導迴圈	瀏覽器顯示重導次數過多	檢查加密模式與主機端強制 HTTPS 設定	來源裝憑證，模式改 Full (strict)
郵件收不到	網域信箱寄得出去收不到	檢查 DNS 記錄的代理狀態	郵件相關記錄一律關閉代理

小型網站的成本效益：把數字算給你看

談完技術，回到錢。CDN 的市場分成兩種計價邏輯：固定月費制與按量計費制，對小站來說這兩種的差別非常大。

按量計費的官方牌價（2026-08-06 查核）

先說 Bunny.net。官方定價頁列出的 Standard Network（119 個節點）價格為：Europe & North America 每 GB US$0.01、Asia & Oceania 每 GB US$0.03、South America 每 GB US$0.045、Middle East & Africa 每 GB US$0.06。另有 Volume Network（10 個節點）第一個 500 TB 每 GB US$0.005。最低消費是「$1 monthly minimum」，並提供 14 天免費試用且「No credit card required」。

再看 KeyCDN。官方定價頁的區域級距是：North America／Europe 前 10 TB 每 GB US$0.04、次 40 TB US$0.03、再 50 TB US$0.02、超過 100 TB US$0.01；Asia／Oceania 對應為 US$0.08、US$0.06、US$0.04、US$0.02；Africa／Latin America 為 US$0.10、US$0.08、US$0.06、US$0.04。另外「No request charges」代表 HTTP／HTTPS 請求數不另計費，前 3 個 Zone 免費、之後每個每月 US$1。

🔴 但 KeyCDN 這裡有一個很容易看漏、而且會讓小站的實際支出差十倍的地方：同一頁上有「最低用量」與「最低付款」兩個完全不同的數字，很多中文轉述只抄了前面那個。官方定價頁的說明區寫的是「Our minimum charge is $4 per month based on the combined total account traffic volume and other services used」，而同一頁下方的 Common pricing questions 裡則有兩問兩答：「Is there a minimum usage? Yes, the minimum usage is $4 per month.」以及「Is there a minimum payment? Yes, the minimum payment is $49.」

兩個數字都是真的，講的是不同的事：每月最低計費 US$4，是「你這個月至少會被扣掉多少」；最低付款 US$49，是「你一次至少要付進帳戶多少錢」。KeyCDN 採預付額度制，所以一個月只用 20 GB 的小站，帳面月費是 US$4，但你第一次入金就得先掏 US$49——大約等於先預繳一年。這一項如果沒看到，你會以為每月四美元就能開始用。

把數字套進一個小站

假設一個台灣的內容站，每月對外傳輸 20 GB（這對一個月幾萬瀏覽量、圖片有壓過的部落格是合理量級），而且流量幾乎全在亞太區：

方案	計價方式（官方，2026-08-06）	20 GB／月的估算	備註
Cloudflare Free	$0 /month，流量不另計費	US$0	不含影像最佳化；條款限制大檔與影片
Cloudflare Pro	$20/mo 年繳、或 $25/mo 月繳	US$240（年繳）／US$300（月繳）一年	加值主要在影像最佳化與規則數
Bunny Standard（Asia & Oceania）	US$0.03／GB，最低消費 US$1／月	20 × 0.03 = US$0.60，因低於最低消費故收 US$1	依官方最低消費條款推算
KeyCDN（Asia／Oceania）	US$0.08／GB，最低計費 US$4／月，最低付款 US$49	20 × 0.08 = US$1.60，因低於最低計費故每月收 US$4；但首次入金門檻是 US$49	請求數不另計費；US$49 是預付額度不是月費

這張表要注意的是：表中 20 GB 的用量是我設定的假設情境，不是任何官方數據；每 GB 單價與最低消費金額則全部來自上述官方定價頁。我把兩者分開標示，是因為前者可以隨你的實際流量替換，後者不行。

算完之後結論很清楚：對月流量幾十 GB 等級的小站，按量計費 CDN 的實付金額幾乎完全由「最低消費」與「入金門檻」決定，跟你用多少無關。而 Cloudflare 免費方案在這個量級是零元。所以純就價格論，小站沒有理由不從 Cloudflare Free 開始；付費 CDN 的價值要到流量量體大很多、或你需要更精細的邊緣控制時才會浮現。

如果你在做整體架站預算，這筆錢其實只是其中一個小項目，主機、網域、佈景主題與可能的外包費用才是大宗，我在網站架設費用全解析裡把各項目攤開比過。

別忘了「複雜度」也是成本

免費方案帳面上是零元，但它不是沒有代價。你多了一層要維護的設定、多了一個出問題時要排查的環節、多了一個必須記得續約與監控的服務。對一個人維護的小站來說，這個成本是真實的，而且在你半年沒動網站、突然要改東西的那天會加倍付出。

我的判準是：如果你連主機端的備份與更新策略都還沒建立起來，就先不要再疊一層 CDN。備份這件事我在三層備份策略那篇寫過，優先順序應該在 CDN 之前。

不用 CDN 的替代路線

如果算完發現 CDN 對你幫助有限，還有幾條路可以走，而且有些比 CDN 更根本。

第一條是把主機搬到讀者附近。這是最直接的解法，也是唯一能真正消除距離的方法。如果你的讀者九成在台灣，把主機從美國搬到台灣或鄰近地區，效果會遠大於在美國主機前面掛一層 CDN——因為 CDN 只能加速可快取的部分，動態請求該回源還是要回源，那段跨太平洋的路徑一步都省不掉。

第二條是把主機端的基本功做滿。開啟 Brotli 或 Gzip、升上 HTTP/2 或 HTTP/3、替靜態檔設定長效 Cache-Control、裝一支穩定的頁面快取外掛。這幾件事不需要多一層外部服務，而且做完之後，就算之後真的要加 CDN，效果也會更好。

第三條是改變網站的產出形態。如果你的內容更新頻率低、互動需求少，靜態網站生成器會讓「快取命中率」這個問題直接消失——因為整站本來就是靜態檔。這條路的取捨我在不用 WordPress 自架網站的幾種做法裡比較過，代價是編輯體驗與外掛生態，好處是速度與安全性。想從更前面一步重新評估工具的話，網站建置工具的五類比較那篇可以當起點。

怎麼自己量：五個可以照抄的檢查

這一節是我認為最實用的部分。所有判斷都應該建立在你自己線路上的數字，而不是別人的部落格文章。下面五個檢查全部可以在終端機用 curl 完成，不需要付費工具。

檢查一：確認你的站被哪個機房服務

把 你的網域/cdn-cgi/trace 用瀏覽器打開，或用終端機抓，看 colo= 那一行。這是 Cloudflare 用戶專屬的端點，Cloudflare 官方的〈Slow Website〉疑難排解文件（2026-08-06 查核）就是這樣教的，並寫明「The colo field shows the three-letter airport code of the serving data center」。對照到我們這一帶，TPE 是台北、KHH 是高雄、SIN 是新加坡、HKG 是香港、NRT 是東京成田。如果你的站在台灣、讀者在台灣，卻看到 SIN 或更遠的代碼，這件事就值得你重新評估。

檢查二：把一次連線拆成三段來看

用 curl -o /dev/null -w "conn=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n" 網址，一次跑三到五輪。三個數字之間的差距，就是一個往返路徑的成本。如果 conn 是 0.19 而 tls 是 0.38，那你的每一個來回都要付 0.19 秒；如果 conn 只有 0.01，距離就不是你的問題。

檢查三：看回應的快取狀態

用 curl -sI 網址 抓回應標頭，找 cf-cache-status 與 cache-control 兩行。首頁通常會是 DYNAMIC，一支 CSS 或 JS 應該要能變成 HIT。如果連圖片與 CSS 都是 MISS 或 BYPASS，那才是真的有設定問題。

檢查四：連續抓同一個檔案，看它會不會變 HIT

對同一支靜態檔連抓三次，觀察 cf-cache-status 有沒有從 MISS 變成 HIT、以及 age 這個標頭有沒有開始累加。我在案例站上實測的結果就是這樣：第一次 MISS，接著三次都是 HIT，而且 age 從 52 一路遞增。age 會遞增，代表這份副本真的留在邊緣，沒有被誰洗掉。

檢查五：直接繞過 CDN 打你的主機

用 curl --resolve 你的網域:443:你的主機真實IP 網址，就能在不改 DNS 的情況下，量出「沒有 CDN 時」的數字。這是唯一能誠實回答「CDN 到底幫我省了多少」的方法。把它跟正常請求的數字並排，差多少一目瞭然。要注意的是，如果你的主機設定了只接受 CDN 來源的連線，這一招會被擋掉，那本身也是一個好消息，代表你的來源保護有生效。

檢查	看什麼	什麼結果代表 CDN 對你有用
機房落點	trace 端點的 colo 代碼	回報的是台灣或鄰近機房
三段時間	conn／tls／ttfb 的階梯差	繞過 CDN 時階梯明顯變大
快取狀態	cf-cache-status	靜態檔穩定出現 HIT
重複抓取	age 標頭是否遞增	副本確實留在邊緣
繞過 CDN	–resolve 直連主機的 TTFB	直連明顯比走 CDN 慢

我自己的決策流程：六個問題

把上面所有東西壓縮成一份可以照著跑的清單。依序回答，答案自然會浮出來。

第一，我的主機實體位置在哪裡？如果在台灣而讀者也在台灣，CDN 對速度的幫助接近零，往下看第三題。如果在美國或歐洲，你有很強的理由裝，或是更該考慮把主機搬到亞洲。

第二，我的讀者實際分布在哪裡？去看流量分析工具的國別報表，不要憑感覺。如果海外讀者佔比低於一成，那你是在為一成的人付出全站的複雜度。怎麼看這份報表，可以參考GA4 的安裝與報表判讀教學。

第三，我有沒有被攻擊或被掃描的困擾？如果你的主機商曾經因為異常流量寄信警告、或後台登入失敗紀錄一天上千筆，那麼免費方案的無流量上限 DDoS 防護與 WAF 本身就值得裝，跟速度無關。

第四，我的站有多少比例是真正的靜態資源？圖片、字型、CSS、JS 佔比高的站，就算 HTML 完全不快取，CDN 仍然能卸掉相當可觀的主機負載；反之，一個以動態查詢為主的站就享受不到。

第五，我有沒有能力在出事時把 DNS 切回去？這是風險題。CDN 是流量的單點，你必須知道怎麼在十分鐘內把 A 記錄改回原主機 IP。做不到就先不要上。

第六，上線之後我要用什麼指標驗收？不要用體感。用 curl 量 TTFB、用 /cdn-cgi/trace 確認落點機房、用 CF-Cache-Status 看命中狀況，並且在改動前後各量一次。搜尋端的變化則可以透過 Search Console 的核心網頁指標報表觀察，速度與排名的關聯我也在SEO 實測心得那篇談過。

常見問題

Q1：我的網站在台灣主機、讀者也都在台灣，裝 Cloudflare 會不會反而變慢？

有可能。我在 2026-08-06 的實測中，一個掛在 Cloudflare 免費方案上的網站被分配到新加坡機房，TCP 連線建立時間是 0.183～0.192 秒，而同一時間 Cloudflare 自家網域落在高雄機房只要 0.010～0.012 秒。如果主機在台灣、讀者在台灣，而 CDN 節點在新加坡，路徑就變成繞了一圈。驗證方式是打開 你的網域/cdn-cgi/trace，看 colo= 回報的是哪個機房代碼，再實際量 TTFB 比較上線前後。

Q2：Cloudflare 免費方案真的完全免費嗎？流量會不會超過就開始收錢？

依 Cloudflare 官方方案頁（2026-08-06 查核），Free 方案標示為「$0 /month」，方案比較表中的 CDN 與 Unmetered DDoS Protection 都列為免費方案包含。官方沒有在該頁列出流量上限。但服務條款另有限制：非 Enterprise 客戶若未加購特定付費服務，不得用 CDN 提供影片或不成比例的圖片、音訊等大檔，Cloudflare 保留停用或限制的權利。所以「免費」的前提是你的用途是一般網站，不是拿來當影音空間。

Q3：為什麼我開了 Cloudflare，快取命中率只有個位數？是不是設定錯了？

多半沒設定錯。主因是 Cloudflare 官方文件明確寫著「The Cloudflare CDN does not cache HTML or JSON by default」——HTML 不在預設可快取的副檔名清單裡，所以你的文章頁一律是 DYNAMIC，連快取都不會被查詢。要提高命中率必須主動建立 Cache Rules 讓 HTML 可快取並指定 TTL，而且要同時排除後台、購物車與登入狀態，否則會有把登入頁面快取給別人看到的風險。開了之後才會撞到第二道關卡：WordPress 核心的 wp_get_nocache_headers() 會在後台、登入流程、404 與已登入使用者的請求上送出 no-cache, must-revalidate, max-age=0, no-store, private，其中 no-store 與 private 是 Cloudflare 明文不快取的指令。

Q4：BYPASS 跟 DYNAMIC 有什麼差別？我該先查哪一個？

依 Cloudflare 快取回應文件的定義，DYNAMIC 是「Cloudflare determined at request time that the asset is not eligible for cache, so the request went to the origin web server without a cache lookup」，也就是規則層就判定不可快取、連查都沒查；BYPASS 則是「considered the asset eligible for cache … but the origin response was ultimately not cacheable」，代表 CDN 想快取但被你的主機回應擋掉。看到 DYNAMIC 去查 Cache Rules，看到 BYPASS 去查來源主機的 Cache-Control 與 Set-Cookie。

Q5：改版之後前台一直是舊的，除了清快取還要注意什麼？

要注意清除頻率的上限。依 Cloudflare 官方清除快取文件（2026-08-06 查核），hostname、tag、prefix 與 purge everything 這幾類操作，Free 方案的上限是每分鐘 5 次，Pro 是每秒 5 次，Business 是每秒 10 次。免費方案在改版當天很容易撞到這個上限。另外別忘了主機端如果還裝了快取外掛，那是另一層，還有瀏覽器本身的快取是第三層，三層都清了才算數。

Q6：不用 CDN 的話，有哪些替代做法可以先試？

先確認主機端是否開了 Brotli 或 Gzip 壓縮、是否支援 HTTP/2 或 HTTP/3、靜態檔有沒有設定長效的 Cache-Control。這三項不需要任何 CDN 就能做，而且效果通常比想像中大。接著才是圖片壓縮與外掛精簡。如果做完這些還是慢，而且你的主機在海外，那時候再考慮 CDN 或搬家會比較有依據。

資料來源

• Cloudflare — Plans & Pricing：本文所有 Cloudflare 方案價格（Free $0/month；Pro $20/mo billed annually 或 $25/mo billed monthly；Business $200/mo billed annually 或 $250/mo billed monthly）與免費方案功能清單的出處，查核日 2026-08-06。
• Cloudflare — Our Network：證明 Cloudflare 網路規模為「337 cities · 8 regions」、宣稱 95% 網路人口在 50 毫秒內，且亞洲清單同時列有 Taipei 與 Kaohsiung City。
• Cloudflare Docs — Default Cache Behavior：證明「The Cloudflare CDN does not cache HTML or JSON by default」、預設可快取副檔名清單、以及 Cache-Control 為 private／no-store／no-cache／max-age=0 或存在 Set-Cookie 時不快取。
• Cloudflare Docs — Cache Responses（CF-Cache-Status）：本文 CF-Cache-Status 對照表中 HIT／MISS／EXPIRED／BYPASS／DYNAMIC／REVALIDATED／STALE 各值定義的出處。
• Cloudflare Docs — Cache-Control：證明 Cloudflare 取 Browser Cache TTL 與 max-age 之中較高者，以及 s-maxage 與 max-age 可分別控制邊緣與瀏覽器快取。
• Cloudflare Docs — Cache Rules Settings：證明 Cache eligibility 的 Bypass cache／Eligible for cache 選項，以及 Edge TTL 的兩種模式，是讓 HTML 進快取的官方機制。
• Cloudflare Docs — Cache Keys：證明預設快取鍵包含含查詢字串的完整網址、不同查詢參數值會產生不同快取項目，且自訂快取鍵僅 Enterprise 方案可用。
• Cloudflare Docs — Purge Cache：證明五種清除方式各方案皆可用，以及 Free 每分鐘 5 次、Pro 每秒 5 次、Business 每秒 10 次的速率限制。
• Cloudflare Docs — HTTP Headers：證明 CF-Connecting-IP 帶入真實訪客 IP、CF-IPCountry 為兩碼國家代碼、True-Client-IP 僅 Enterprise 方案可用。
• Cloudflare Docs — Restoring Original Visitor IPs：證明來源主機預設看到的是 Cloudflare 的 IP，以及 Apache 應改用 mod_remoteip、Nginx 用 ngx_http_realip_module。
• Cloudflare Docs — IP Geolocation：證明 CF-IPCountry 標頭的行為與四種方案皆支援。
• Cloudflare Docs — DDoS Protection：證明 Free 方案即含「Standard, unmetered DDoS protection (layers 3-7)」且 L3/4 與 L7 防護四方案皆有。
• Cloudflare Docs — Polish：證明影像最佳化僅 Pro、Business、Enterprise 可用，Free 方案標示為 No。
• Cloudflare Docs — Images Pricing：本文 Cloudflare Images 每月前 5,000 次免費轉換、$0.50／1,000 次轉換、$5／10 萬張儲存、$1／10 萬張傳送等數字的出處。
• Cloudflare — Service-specific Terms (Application Services)：本文逐字引用的 CDN 使用限制條款出處，說明非 Enterprise 客戶未加購指定付費服務時不得用 CDN 提供影片或不成比例的大檔。
• Cloudflare — Automatic Platform Optimization：本文引用的 APO 官方說明與其自家測試宣稱（TTFB 改善 72%、FCP 改善 23%）的出處；同一頁未列出 APO 的獨立訂閱價格。
• Cloudflare Docs — Activate the Cloudflare WordPress plugin（APO）：證明 Pro 以上方案已含 APO、Free 方案需另行購買，以及後台 Speed → Settings → Content Optimization 的購買路徑；該頁同樣未列出價格。
• Cloudflare Docs — Cloudflare traffic not being sent to the geographically closest data center：本文引用的官方立場出處，說明 anycast 請求可能不會落在地理上最近的機房，且穩定性優先於就近服務。
• Cloudflare Docs — Slow Website：證明 /cdn-cgi/trace 的 colo 欄位為機房的三碼機場代碼，以及「持續被導到遠端區域」對應的官方成因為 ISP 對等互連位置或 Cloudflare 容量調度。
• Cloudflare Docs — Cache-Control（Origin Cache Control）：證明 Free、Pro、Business 方案的 Origin Cache Control 預設啟用且無法關閉，以及該狀態下 max-age=0 與 no-cache 為「快取並每次驗證」、僅 no-store 一律不快取。
• Bunny.net — Pricing：證明 Standard Network 的 Asia & Oceania 每 GB US$0.03、$1 monthly minimum 與 14 天免信用卡試用。
• KeyCDN — Pricing：證明 Asia／Oceania 前 10 TB 每 GB US$0.08 起的級距、「Our minimum charge is $4 per month」與 FAQ 中「the minimum usage is $4 per month」「the minimum payment is $49」兩個並存的數字，以及請求數不另計費、前 3 個 Zone 免費。
• WordPress Developer Resources — wp_get_nocache_headers()：證明 WordPress 核心預設送出的 Cache-Control 字串為「no-cache, must-revalidate, max-age=0, no-store, private」。
• web.dev — Time to First Byte (TTFB)：證明良好 TTFB 為 0.8 秒以下、不良為超過 1.8 秒，以及 TTFB 包含重新導向、DNS、連線與 TLS 協商等組成。
• web.dev — Largest Contentful Paint (LCP)：證明良好 LCP 為 2.5 秒以下、不良為超過 4.0 秒，且 LCP 包含連線建立與 TTFB 延遲。

本文列出的所有價格與方案內容，均為 2026 年 8 月 6 日於各服務官方頁面查核的結果，幣別為美元且未含稅。CDN 業者的定價與方案內容可能隨時調整，實際費用請以你結帳當下官方頁面顯示為準。文中的連線數字為單一台灣家用線路在 2026-08-06 上午的實測結果，僅代表該時間該線路的狀況，不構成對其他網路環境的效能保證。