反向代理 Reverse Proxy？我願稱你為代理掮客！

　正向代理：你請朋友走進大賣場，請他找到對的貨架，請他拿你想買的商品。

　反向代理，你走進大賣場向店長說要買的東西，由店長幫你找到對的店員、對的櫃檯，買你想買的商品與結帳，就是反客為主、公親變事主！

歡迎來 FB 粉絲專頁、YouTube 抓住我們最新的蹤跡！

　在系統開發或者網站開發中，反向代理 (Reverse Proxy) 是在討論高流量、高併發網站架構、微服務部署，或是在使用像 Nginx 這類工具會出現，可說是這類系統的基礎建設之一。

　不過乍聽之下，反向代理這詞，蟲一開始覺得有點反人類，那個語感就像是，原本代理就是我找他做事，而反向代理就像是我找他來幫我做事，不過再想一下、舉個例類同一下就通了，關鍵就在於：斷句與服務對象的不同！

我找，他來幫我做事

正向代理：幫你存取某某服務

反向代理：幫網站分配你的需求

　就如前言所說，原本是你請你的朋友去大賣場、去小北買東西，是你朋友自己看指標、憑印象瞎拚蝦碰地找到貨架，最後找到你要的商品。

　現在反過來，你一走進小北就直接有店長問你要找什麼、要辦什麼服務，更優質的是，店長還幫你找了店員幫你搬大水(礦泉水)、也幫你找會員卡專員幫你辦會員，這位優秀的小北店長就充分發揮了反向代理的角色。

反向代理？反客為主、公親變事主

　先用「代理掮客」去想，掮客帶著你的需求去找服務，一樣接著上面的舉例，小北店長掮著你的需求，去找到對的服務(店員)，這樣反客為主、公親變事主的情境，就是我用代理掮客來做最直覺地概念交換的解釋。

　換回來用系統或網站來想，可以想像是某某網站、某某系統的門口就站著一位「掮客」、一位公司櫃檯的「接待人員」，當使用者上門，這位接待人會先詢問來意、確認需求，再將訊息轉交給內部的負責部門去處理。

　以使用者的視角來看，其實從頭到尾都只和這位接待互動，完全不會接觸到公司內部的實際部門，也不清楚公司後台的運作細節，而代理(櫃台)已經在幫你找到對的人、完成你的需求再交付給你，這就是反向代理的概念。

　反向代理通常部署在伺服器前端，負責攔截來自使用者的所有請求，再根據請求的路徑、網域、Header 或其他條件，將請求導向對應的後端服務或伺服器，整個過程中，使用者看到的只有「統一入口」，而非實際承接處理的伺服器架構。

　一開始我也覺得反向代理 Reverse Proxy 聽起來就像是 API 路由 API Routing，畢竟兩者都會處理請求的分流跟導向，不過處理的層級、應用範圍跟最終目的是不一樣的。

　簡單來說，API 路由負責應用層的「內部功能切換」，而反向代理負責系統層的「請求統整與流量控管」。

　還是那個熟悉的小北，現在，將這個情境放大十倍、百倍，甚至萬倍，如果最佳客容量 50 人的小北突然擠進 5,000 人甚至 10,000 人，那肯定是通通擠在門口，貨架什麼的根本擠進不去。

　在高流量 (使用者請求總量多，例如每秒幾千次請求)、高併發(同一時間內有大量請求發生)

　關於高流量 & 高併發還是多補充一下：

高流量：Nintendo Switch 2 發售公告一釋出，Nintendo 官網一小時內湧入 10 萬名用戶瀏覽。 / 整體系統的吞吐量

高併發：Nintendo Switch 2 結帳頁面在 8:00 一開放結帳，兩萬人同時點擊「結帳」。 / 整體系統的瞬間處理能力

　在面對流量、穩定性與維運時的種種問題，因而有了反向代理的種種應用方案：

負載平衡 Load Balancing：當後端服務架設了多台伺服器處理請求時，反向代理可以依照流量狀況將請求平均分派，避免某台機器超載。
靜態內容快取：像圖片、CSS、JS 等靜態資源可以在反向代理這層做快取，加快使用者載入速度，減少伺服器負擔。
SSL 終止 TLS Termination：反向代理可以集中處理 HTTPS 的加密與解密工作，讓後端服務僅需處理純 HTTP，簡化部署與維護。
統一入口 API Gateway ：使用者只需要對一個 URL 發出請求，背後實際請求會依路徑或條件分派至不同後端服務，對外呈現的是「單一門戶」。
資安防護：反向代理能配合 WAF（Web Application Firewall）、Rate Limiting、IP 黑名單等機制，加強系統防護能力。

以上種種，可以看出反向代理除了有優秀處理需求的櫃檯的意味，也有實質的系統守門員的功用。