Skip to main content
讓瀏覽器的請求經過你的擴充功能所控制的 proxy 伺服器。 Extension.js 沒有任何針對 proxy 的行為。proxy API 屬於瀏覽器,而你的 manifest.json 權限會原封不動進入建置產物。各目標之間的差別在於哪些權限會被保留,所以請從這裡看起。

各目標如何處理該權限

一份宣告了 "proxy" 的資訊清單,建置結果如下: Safari 建置會印出原因:
在承諾 Safari 上的 proxy 行為之前,請先為此做好規劃。只想為單一目標加上資訊清單鍵時,請見依瀏覽器區分的資訊清單欄位

設定固定 proxy

在背景 service worker 設定 proxy,那裡可以使用該 API:
proxy 權限是必要的,Chromium 建置通常還需要涵蓋目標網站的主機權限。

隨擴充功能提供 PAC 指令碼

PAC 指令碼不是資訊清單欄位,因此打包器不會把它當成進入點。它不會被計算雜湊、改寫路徑,也不會自行進入產物。有兩條可行路線。 把指令碼當成 data 內嵌傳入:
或者把指令碼保留成檔案。public/ 目錄裡的內容會原樣複製進建置產物,所以放在那裡的 PAC 檔案會以同名出現在 dist/<browser>/。從你自己的擴充功能來源以 fetch 讀取它,再把文字當成 data 傳入。public/ 的作用請見特殊資料夾

處理 proxy 驗證

需要憑證的 proxy 會觸發 chrome.webRequest.onAuthRequired。Manifest V3 移除了阻擋式 webRequest,因此要回應該挑戰,除了 webRequest 之外還需要 webRequestAuthProvider 權限。 攔截網路請求介紹了 Manifest V3 保留的請求 API,以及 declarativeNetRequest 在哪些地方取代了阻擋式 API。
編譯進擴充功能的憑證,任何安裝者都讀得到。環境變數也改變不了這件事,因為它們的值在建置時就被內嵌了。請見環境變數

Firefox 的機制不同

Firefox 有一個同名權限下的 proxy API,背後的模型並不一樣。Firefox 透過 browser.proxy.onRequest 讓擴充功能逐一請求做決定,而不是儲存一份設定物件。 Extension.js 不會針對這個差異提出警告。它的 Gecko 相容性警告涵蓋的是其他 API,因此 Chromium 形態的 chrome.proxy.settings.set 呼叫進入 Firefox 建置時不會有任何訊息。請在 MDN 確認該 API,並在發布前測試 Firefox 目標。

也可以只代理開發用瀏覽器

有時你想代理的是開發期的瀏覽器,而不是擴充功能。這時請傳瀏覽器參數,而不是使用擴充功能 API:
瀏覽器參數介紹了這個變數與 browserFlags 設定項。

後續步驟