為什麼使用 CDN 後伺服器反而變慢？

發布日期：2026-08-25

Cache misconfigurations can slow CDN performance

你原本期待內容傳遞網路能提升速度，結果網站卻感覺更慢了。是的，CDN 確實有可能讓你的伺服器變慢。其原因通常可以追溯到 CDN 與來源站伺服器的互動方式、你的設定，以及你的網路環境。那麼，為什麼會出現「為什麼使用 CDN 後伺服器反而變慢？」這種情況呢？

有多個因素會導致這種令人沮喪的結果。伺服器硬體資源不足可能會形成請求瓶頸；快取設定可能導致頻繁未命中；第三方資源可能完全繞過 CDN；網路問題，例如邊緣節點覆蓋不足或 DNS 延遲，也會損害效能。每一個因素都會直接影響你網站的整體表現。

理解這些要素，有助於你修復問題、正確調校 CDN，並恢復快速的網頁載入速度。

為什麼使用 CDN 後伺服器反而變慢？

常見原因概覽

你可能會疑惑，為什麼使用 CDN 後伺服器反而變慢？答案在於多個相互作用的因素共同抵消了你原本預期的加速效果。CDN 並不會自動解決所有效能問題。事實上，它還可能引入新的瓶頸，或無法處理原本已經存在的問題。理解這些原因，能夠幫助你診斷並修復變慢的根源。

下表總結了幾類主要的技術因素，即使大多數流量已經由 CDN 處理，它們仍然可能拖慢你的來源站伺服器。

技術因素	它如何拖慢來源站伺服器
硬體資源不足	即使 CDN 已經減少了一部分流量，來源站伺服器的 CPU 和記憶體仍可能不堪負荷，從而導致負載飆升和回應變慢。
網路問題	來源站伺服器所使用的 ISP 若存在問題（如頻寬瓶頸、路由異常或服務中斷），就會造成 CDN 無法繞過的延遲。
第三方資源	CDN 只能加速來自來源站伺服器的內容。第三方指令碼、廣告和媒體資源會直接從外部主機載入，增加 CDN 無法消除的延遲，從而削弱整體效能提升。
快取設定不當	如果缺少 cache-control 標頭、快取時間過短，或被相互衝突的 Pragma 標頭覆蓋，CDN 就會頻繁快取未命中，迫使來源站處理本應由邊緣節點直接回傳的請求。

除了這些技術因素，還有一些更廣泛的問題也會導致該現象。這些原因往往源於你在基礎架構和服務商選擇上的決策：

DNS 伺服器品質：較便宜的 DNS 服務通常可靠性較差，因此更推薦使用 Cloudflare 或 NS1 這類高品質方案。
伺服器租用問題：頻寬不足、設備等級較低以及安全性較差，都會拖慢伺服器速度。
網站最佳化：隨著應用持續演進，持續進行程式碼最佳化是必要的。
地理限制：某些 CDN 在特定地區（如中國）表現不佳，導致當地使用者存取變慢。
依賴單一 CDN：只依賴一家服務商會帶來效能風險，因為即使像 Cloudflare 這樣的頂級 CDN 也曾發生重大故障。

這些原因大致可以歸為四大類，我們將在下文詳細展開：伺服器硬體與設定、快取設定陷阱、第三方資源，以及網路或 CDN 服務商問題。每一類都包含可能削弱 CDN 優勢的具體錯誤設定或疏漏。透過逐一排查這些方面，你可以辨識究竟是哪類因素正在影響你的網站，並採取相應措施恢復快速載入。

伺服器硬體與設定

來源站伺服器瓶頸

你的來源站伺服器仍然需要處理所有 CDN 無法從快取中直接回應的請求。接入 CDN 後，你可能會以為硬體負載會大幅下降。但實際上，流量減少往往只是暴露了另一個問題：你的伺服器 CPU 和記憶體原本就已經接近極限。CDN 吸收了那些最容易處理的請求，而剩下的請求——動態頁面、API 呼叫、未快取資源——通常恰恰是最消耗資源的部分。這些請求需要資料庫查詢、工作階段查找和應用邏輯處理。於是，雖然總流量下降了，但你的硬體處理的「重負載請求」占比反而更高，從而導致回應時間飆升。

你還應檢查伺服器的頻寬分配情況。許多伺服器租用方案都包含每月流量上限。當 CDN 為了填充邊緣快取而從來源站拉取內容時，會消耗這部分頻寬。在初始預熱快取期間，或快取被清除之後，CDN 可能會反覆抓取大檔案。這種行為會占滿你的連線頻寬，導致所有到達來源站的請求都變慢。監控你的頻寬使用情況；如果經常出現頻寬打滿的現象，就應考慮升級方案。

