在 Vite 設定開發環境的 Proxy

為了處理一個反向代理問題而去了解 Vite 的 Proxy 使用方式

實際上這是為了在 Vite 去嘗試 Proxy 的使用，為了了解反向代理的運作來解決工作上遇到問題而產生的文章，所以想把脈絡也記錄下來，若要直接查看 Vite 設定 Proxy 設定的方式，可以直接下滑到「解決方式」的部分。

前情提要

某天在公司被告知，要將我們網站中的其中一個儀表板頁面放到政府的整合平臺，我們只要提供儀錶板網址，整合平臺那邊會設定「反向代理」。但實際上，整合平臺設定後，我們的儀表板依然沒辦法在整合平臺順利呈現，呼叫 API 時都會有 CORS 跨網域問題，後端即便針對整合平臺的跨網域問題進行設定也沒辦法解決。

原本想說就真的是提供現有網址就好，但因為牽涉到反向代理，就不是單純「提供網址」這麼簡單了。

問題

在拼湊各種資訊後，認為在 A 網站中無法呈現我們儀表版的內容，可能是跟呼叫 API 的 URL 相關，原本在我們自己的系統，假設儀錶板頁面網址是https://ourDashboard.com.tw，取資料呼叫的 API 是 https://ourDashboard.com.tw/api/info。

這邊反向代理的概念，是整合平臺 (假設網址是 https://integrate.com)) 會將我們的網址從原本的 https://ourDashboard.com.tw 改寫為是 https://integrate.com，但這時候我們的儀表板同樣是去呼叫 https://ourDashboard.com.tw/api/info，這時兩者是不同網域，當然會出現 CORS 問題。

若要解決這個問題，理當是我們在 https://integrate.com 網站時，要呼叫的 API 要是 https://integrate.com/api/info；而在我們自己的網站時，呼叫的 API 是 https://ourDashboard.com.tw/api/info。儀表板這個頁面的程式碼都不用動，需要調整的只是呼叫 API 的路徑。

前端在呼叫 API 時，是使用 Axios 套件去統一設定 baseURL，原先處理方式是在正式機環境就會採用正式機的 url、測試機就會採用測試機的，而實際的 url 是寫死在環境變數檔案中，原本的寫法大概類似以下。而這個設定就不太好在同一個頁面去設定當網域不同時要呼叫不同的 API url，如果是寫一個判斷網域來使用不同 API url 似乎也怪怪的。

import axios from 'axios';

const instance = axios.create({
  // 測試機或正式機 API URL 透過環境變數檔案去帶出來
  baseURL: import.meta.env.VITE_APP_API_BASE_URL,
  headers: {
    'x-api-key': import.meta.env.VITE_APP_OEIA_API_KEY,
  },
  withCredentials: true,
});

解決方式

初次接觸反向代理的時候，覺得這實在很謎，在別人的網站中，應該呼叫別人的網域名稱的 API，但實際上會轉向我們自己的網站，整合平臺是透過後端在 IIS 去設定反向代理達到這個目的。

其實以這邊的反向代理問題，就是將 Axios 的 baseURL 改為直接抓 Domain name，就可以搭配整合平臺所設定的反向代理，基本上就處理完了。繞了一大圈了解發生什麼事，理解概念後，其實處理方式並不難。

但當時希望自己在前端有辦法先測試看看反向代理是怎麼運作的，因此想到可以試試看 Vite 裡面的 Proxy 設定，這個設定主要是在開發環境測試 API 使用的。( 因此以下設定會是基於開發環境要去呼叫測試機的 API。)

1. 在 Axios 的 baseURL 不要用環境變數去帶了，改為直接抓 Domain Name 的方式

import axios from 'axios';

const instance = axios.create({
  // 原本是直接帶測試機或正式機的 API URL，這邊改成會直接去套用網站的 Domain name
  baseURL: '/api', 
  withCredentials: true
});

2. 在 vite.config.js 檔案中，設定 proxy

import { defineConfig } from 'vite';

export default defineConfig({

 ...
  server: {
    host: '0.0.0.0',
    proxy: {
      '/api': {
        target: 'https://developDashboard.com.tw', // 開發環境，實際上後端 API 進入點
        changeOrigin: true, // 是否允許跨域，true 代表允許跨域，因為本機網域跟呼叫 API 的網域不是同一個
        secure: false // 如果是 https 的話，要改成 true，但因為本機開發的話會是 http，所以這裡設成 false

        // rewrite: path => path.replace(/^\/api/, '')
      }
    }
  },
});

• proxy 內的屬性， /api 是要對應 Axios 中的 baseURL
• target 為後端 API 的路徑
• changeOrigin ，是否允許跨域， true 代表允許跨域，因為本機網域跟後端 API 的網域不是同一個，所以這邊會設定為 true
• secure ，如果是 https 的話，要改成 true，但因為本機開發的話會是 http，所以這裡設成 false
• rewrite ，假設目前設定 baseURL 是 /api ，而後端的 API 路徑也包含 /api 的話，那不用特別設定 rewrite，但如果後端 API 路徑不包含 /api 這一段的話，就要將這一段用空值取代掉

3. 在瀏覽器的開發人員工具中可以看到，URL 會直接指向測試機，目前看到的 API URL 就會像是 http://localhost:5173/api/info （localhost 就依照本機的 port 不同）。它的運作概念也同樣會是，藉由 vite.config.js 的設定，當看到 URL 有 /api 這樣的關鍵字時，就將網址改為是 [https://developDashboard.com.tw](https://developDashboard.com.tw)

4. 測試時可能會有點小疑惑，不確定到底是不是正常轉址過去了，可以從開發人員工具中，「網路」的部分確認呼叫 API 的 URL，以及回應的資料是否正確