透過FAQ專案理解反向代理

前言

這是我在翻新舊版專案到新架構時遇到的問題，因為是第一次接觸反向代理，所以特別記錄下來，藉此加深理解。過程中，我發現反向代理在分流請求、提高安全性和優化效能方面發揮了重要作用。
透過這次經驗，我學習了其基本概念，也清楚如何在專案中正確配置與應用。這篇文章將整理我的學習過程與心得，希望能幫助有相同需求的開發者更快上手。

反向代理

在開發過程中，我們經常會遇到前端與後端分開部署的情境，這時候反向代理 (Reverse Proxy) 就能發揮關鍵作用。這篇文章將先介紹反向代理的概念與優勢，接著再進入 Vite 設定，最後說明 Base Path 與多語系配置。

什麼是反向代理

我習慣用門牌來比喻網址，那麼反向代理就像是郵局。當使用者發送請求時，這些請求不會直接送到真正的伺服器，而是先經過「郵局」(反向代理伺服器)，郵局會負責轉送請求，再將結果帶回來給使用者。

這樣的設計讓使用者無需知道真正的伺服器位置，只需與反向代理溝通即可。
與傳統代理的差別：

傳統代理 (Forward Proxy)：用戶請求代理，代理再去訪問網站（類似 VPN）。
反向代理 (Reverse Proxy)：用戶請求網站，實際上請求由代理伺服器處理，再轉發給內部伺服器。

好處是什麼

那為什麼我們要多一道反向代理這個麻煩的手續呢？主要有 4 個關鍵優勢：
1.安全性：

隱藏真實伺服器的 IP，避免直接攻擊（例如 DDoS）。
可設定存取控制 (Access Control)，只允許合法請求通過。

2.效能提升：

快取靜態資源，減少對後端的請求，提升回應速度。
壓縮請求，減少頻寬消耗。

3.負載平衡：

分散流量到多台伺服器，避免某台伺服器過載。
可動態調整，讓高流量時網站依然穩定運行。

4.集中管理：

統一管理 SSL 憑證，簡化 HTTPS 配置。
可設定統一的存取控制、日誌管理，方便監控與維護。

在開發過程中，反向代理常被用來處理 API 請求，特別是當前端與後端伺服器分開時，能有效解決 CORS 問題。

專案介紹及修改

在了解了反向代理的概念後，接下來我們要來看一下我這次專案修改的部分了

基礎路徑（Base Path）？

我們一樣用門牌來比喻基礎路徑，以這個專案/faq為例，代表我的專案會是在example.com/faq 這個地址，我們所有的靜態資源都會從這個地址去找。常見的網站架構可能是這樣：

1
2
3

example.com/       #主網站
example.com/faq/   #FAQ
example.com/admin  #後台

在這種情境下，每個子系統都是獨立應用，需要各自的靜態資源。因此，我們透過 base 設定來區隔資源路徑，確保不同應用之間不會互相干擾。

Vite設定

因為我的專案是用vite，所以我必須要到vite.config.ts這隻檔案去做兩個設定：
1.開發環境的代理設定（Development Proxy）
如果我們的 API 伺服器位於 https://backend.example.com，我們希望開發時透過 /api 來轉發請求，可以這樣設定：

export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: '<https://backend.example.com>',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\\/api/, '')
      }
    }
  }
});

2.基礎路徑設定（Base Path Configuration）

export default defineConfig({
  base: '/faq/',    // 設定基礎路徑
  // ...其他設定
});

這樣做有兩個主要目的：

讓 Vite 知道應用程式會部署在 /faq/，確保產生的 HTML、CSS、JS 路徑正確。
所有靜態資源都會從 /faq/ 開始尋找，避免部署時發生 404 錯誤。
設定前後的變化：

# 設定前的資源路徑
example.com/main.js
example.com/style.css

# 設定後的資源路徑
example.com/faq/main.js
example.com/faq/style.css

如果不設定 base，Vite 預設會讓資源路徑從 / 載入，當專案部署到 /faq/ 這樣的子目錄時，所有靜態資源會無法正確載入，造成錯誤。
之後我們的網站長這樣：

example.com/             # 主網站
example.com/faq/         # FAQ 系統（你的專案）
example.com/admin/       # 後台管理系統
example.com/shop/        # 購物系統

每個子系統都是獨立應用
每個子系統都需要各自的靜態資源
透過base的設定來區隔資源路徑(這也是這次的主要目的之一)

多語系(i18n)設定

i18n是一套多語系轉換常用到的套件，非常值得花一個篇幅來介紹，但本章的重點不是在此，所以只講這次修改到的地方，這次的修改重點在於調整語系檔案的載入方式，以減少不必要的資源下載。

i18n.init({
  ns: ['common', 'feature'],  // namespace(命名空間)
  defaultNS: 'common',        // 預設命名空間
  backend: {
    loadPath: "faq/locales/{{lng}}/{{ns}}.json",  // 語系檔案路徑
  }
})

這是一個動態路徑模板，用來告訴 i18n 要去哪裡找語系檔案：

{{lng}}是我們的語系，例如：zh-TW、en-US等等
{{ns}}是我們的命名空間的變數，這個專案有兩個 feature 跟 common
這樣設定完後，我們的結構長這樣：

faq/locales/
├── en-US/
│   ├── common.json    # 共用翻譯
│   └── feature.json   # 功能翻譯
└── zh-TW/
    ├── common.json
    └── feature.json

至於為什麼要這樣改？因為原本的語系檔案過大，會一次載入所有語言與功能翻譯，導致初次加載時間變長。透過拆分，我們可以只載入當前語系所需的部分，大幅提升效能。

後記

這次的 FAQ 專案讓我認識反向代理以及他的必要性。說真的，一開始接觸反向代理時，我也覺得這概念有點抽象 - 為什麼需要一個「中間人」來處理請求呢？
但當我實際在專案中使用 Nginx 作為反向代理後，才慢慢的理解它。我們可以想像 Nginx 就像是一個超級管家，幫我們：

管理所有靜態檔案（JS、CSS）的存放位置
處理多語系檔案的請求
將 API 請求轉發到對的地方

最讓我驚豔的是，這個「管家」不只是單純地轉發請求而已，它還：

幫我們擋掉一些可能的攻擊（增加安全性）
幫忙分散伺服器的負擔（負載平衡）
透過快取來加速response的速度

經過這次的實作，我不只學會了如何設定專案的基礎路徑（base path）和處理多語系載入，更重要的是理解了為什麼大型專案都需要反向代理這樣的架構。雖然設定過程中遇到了一些坑，但解決這些問題的過程也讓我學到很多。
希望這篇筆記對其他正在學習的前端工程師有幫助。有時候，一個看似複雜的概念，實作過後才發現：「原來是這樣啊！」