什麼是 Proxy？

Proxy 是位於用戶端（例如您的應用程式）與目的地伺服器（例如後端 API）之間的中繼伺服器。 當您的應用程式傳送要求時，Proxy 會先接收它。 然後，Proxy 可以將要求轉送至目標伺服器、修改、封鎖或直接傳回回應。

簡言之，Proxy 代表用戶端或伺服器來調解通訊。

Proxy 的運作方式

Proxy 會藉由接收連入要求並採取下列一或多個動作，在 HTTP 層級運作（或其他應用程式通訊協定）：

  • 將要求轉送 至目標伺服器，然後將響應轉送回用戶端。
  • 在 轉送之前修改標頭、URL 或承載。
  • 在本地攔截並回應要求，無需聯絡目標伺服器。
  • 根據 規則或存取原則拒絕要求。

從客戶端的觀點來看，它只會將要求傳送至 URL。 Proxy 會在幕後處理其他所有專案。 此模式是客戶端到代理伺服器再到目標伺服器。

此模式引進了一層控件和抽象概念，可用來改善安全性、可觀察性、效能和可測試性。

Proxy 的類型

有不同類型的 Proxy。 每個角色都適合系統架構中的特定角色。

正向代理

正向 Proxy 位於 用戶端前面。 當您的應用程式提出要求時，它會通過 Proxy，以決定是否和如何轉送它。 正向代理通常用來：

  • 控制外部資源的存取。
  • 匿名用戶端流量。
  • 記錄傳出流量以進行監視。
  • 套用內容篩選或轉換。

反向代理

反向代理伺服器位於伺服器 前面。 用戶端不知道基礎後端基礎結構。 反向代理會接收連入要求，並將其轉送至後端伺服器之一。 反向 Proxy 通常用來：

  • 跨多個服務對流量進行負載平衡。
  • 提供快取的回應，以減少後端負載。
  • 終止 TLS/SSL 連線。
  • 從公用因特網隱藏內部服務詳細數據。

透明代理

透明代理會在不需要用戶端明確設定使用它的情況下攔截流量。 此類型用於公司或因特網服務提供者環境中，以強制執行原則或監視使用方式。

為什麼 Proxy 對應用程式開發人員很重要

基礎設施或網路小組通常會管理代理伺服器。 不過，Proxy 會直接影響應用程式行為，特別是在開發和測試環境中。 以下是一些實際的方式，它們會影響你的日常工作。

偵錯和可觀察性

Proxy 可以擷取和檢查 HTTP 流量。 這類工具如 Dev Proxy、Fiddler、Proxyman、Charles Proxy 或 mitmproxy 可作為本地的正向代理服務。 您可以通過這些工具運行您的應用程式，以分析請求和回應、找出錯誤，並驗證標頭或身份驗證令牌。

API 閘道和路由

在許多生產系統中，應用程式的後端流量會透過 API 閘道或反向 Proxy 路由傳送，例如 NGINX，或 Azure API 管理等雲端原生服務。 這些 Proxy 會處理路由、驗證、速率限制等等。

當你設計 API 或建置分散式服務時，必須了解代理如何影響標頭（例如 X-Forwarded-For）、逾時以及請求大小限制。

CORS 和本機開發

在本機開發期間，特別是在 Web 應用程式中，當您從瀏覽器呼叫 API 時，可能會遇到跨原始來源資源分享 （CORS） 限制。 開發代理可以將您的請求轉發到目標 API，同時重寫標頭以繞過 CORS 限制。 重寫 CORS 要求的開發人員工具常見範例，包括 Express 或 ASP.NET Core 等架構中的 vite、webpack-dev-server或自定義 Proxy 中間件。

服務虛擬化和測試

Proxy 可以模擬後端 API。 在實際服務無法使用、不穩定或使用成本昂貴的情況下進行測試時，這項功能就會很有用。 透過攔截與模擬回應，你可以測試應用程式在不同情境下的行為，例如逾時、錯誤或資料錯誤。

Dev Proxy代理或自定義代理實作之類的工具通常被用於整合測試和端對端測試。

驗證和安全性

代理伺服器通常是保護應用程式安全的第一線防禦。 他們可以強制執行訪問控制、插入驗證標頭，或終止 TLS/SSL 連線。 身為開發人員，務必要了解應用程式在代理伺服器後方的行為，以及如何存取包含驗證或身分識別資訊的標頭。

常見的標頭和代理伺服器考慮因素

當要求通過 Proxy 時，會新增或修改特定標頭，以保留重要的元數據。 例如：

  • X-Forwarded-For：指出用戶端的原始IP位址。
  • X-Forwarded-Proto：表示原始通訊協定（HTTP 或 HTTPS）。
  • X-Forwarded-Host：表示用戶端所要求的原始主機。

當您的應用程式在反向 Proxy 後方執行時，請確定您的架構或平臺已設定為信任並正確解譯這些標頭。

用代理工具測試你的應用程式如何處理 API 失敗

因為前轉代理會看到你應用程式發出的每一個請求，它也可能直接以失敗回應其中一些請求，而不是轉發：a 500、帶有 Retry-After 標頭的 429 Too Many Requests，或是需要 8 秒的回應。 你的應用程式會持續呼叫真實的 API URL，所以你要在生產環境中測試應用程式，包括它的 HTTP 客戶端、SDK 和重試策略。

與其他測試 API 失敗的方法相比：

Approach 你發現的 你錯過的內容
等待生產 實際失敗 在使用者點擊它之前的一切
在測試中模擬 API，或讓你的程式設計代理寫出模擬 不管你的錯誤分支是否執行 API 的真實狀態碼、標頭和錯誤內容，以及你的 SDK 重試政策。 你的應用程式也需要一個僅供測試使用的開關來連到模擬物件。
呼叫真正的 API，希望它失敗 實際行為 你無法隨需引發故障
讓你的應用程式透過可模擬故障的 Proxy 執行 真實網址的錯誤、限速和延遲，隨選 單獨來看你的程式碼。 把那件事留給你的單元測試。

開發代理作為開發和測試的正向代理

Dev Proxy 是一種前向代理，你可以在自己的機器或 CI 中執行，攔截並修改應用程式對你選擇的 API 的請求。 透過開發代理，您可以：

  • 查看您的應用程式如何回應 API 錯誤。
  • 確認你的應用程式如何處理 API 速率限制和限速。
  • 查看您的應用程式如何處理緩慢的 API。
  • 不用寫一行程式碼就能建立模擬 API。
  • 獲得有關如何使用 API 的情境指導。

要在您的應用程式所呼叫的 API 上試用它，先下載預設並啟動 Dev Proxy。 例如，針對 GitHub：

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

也提供 OpenAI（openai-throttling）、Anthropic（anthropic-throttling），以及 Microsoft Graph OneDrive 和 SharePoint 端點（microsoft-graph-rate-limiting）的預設設定。

請您親自試試看

選擇一個與你正在建造的場景相符的場景：

後續步驟

開始使用

  • 上次更新時間：