軟體缺陷與設定錯誤

很多效能變慢的問題其實與 CDN 無關，而是軟體層面本身存在問題。比如，過時的 Web 伺服器軟體可能缺乏對現代流量模式的最佳化。使用預設設定的舊版 Apache 設定，在並發連線下往往表現不佳。同樣，資料庫連線池設定錯誤也可能耗盡可用連線，迫使請求排隊等待。啟用 CDN 後，這類問題會更加明顯，因為來源站此時處理的請求類型已經發生了變化。

啟用 CDN 後，你應該重新檢視伺服器設定。檢查 Web 伺服器是否支援 HTTP/2，因為它可以透過多工降低延遲。確認應用框架中的快取層是否正常運作。查看錯誤日誌，尋找重複性故障或逾時資訊。有時，一個簡單的調整，比如提高 PHP 記憶體限制或修改工作程序數量，就能解決效能下降問題。這類軟體層面的最佳化，往往比你單純修改 CDN 設定帶來的收益更明顯。

快取設定陷阱

預設僅快取靜態資源

許多 CDN 服務，包括 Cloudflare，預設策略都比較保守。它們會自動快取圖片、CSS 和 JavaScript 檔案等靜態資源，但預設不會快取 HTML 頁面。這意味著每位訪客對主網頁的請求仍然會回到你的來源站伺服器。CDN 只處理了那些最容易快取的檔案，而來源站仍然要為每位使用者產生核心頁面內容。

這種預設行為並非沒有道理。HTML 頁面通常包含動態內容、個人化元素或與工作階段相關的資料，若盲目快取，可能會向使用者回傳過期資訊。然而，許多網站的 HTML 實際上大部分時間都很少變化。對於這類網站來說，不快取 HTML 就等於白白浪費了一次明顯的加速機會。你可以透過規則或頁面規則覆蓋預設設定，告訴 CDN 也快取 HTML 頁面，並為其設定合適的快取時間。

你需要結合內容類型來判斷。如果你的部落格文章或產品頁面更新頻率很低，那麼把 HTML 快取在邊緣節點會非常有價值。這樣，CDN 就能直接從其網路中回傳完整頁面，而來源站需要處理的請求會大幅減少。僅這一項調整，就可能顯著改善載入速度。

TTL 與快取清除錯誤

為快取內容設定合適的存活時間（TTL）至關重要。有資料表明，靜態資源的瀏覽器快取 TTL 可以高達一年，這也是效能最佳化中的常見建議值。然而，很多網站卻設定了很短的 TTL，導致瀏覽器頻繁重新驗證資源，從而給來源站帶來不必要的流量。

在後端，預設快取 TTL 甚至可能短到只有 5 秒。這個數值通常適用於內部資源快取，而不是面向用戶端的內容交付。如果你把這種極短的 TTL 用在瀏覽器快取上，系統就會不斷重新驗證內容，快取本該帶來的收益自然也就消失了。

不合理的快取清除策略同樣會引發問題。比如，同時執行兩個整頁快取外掛會造成規則衝突，導致回傳過期內容或破壞頁面版面。錯誤設定的壓縮選項，例如把不該合併的 JavaScript 檔案合併在一起，也會拖慢網站。把物件快取指向一台沒有持久化儲存能力的機器，也會降低效能。即使頁面已經快取在邊緣節點，如果其中包含未最佳化的圖片，或所有流量仍被路由到一台距離遙遠的機器，頁面載入依然會很慢。

為了避免這些問題，你需要正確設定 cache-control 標頭。cache control header 會告訴 CDN 和瀏覽器每種資源應快取多久。你必須正確設定 cache control header。較為平衡的做法是：靜態資源使用一年的 TTL，動態頁面使用較短的 TTL。僅在內容發生變化時才清除快取，從而盡可能保持快取處於「預熱」狀態。這會減少來源站負載，並提升回應速度。

第三方資源與 CDN

未快取的外部資源

你的 CDN 只能加速你自己網域下提供的內容，無法處理託管在第三方網域上的資源。你可能會嵌入來自公共 CDN 的 JavaScript 函式庫、來自行銷平台的分析指令碼，或者社群媒體小工具。這些請求都會完全繞過你的 CDN，直接從使用者瀏覽器存取外部主機。而這些外部主機可能回應緩慢、全球覆蓋有限，或者與目標使用者之間的網路連通性較差。結果就是頁面出現明顯延遲。

這個問題是可以修復的。你應審查頁面中的第三方依賴項，用自行託管的副本替換體積較大的供應商函式庫；使用 async 或 defer 屬性，避免指令碼阻塞渲染；還可以考慮使用標籤管理系統來控制載入時機。這些做法能夠減少未快取請求的數量，並提升整體效能。

