代理伺服器如何運作？
了解代理伺服器的運作機制——請求轉發、IP 遮蔽、緩存，以及流量通過中間伺服器的逐步流程。
了解代理伺服器的運作機制——請求轉發、IP 遮蔽、緩存，以及流量通過中間伺服器的逐步流程。
當您將瀏覽器或應用程序配置為使用代理時，您的每一個請求都會循不同路徑到達互聯網。您的瀏覽器不是直接連線至目標伺服器，而是將 HTTP 或 HTTPS 請求發送至代理伺服器的 IP 地址和端口號。代理接收此請求，按其配置進行檢查，然後開立自己獨立的連線至實際目標——即您嘗試訪問的網站。
目標伺服器收到來自代理 IP 地址的傳入連線。它處理此請求，與處理任何其他請求一樣，生成回應——您所請求的網頁、API 數據、圖像或文件。此回應被發送回代理伺服器。代理隨後將回應轉發至您的設備，完成往返旅程。您的瀏覽器正常渲染內容，不知道它已通過中間人路由。
這一雙連線模型是所有代理操作背後的基本機制。第一個連線在您的設備與代理之間；第二個在代理與目標之間。關鍵在於，這是兩個獨立的 TCP 連線——目標伺服器無法看到您設備的 IP 地址，因為它只與代理直接接觸。目標的任何記錄均捕獲的是代理的 IP，而非您的 IP。
IP 遮蔽是使用代理最常被引用的原因，但其機制比單純的「隱藏您的 IP」更為細緻。當代理將您的請求轉發至目標伺服器時，它將 TCP 數據包標頭中的來源 IP 替換為自己的 IP 地址。目標收到來自代理 IP 的連線，僅憑網絡層無法從技術上確定原始客戶端的 IP。
然而，您的身份被遮蔽的程度，取決於代理的匿名級別。透明代理在 HTTP 標頭字段 X-Forwarded-For 中傳遞您的真實 IP——實際上不提供任何隱私保護。匿名代理從數據包標頭中移除您的真實 IP，但仍可能包含標識自身為代理的 X-Forwarded-For 標頭。精英或高匿名代理則會剔除所有此類標頭，使請求看似源自沒有任何代理中間人的普通終端用戶瀏覽器。
同樣重要的是要了解，IP 遮蔽僅對目標伺服器隱藏您的 IP。您自己的 ISP ↗ 仍可看到您正在連線至代理伺服器的 IP 地址，而代理供應商本身也從您為訪問代理而建立的連線中得知您的真實 IP。若要實現真正的匿名瀏覽，您需要將代理與其他隱私措施結合使用，或考慮 VPN 或 Tor 是否更符合您的威脅模型。
代理伺服器最初的用途之一——在企業及 ISP ↗ 部署中仍是重要使用場景——是內容緩存。當緩存代理首次提供某個請求時，它會存儲回應的本地副本。下次該代理後的任何用戶請求相同資源時，代理便直接提供緩存副本，而無需從源站重新獲取。這節省了頻寬、減少了伺服器負載，並可大幅改善頻繁存取內容的回應時間。
現代緩存代理實施精密的緩存管理系統。它們遵守源站伺服器設置的 HTTP 緩存控制標頭，這些標頭指示緩存可存儲內容的時長及在何種條件下應重新驗證。條件式 GET 請求允許代理核查緩存資源是否已更新，而無需下載完整回應。當內容已更改時，代理獲取並存儲新版本；若未更改，304 未修改回應允許代理放心地提供緩存副本。
內容傳遞網絡（CDN）——現代網絡性能的骨幹——本質上是大規模、地理分佈的緩存代理網絡。當您訪問託管在 Cloudflare、Akamai 或 AWS CloudFront 上的網站時，您的請求通常由實體上靠近您的緩存節點提供服務，而非源站伺服器。這就是代理緩存在全球規模上的運作，將全球用戶的延遲從數百毫秒降低至個位數毫秒。
處理加密的 HTTPS 流量對代理伺服器而言是一個挑戰。使用純 HTTP 時，代理可完整讀取和檢查每個請求和回應。但 HTTPS 使用 TLS 加密在您的瀏覽器與目標伺服器之間建立端對端加密通道。簡單的代理無法讀取 HTTPS 請求的內容，也無法在不破壞加密的情況下將自身插入其中。
大多數正向代理的解決方案是 HTTP CONNECT 方法。當您的瀏覽器想要透過代理存取 HTTPS 網站時，它會向代理發送 CONNECT 請求，指定目標主機和端口（例如 CONNECT example.com:443）。代理隨後建立至目標的 TCP 連線，並發送回 200 連線已建立的回應。從此時起，代理充當透明管道——它盲目地在您的瀏覽器和目標之間轉發加密字節，無法解密它們。TLS 握手直接在您的瀏覽器和目標伺服器之間進行。
部分企業代理採取不同方法：SSL 檢查（亦稱 HTTPS 攔截或設計上的「中間人」）。這些代理解密 HTTPS 流量，檢查是否存在政策違規或惡意軟件，重新加密後轉發至目標。這需要在員工設備上安裝受信任的根憑證，以使代理重新簽名的憑證受到信任。雖然在企業安全環境中合法，但這種方法從根本上破壞了端對端加密，切勿在明確披露的企業環境以外使用。
