假設你的網站只有一台 origin server，放在東京。台灣使用者打開它，request 要跨一段網路到東京再回來；歐洲使用者則要走更遠。如果圖片、CSS、JavaScript 每次都必須回到同一台 origin 取得，距離、流量和 origin 的負載都會逐漸變成瓶頸。

CDN（Content Delivery Network）的核心做法，是把一群分散在不同地區的伺服器放在 origin 前面，讓使用者的 request 先進入 CDN 網路，再由適合的 edge 節點回應或轉送。

一句話先記住：CDN 解決的是「每個人真的都需要跑回同一台 origin 拿同一份內容嗎？」

先認識 Origin 和 Edge

Origin 是內容真正的來源，例如你自己的 web server、object storage，或網站部署平台。Edge 則是 CDN 網路靠近使用者的一側。使用者通常先連到 edge，而不是直接和 origin 溝通。

使用者 → CDN edge → origin server

「靠近」不必理解成單純的直線地理距離。Internet routing 還會受到 ISP、peering、Anycast、網路壅塞等因素影響。實際目標是讓 request 進入一個能更有效率處理它的網路位置。

第一次沒有內容：Cache Miss

假設 edge 還沒有你的 logo.svg。使用者第一次 request 時，edge 找不到可直接使用的版本，就需要往 origin 取得內容。這通常稱為 cache miss。

origin 回傳檔案後，只要 caching 規則允許，edge 可以保存一份副本，再把 response 交給使用者。這時 CDN 並沒有改變「誰是內容來源」；origin 仍然是 source of truth，只是 edge 多了一份可以重用的 representation。

第一次：User → Edge（miss）→ Origin → Edge 儲存副本 → User

下一個人來了：Cache Hit

之後另一位使用者 request 同一份、而且仍然可重用的資源時，edge 就可能直接回傳自己的 cached copy，不必再次向 origin 取完整內容。這就是 cache hit。

之後：User → Edge（hit）→ 直接回應

這同時帶來兩件事：使用者少走一段往返 origin 的網路路徑，而 origin 也少處理一個 request。當同一份靜態內容被大量存取時，差異會非常明顯。

所以 CDN 就是 Cache 嗎？

不是。Cache 是「保存一份可重用 response」的機制；CDN 是一套分散式內容傳遞基礎設施。CDN 很常大量使用 caching，所以兩個概念經常一起出現，但 CDN 還要處理 routing、TLS、proxy、流量吸收、節點分布等事情。

反過來也成立：你可以有 cache，卻完全沒有 CDN。瀏覽器自己的 HTTP cache、Redis、application memory cache 都是例子。

CDN 也不是「把整個網站複製到全球」

這是另一個很容易產生的誤解。哪些內容會被 cache、多久可以重用、哪些 request 必須回 origin，都取決於 CDN 和 origin 的設定。

圖片、CSS、JavaScript 等 static assets 通常很適合 cache；登入後的個人頁面、即時庫存、會因 cookie 或 authorization 不同而改變的 response，就不能隨便讓 shared cache 對所有人共用。CDN 並不是看到 HTTP 就全部存起來。

Reverse Proxy：為什麼使用者看不到 Origin？

很多 CDN 會以 reverse proxy 的方式站在 origin 前面。client 連的是 CDN；CDN 收到 request 後，決定自己回應，或代表 client 往 origin 取得資料。

這和 browser 裡手動設定的 forward proxy 方向不同。reverse proxy 是站在 server 這一側替後面的服務接流量，因此可以統一處理 TLS、cache、安全規則、流量限制和 routing。

Client → Reverse Proxy / CDN → Origin

Anycast 又是什麼？

大型 CDN 常利用 Anycast，讓許多網路節點對外宣告同一個 IP prefix，由網路 routing 把使用者送到適合的節點。對使用者來說，看起來像是在連同一個位址；實際上不同地區的流量可以進入不同資料中心。

所以 CDN 的「離你近」不是靠 JavaScript 先量距離再挑 server，而是網路層與 CDN routing 一起決定 request 從哪裡進入系統。

CDN 能降低 Origin 壓力，但不會讓 Origin 消失

cache hit 越多，origin 收到的重複 request 就越少。但 cache miss、需要 revalidation 的內容、不可 cache 的 dynamic response，仍然可能一路回到 origin。

因此 origin 掛掉時，「CDN 前面還有 cache」不代表整個網站一定完全正常。有些已 cached 的資源可能繼續被提供，但需要即時回 origin 的功能仍然會失敗。CDN 提高韌性，不等於 origin 可以不管。

那 Hosting 和 CDN 差在哪？

Hosting 解決的是「你的網站或程式實際在哪裡執行、檔案放在哪裡」；CDN 解決的是「內容和 request 怎麼更有效率地在使用者與來源之間傳遞」。

現在很多平台會把兩者包在一起。例如 static site 部署後，檔案可能直接被平台放進全球 edge network。這時你感覺不到傳統的「一台 origin 主機」，但概念上仍然可以分辨內容來源、部署系統和 edge delivery 各自負責什麼。

CDN 不是永遠比較快

如果資源本來就很小、使用者和 origin 很近，或 CDN cache 命中率很低，額外的 DNS、TLS、proxy 和第三方依賴也可能帶來成本。尤其從另一個第三方 CDN 載入 library，不代表瀏覽器就一定能和其他網站共享那份 cache。

所以「用了 CDN」不是性能保證。真正要看的仍然是 latency、cache hit ratio、TTFB、origin load、資源大小，以及使用者實際所在的網路。

最後，把 CDN 想成分散式的前線

Origin 保存原始內容與應用邏輯；CDN edge 站在更前面接住大量 request。能直接重用的內容就在 edge 回應，不能的才往 origin 走。

CDN 真正的價值不是「多放幾台 server」，而是把內容傳遞、cache 與 routing 從單一 origin 前面抽出來，變成一層分散式網路。理解這一點後，cache hit、cache miss、edge、reverse proxy 和 Anycast 就不再是幾個互不相干的名詞。

如果只想先留一句：CDN 讓使用者先遇到分散在網路邊緣的節點，而不是每次都跑回同一個 origin。

資料來源

CDN 的基本定義與分散式節點說明參考 MDN CDN；edge caching、origin 與 CDN 架構參考 Cloudflare CDN Reference Architecture；reverse proxy、Anycast 與 proxied traffic 的說明參考 Cloudflare Fundamentals。