Reverse Proxy 是什麼？為什麼使用者連到的伺服器，不一定是真正處理請求的那一台？

你輸入一個網址，DNS 找到 IP，瀏覽器建立 HTTPS 連線，接著送出 HTTP request。直覺上，你可能會以為：「這個 IP 對應的那台伺服器，就是網站本體。」

但現代網站常常不是這樣。

你真正連上的，可能只是一個站在最前面的入口。它自己不負責登入、不查資料庫，也不執行主要商業邏輯，而是收到 request 後，再把它交給後面的服務。

這個入口常見的角色，就是 Reverse Proxy（反向代理）。

一、先從 Proxy 說起

Proxy 的核心概念很簡單：A 原本要和 B 溝通，但中間多了一個 P。A 先把東西交給 P，再由 P 去找 B。

Forward Proxy 比較像站在 client 這一側。Client 知道自己正在使用 proxy，由 proxy 代表 client 去存取外部網站。Reverse Proxy 則反過來，站在 server 這一側：瀏覽器先連到 Reverse Proxy，再由它連到 Backend 或 Upstream。

使用者通常只知道 reverse proxy 的公開網址，甚至根本不知道後面到底有幾台 server。所以「reverse」不是因為資料倒著走，而是代理的方向和 forward proxy 不同。

二、一個最簡單的例子

假設你做了一個網站 https://example.com，真正的 Node.js 應用程式只跑在內部的 3000 port。這個 port 沒有直接暴露給網際網路，外部使用者先連到負責 443 port 的 Nginx。

Nginx 收到 request 後，根據設定把它轉送到應用程式。對使用者來說，他始終只是在存取 example.com。他不需要知道 3000 port，也不需要知道後面跑的是 Node.js、Python、Go，甚至另一台機器。

這就是 reverse proxy 最核心的工作：提供一個對外入口，隱藏並代理後面的服務。

三、Upstream 是什麼？

在 reverse proxy 的語境裡，你很常看到 upstream。它可以理解成「proxy 接下來要把 request 交給誰」。

Upstream 可能是一個 application server，也可能是一組 server。Reverse proxy 收到 request 後，可以決定送到其中哪一台。因此 reverse proxy 不只是轉發，它還可以成為整個流量入口的控制點。

四、為什麼不讓使用者直接連 Backend？

如果只有一個小型測試服務，直接開 port 當然可以運作。但正式系統通常希望把「對外連線」與「應用程式本身」拆開。

第一個原因是統一入口。系統可能同時有 frontend、API、auth、images，而且每一部分由不同服務處理。Reverse proxy 可以根據 hostname 或 path 分流，例如 /api 交給 API server、/auth 交給 Auth service。對外仍然只需要一個 domain。

第二個原因是後端不必直接暴露。Application server 可以只允許內部網路存取，Internet-facing 的部分交給 reverse proxy。這不代表「用了 reverse proxy 就安全」，但它讓網路邊界與責任更清楚。

五、TLS termination：HTTPS 不一定在 App 裡結束

HTTPS 需要 TLS。如果每一個 backend 都自己處理 certificate、private key 與 TLS negotiation，管理會變得很麻煩。

因此常見架構是 Browser 先用 HTTPS 連到 Reverse Proxy，外部 TLS 連線在 proxy 結束，再由 proxy 連到 Backend。這叫 TLS termination。

Reverse proxy 可以集中管理 certificate 與 TLS 設定，後面的 application 專心處理 HTTP request。Proxy 到 backend 之間也可以繼續使用 TLS，是否需要取決於網路環境與安全需求。

重要的是：網址顯示 HTTPS，不代表 TLS 一定一路直接連到最終執行程式的那台 server。

六、Load Balancing：一個網址後面可以有很多台 Server

假設網站流量變大，一台 application server 不夠了。你可以開 App A、App B、App C，但使用者不需要自己決定要連哪一台。

Reverse proxy 可以做 load balancing。每次收到 request，proxy 按照規則選一個健康的 upstream。最簡單可能是 round robin，也就是輪流分配；更複雜的系統則可能依照目前連線數、延遲、權重或其他條件選擇 server。

因此，使用者看到一個 domain，背後卻可能是一整群機器。

七、Reverse Proxy 還能做什麼？

因為所有 request 都先經過它，所以 reverse proxy 很適合處理「每個服務都需要，但不想每個服務各寫一次」的事情。