混合內容問題

混合內容是指：你的 HTTPS 安全頁面中，仍然包含透過 HTTP 明文載入的資源。瀏覽器會將這類資源視為不安全內容，因此可能直接封鎖，或延遲其載入。而這種延遲會直接傷害頁面效能。

下表展示了混合內容對關鍵指標的影響。

效能維度	混合內容帶來的影響
瀏覽器載入	透過立即提供靜態頁面外殼，可改善 First Contentful Paint（FCP）和 Largest Contentful Paint（LCP）；使用者能更快看到有意義的內容，從而提升感知效能。
CDN 效能	靜態部分可由 CDN 快取，從而降低伺服器負載；動態部分僅在需要時渲染，最佳化資源利用率並減少冗餘網路請求。

當你修復混合內容後，瀏覽器就能立即載入靜態頁面外殼。這會改善 First Contentful Paint 和 Largest Contentful Paint。你的 CDN 可以快取靜態部分，降低來源站伺服器負載，而動態部分只在需要時才渲染，從而最佳化資源效率。

修復混合內容的方法很簡單：把所有資源 URL 都更新為 HTTPS；使用協定相對 URL，或者確保你的 CMS 產生的是安全連結。這樣，瀏覽器和 CDN 才能協同運作，消除混合內容帶來的載入延遲。

網路與 CDN 服務商問題

地理位置與海底光纜延遲

來源站伺服器的實體位置比你想像中更重要。如果使用者位於大洋彼岸，他們的請求就必須透過跨洲傳輸資料的海底光纜。這些光纜容量有限，在高峰期一旦發生擁塞，所有到達來源站的請求都會增加明顯延遲。CDN 無法從根本上解決這個問題。它只能把內容副本盡量存放到離使用者更近的地方。對於首次請求的未快取內容，資料仍然需要跨越海底光纜，而這一來一回的往返時間可能會拉長到數百毫秒。

你應認真考慮你的主要受眾究竟分布在哪裡。如果大多數流量都來自遠離來源站的地區，就應選擇在該區域覆蓋能力更強的 CDN。有些服務商在同一個國家內部就部署了多個邊緣節點，而另一些服務商覆蓋有限，導致使用者只能連線到更遠的邊緣節點。這種地理上的覆蓋差距會直接增加存取延遲。你可以使用一些支援多城市測試的免費工具，比較不同地區的回應時間，從而量化這一影響。

DNS 與邊緣網路品質

在頁面真正開始載入之前，DNS 解析本身也會帶來額外延遲。當使用者輸入你的網域時，瀏覽器必須先查詢 DNS 伺服器，才能取得網站對應的 IP 位址。一個緩慢的 DNS 服務商可能會在這個階段額外增加數百毫秒。你可以透過選擇回應速度快、具備全球覆蓋能力的 DNS 服務來減少這種延遲。有些 CDN 服務商會把高品質 DNS 作為服務的一部分提供，這樣你就不需要另外再找 DNS 託管商。

CDN 邊緣網路本身的品質，也會影響你的效能表現。研究表明，在分散式架構中增加更多伺服器，並不一定會降低延遲。額外的伺服器之間需要更多協調，反而可能增加往返時間。這說明，你應該評估 CDN 實際的邊緣效能，而不是想當然地認為「節點越多就一定越快」。

只看平均 TTFB 會掩蓋極端延遲尖峰。平均值會把 99 次快速快取命中與 1 次災難性的來源站逾時混合成一個中間數字，而這個數字並不能真實代表任何一次實際使用者工作階段。

這類網路問題往往會突然出現。你可能會發現延遲突然飆升，並持續數小時，而 CDN 服務商未必會及時承認問題。你可以透過持續監控邊緣效能，並準備好備用服務商，來降低這類風險。多 CDN 策略能在某一網路出現故障時為你提供切換空間。

「為什麼使用 CDN 後伺服器反而變慢？」這個問題其實有明確答案。伺服器變慢通常源於設定錯誤、網路問題、未被加速的第三方資源，或不合理的快取策略。這些問題都是可以解決的。首先要做的是持續監控效能，例如追蹤 Time to First Byte 和快取命中率等指標。這些指標能夠揭示延遲究竟出現在哪個環節。然後，調校快取標頭，為不同類型內容設定合適的 TTL；啟用 HTTP/2 以降低延遲；考慮使用專門的 origin shield 來保護來源站；多 CDN 策略也能幫助你規避單一服務商帶來的風險。定期檢查設定，及早發現問題。每一次調整，都會改善網站回應速度。