正向代理 & 反向代理
更新於 發佈於 閱讀時間約 2 分鐘
帶著這樣的疑問，我在網路上找到一篇用「租房」來說明正向／反向代理的文章：【終於有人把正向代理和反向代理解釋明白了！】，內容相當詳細好懂，對轉職人來說真是太棒了，這篇筆記也是基於該文章整理而成的唷～
既然是以租房為範例，首先我們要知道稍後會出現的幾個角色：
- 租客 (開發者/使用者)
- 房東 (目標伺服器)
- 二房東 (代理伺服器)、房仲 (代理伺服器)
正向代理
情境：
租客向房仲(代理伺服器)詢問物件，並由房仲來進行帶看，但房東並不會知道看他房子的人(開發者/使用者)是誰
正向代理是伺服器(仲介)代理了「用戶端」(租客)去和「目標伺服器」(房東)進行交互
正向代理的用途：
- 如果有重複的請求，可以從暫存(cache)取資料，加快速度 (房仲可以多次帶看)
- 突破或減少網域限制 (假設房仲手上案源多，就不會受限於單一房東)
- 隱藏使用者IP位置，減少攻擊 (房東不知道租客訊息)
反向代理
情境：
房東將物件交給親戚朋友(代理伺服器)來進行洽談帶看，租客(開發者/使用者)並不知道真正的房東是誰，會認為自己接洽的就是房東(目標伺服器)
反向代理是伺服器(二房東)代理了「目標伺服器」(房東)去和「用戶端」(租客)進行交互
反向代理用途：
- 如果有重複的請求，可以從暫存(cache)取資料，加快速度 (二房東一樣可以多次帶看)
- 負載均衡 (房東很忙，又不想委託第三方，於是請認識的親友來幫忙分擔)
- 隱藏服務器IP位置，充當防火牆，減少攻擊 (租客不知道房東訊息)
正向代理 & 反向代理 比較
正向代理和反向代理看起來都是用戶和目標伺服器之間的橋樑，都可以提高訪問速度，但兩者還是有所區別的，透過表格比較會更加清楚些：
了解兩者差異之後，回到 vite proxy 上吧，在開發階段，前端會使用 vite 創建的虛擬伺服器去 call 後端的 API，這時候虛擬伺服器和後端伺服器處於不同的伺服器位置，而產生了跨域問題，vite proxy 可以幫我們把 API 的路徑(例如：http://localhost:5173/api/bar) 換成真實的後端 API 網址(https://google.com/api/bar)。
也就是 vite 伺服器(租客) 在不知道房東(後端伺服器)真實身份的情況下，一樣可以獲取 API 的數據資料，這就是 vite 的反向代理囉！至於 vite proxy 代理的實作方式，直接參考官方文件就可以了～
其他參考資料：
我是Amber，前端學習中，歡迎交流討論🧸
23會員
22內容數
留言0
查看全部
你可能也想看
Google News 追蹤
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
在這篇教學文章中，我們將展示如何使用 Node.js 建立一個簡單的伺服器，並解決常見的跨來源資源共享（CORS）問題，確保伺服器能夠接收並處理來自不同來源的資料。
※ 什麼是Web API
API 就是後端開出來讓前端來用的介面，讓前端與後端可以溝通。
API流程：
終端使用者用任何一種裝置進入瀏覽器。
瀏覽器透過 API 向後端發出請求，請求查詢或修改資料。
後端透過 API 收到前端的請求後，取得資料並回應給前端。
前端渲染畫面，終端使用者
※ 原本狀態：伺服器渲染
這是 MVC 架構下的 request / response 示意圖，在這張圖呈現的架構裡，畫面和資料都由同一個架構處理。
伺服器渲染流程：
瀏覽器針對特定網址送出請求。
路由器解析請求後，轉接給對應的 controller。
controller 按照要求，透過
代理模式通過封裝原始對象來實現對該對象的控制和管理，同時不改變原始對象的行為或客戶端與該對象互動的方式，以此介入或增強對該對象的訪問和操作。
在開發前後端分離架構時，使用兩個不同網域所遇到跨域請求問題。特別是在POST請求時行為差異大，揭示了「簡單請求」與「預檢請求」的關鍵差異。簡單請求不需預檢，但application/json會觸發預檢請求，需透過特定設定解決。分享這篇文章希望幫助開發者有效處理跨域問題。
Accept：用戶端能夠接收的內容類型。
Accept: text/plain, text/html
Accept-Charset：瀏覽器可以接受的字元編碼集。
Accept-Charset: utf8
Accept-Encoding：指定瀏覽器可以支援的web伺服器返回內容壓縮編碼
HTTP伺服器端
package main
import (
"net/http"
)
type Refer struct {
handler http.Handler
refer string
}
//實現中介軟體邏輯
func (this *Refer) ServeHTTP(
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
在這篇教學文章中，我們將展示如何使用 Node.js 建立一個簡單的伺服器，並解決常見的跨來源資源共享（CORS）問題，確保伺服器能夠接收並處理來自不同來源的資料。
※ 什麼是Web API
API 就是後端開出來讓前端來用的介面，讓前端與後端可以溝通。
API流程：
終端使用者用任何一種裝置進入瀏覽器。
瀏覽器透過 API 向後端發出請求，請求查詢或修改資料。
後端透過 API 收到前端的請求後，取得資料並回應給前端。
前端渲染畫面，終端使用者
※ 原本狀態：伺服器渲染
這是 MVC 架構下的 request / response 示意圖，在這張圖呈現的架構裡，畫面和資料都由同一個架構處理。
伺服器渲染流程：
瀏覽器針對特定網址送出請求。
路由器解析請求後，轉接給對應的 controller。
controller 按照要求，透過
代理模式通過封裝原始對象來實現對該對象的控制和管理，同時不改變原始對象的行為或客戶端與該對象互動的方式，以此介入或增強對該對象的訪問和操作。
在開發前後端分離架構時，使用兩個不同網域所遇到跨域請求問題。特別是在POST請求時行為差異大，揭示了「簡單請求」與「預檢請求」的關鍵差異。簡單請求不需預檢，但application/json會觸發預檢請求，需透過特定設定解決。分享這篇文章希望幫助開發者有效處理跨域問題。
Accept：用戶端能夠接收的內容類型。
Accept: text/plain, text/html
Accept-Charset：瀏覽器可以接受的字元編碼集。
Accept-Charset: utf8
Accept-Encoding：指定瀏覽器可以支援的web伺服器返回內容壓縮編碼
HTTP伺服器端
package main
import (
"net/http"
)
type Refer struct {
handler http.Handler
refer string
}
//實現中介軟體邏輯
func (this *Refer) ServeHTTP(