例如加入或修改 HTTP headers、壓縮 response、Redirect HTTP 到 HTTPS、限制 request 大小、Rate limiting、Access log、IP allowlist、Cache、Health check，以及路由不同服務。

這也是為什麼 reverse proxy 往往不只是單純的中繼站，而是整個 web architecture 的重要邊界。

八、Nginx 為什麼常和 Reverse Proxy 一起出現？

Nginx 是很常見的 web server，也能當 reverse proxy。當它收到特定路徑的 request，可以依設定把 request 交給另一個 application。

這不代表 Nginx 就是 API。Nginx 負責入口與轉送；真正理解 API 邏輯的，仍然是後面的 application。

九、Cloudflare 算 Reverse Proxy 嗎？

在常見的 proxied 網站設定下，可以把 Cloudflare 理解成位於網站前方的大型 reverse proxy 與 edge network。使用者先連到 Cloudflare 的 edge，而不是直接連到 origin server。Cloudflare 再依設定與快取狀態決定是否需要向 origin 取得內容。

所以「使用者連到哪台 server」和「真正產生內容的是哪台 server」本來就可能是兩個不同問題。

十、Reverse Proxy 和 CDN 差在哪？

兩者有重疊，但不是同義詞。Reverse proxy 描述的是一種網路角色：client 先連到 proxy，再由 proxy 代表 server-side 系統去找 upstream。

CDN 的重點則是把內容分散到許多 edge location，讓使用者能從較近的位置取得內容，並大量利用 cache。很多 CDN 本身就是以 reverse proxy 方式工作，所以兩個概念常同時出現。

可以簡化成：Reverse Proxy 在問「誰站在 backend 前面接 request？」；CDN 在問「如何利用分散式 edge 與 cache 更有效率地配送內容？」同一個服務可以同時符合兩種描述。

十一、Reverse Proxy 和 API Gateway 又差在哪？

API Gateway 通常也會 reverse proxy request，但它更強調 API 管理。除了 routing，它可能額外負責 authentication、authorization、rate limit、API key、quota、request transformation、observability 與 version routing。

因此可以把 API Gateway 看成更專門針對 API traffic 的入口層，而 reverse proxy 是更基礎、更廣義的架構概念。不是每個 reverse proxy 都是 API Gateway，但很多 API Gateway 的底層行為包含 reverse proxy。

十二、Proxy 之後，Backend 怎麼知道原始使用者資訊？

這會帶來一個實際問題。Backend 收到的連線可能來自 reverse proxy，所以它直接看到的來源 IP 是 proxy。

如果 application 需要知道原始 client，proxy 通常會透過 forwarded headers 傳遞來源 IP、原始 protocol 與 host 等資訊。

但這些 header 不能無條件相信。如果 backend 同時接受不受信任的直接外部連線，來源資訊可能被偽造。因此 application 通常必須設定哪些 proxy 是可信任的，只有來自可信 proxy 的 forwarded information 才能作為判斷依據。

這也是部署 web framework 時常看到 trust proxy 設定的原因。

十三、Reverse Proxy 不是「把網站藏起來就安全」

它確實可以避免 backend 直接暴露，也能集中 TLS、流量限制與其他防護，但不能因此把它當成安全保證。

如果 application 本身有權限驗證錯誤，reverse proxy 不會憑空知道哪個使用者能讀哪筆資料。如果 origin 仍然允許所有人直接連線，也可能繞過前面的 proxy。

Reverse proxy 是架構層，不是萬能防護罩。

十四、一次完整 Request 可以經過多少層？

把前面幾篇 Explore 的概念串起來，一次開網頁可能先由 DNS 把 domain 解析到公開 IP，Browser 再與 edge 或 reverse proxy 建立 HTTPS 連線。Reverse proxy 檢查 request 並決定路由；如果有 cache 而且命中，可能直接回 response；如果沒命中，proxy 才把 request 送到 upstream application。Application 又可能呼叫其他 API 或 database，最後 response 再一層一層回到 browser。

最後整理

Reverse Proxy 是站在 server 前方的代理層。Client 把 request 送給它，它再把 request 轉交給真正處理工作的 upstream。這讓系統可以隱藏 backend、統一 domain、集中 TLS、做 routing、load balancing、cache、logging 與流量控制。

最值得記住的不是某一套伺服器設定語法，而是一個架構觀念：

公開網址代表的是服務入口，不一定代表真正執行服務的那台機器。

理解這一點後，CDN、Cloudflare、load balancer、API gateway、container service 甚至大型網站的多層架構，都會開始變得比較容易看懂。