Playwright 流量會經本機 VPN 嗎？本地、遠端與 CI 檢查

Playwright 流量可以經本機 VPN，但真正發出請求的程序須在該電腦執行並採用其 VPN 路徑。遠端瀏覽器或 CI worker 須獨立驗證，context 的代理亦可能改變你原本以為正在測試的路線。

關鍵要點：

• 分別找出瀏覽器及 API 請求程序。
• 遠端瀏覽器控制連接與網頁請求並非同一條路徑。
• 代理及 Service Worker 會改變觀察的含義。
• 用自有端點的請求證據驗證，VPN 圖示或網頁語言不足以證明。

步驟 1：Playwright 流量在哪裏發出？

改設定前畫出執行關係：Node 測試程序所在機器、瀏覽器所在機器及任何代理或網絡共享機制。「手提電腦執行腳本」不能確定瀏覽器也在本機。browserType.connect() 接入瀏覽器服務，並不在本地啟動該瀏覽器。［2］

私下核對 launch 與 connect 程式。chromium.launch() 在執行該程式的環境啟動瀏覽器，容器與遠端開發工作階段仍屬那個環境，未必是桌面系統。記錄執行版本及設定，避免公開含憑據的連接端點。

控制 WebSocket 連接測試客戶端與瀏覽器服務，導航請求則是另一個流程。官方 connect API 的 exposeNetwork 可以明確暴露指定客戶端網絡給遠端瀏覽器，所以「遠端路線」亦有須記錄的例外。不要只為這次診斷開啟寬泛網絡暴露。［2］

整台執行主機連接有問題時，先用裝置排障指南。本文則聚焦這次請求由哪個元件發出，以及哪些證據可以確認其路徑。

步驟 2：哪項 Playwright 代理設定生效？

Playwright 可以為整個瀏覽器設定 HTTP(S) 或 SOCKSv5 代理，亦可對個別 context 設定。官方網絡指南還說明代理認證及 bypass。核對實際解析後的設定，不只看儲存庫中的示例。［1］

記下設定位於 launch、context 建立或獨立客戶端。代理地址及目標繞過範圍保存在私人記錄，憑據透過獲准秘密管理處理，不放截圖、shell 歷史、trace 或完整環境變數記錄。

請求或元件	要記錄的執行位置	需要的驗證
本地啟動瀏覽器	執行 launch 的主機	自有端點收到的瀏覽器請求
connect 接入瀏覽器	瀏覽器服務主機及網絡共享選項	與控制連接分開的網頁路徑
已設定代理的 context	瀏覽器位置及代理出口	實際代理與目標 bypass
APIRequestContext	實際擁有 API 請求 context 的 driver	自身請求及代理證據
CI 或遠端 worker	真正 worker 環境	worker 路線、政策與存取權限

代理可連接，不代表目標會看到該電腦的公網出口。代理在其他位置時，目標可能看到代理的對外地址，即使本機經 VPN 連到代理。分清各跳，本地隧道可能只改變前往代理的連接，不改代理向外的出口。

概念見系統隧道與應用代理比較。保留必要組織設定，只有停用強制代理才成功，是另一個設定案例，不能證明原設定已修復。

步驟 3：Playwright APIRequestContext 是否同路？

page.request 和 browserContext.request 提供與瀏覽器 context 關聯的 APIRequestContext，官方 API 指南說明兩者 Cookie 共享。由 request.newContext() 建立的獨立 context 有自己的 Cookie 儲存。這種儲存關係不能證明 API 經瀏覽器程序的網絡路線。［3］

找出實際擁有 API 請求 context 的 driver，並核對其選項。在本例採用的 Playwright 1.62.1 Node.js 實作中，BrowserContext 關聯請求經該 context 的 driver 執行，繼承 context／browser 的代理預設。本地 API runtime 建立的獨立 request.newContext() 屬另一種情況，不能只按腳本主機判斷全部 API 請求位置。分別驗證導航、關聯 API context 及獨立 API context。［5］

使用你擁有、回傳無害請求元資料與可預期結果的端點。各做一次安全瀏覽器與 API 請求，用不同無敏感關聯 ID，再對照服務端記錄。清楚記錄認證及目標，不為了成功把瀏覽器 Cookie 複製到不相關請求。

瀏覽器與 curl 環境比較可以解釋第三種客戶端，卻不能取代兩項 Playwright 流程的證據。另一個Postman 客戶端逾時時，獨立記錄其執行位置及代理。

步驟 4：Playwright Service Worker 會隱藏請求嗎？

Service Worker 可直接回應網頁或發出自己的網絡請求。Playwright 區分 frame 與 Service Worker 擁有的請求，官方文檔說明對應事件及 routing。頁面顯示內容，不表示新請求已到達伺服器。［4］

查看回應是否經 Service Worker，以及測試有沒有攔截它。fixture、快取或離線 shell 可以成功顯示，但沒經過你想量度的網絡。將這類結果視為應用或攔截證據，而非公網出口證據。

在獲准診斷 context 中，網絡指南建議當 Service Worker 妨礙 route 觀察時阻止它。不過這會改變測試設定，必須留下記錄；需要等同正式應用行為的測試，不可靜默取消 Service Worker。［1］

建立獨立可棄置 context，保留原應用工作階段。核對自有小型無快取端點與預期標記，確認測試不在本地 fulfill 請求。不關 TLS、不公開內部服務，也不削弱安全控制來方便觀察。

步驟 5：如何比較本地執行路線？

瀏覽器真正位於受支援本地電腦時，AethoVPN 可用於比較該電腦前往自有端點的路線。選 App 目前列出的本國或鄰近位置，開啟全局模式並重複同一瀏覽器請求。目標觀察與預期結果分開保存，不與 APIRequestContext 結果混合。

Windows 使用官方安裝程式，Debian／Ubuntu x64 使用 .deb。Mac 按網站向導取得配置，需要 Pro 或 Premium。先核對目前公網出口，再驗證每一項請求；另一瀏覽器開啟 IP 頁面，不能證明測試瀏覽器路線。

比較不會把本機隧道延伸到遠端瀏覽器、授予 CI 網絡權限或覆寫獨立代理的出口。需要帳戶完成獲准本地比較時，可建立帳戶並開始 3 天免費 Pro 試用，每人一次，註冊時開始計算。

遠端執行須請 runner 負責人提供獲准路線及該環境的請求觀察。VPN 連接檢查只用於相關裝置，並記錄網絡共享選項。不開 exposeNetwork: '*' 或新增公網監聽作捷徑。

實際任務為網站地區行為時，繼續IP 與瀏覽器座標測試。Playwright geolocation 改變瀏覽器座標，不確定請求的公網 IP 或國家；帳戶偏好、語言及快取需要獨立案例。

步驟 6：受控示例支持甚麼結論？

本地示範實際以 Playwright 啟動 Chromium，再以獨立 APIRequestContext 請求自有回環端點。伺服器記錄不同案例 ID，報告保存兩項預期回應與執行程序資料。

截圖是真實本地報告，不是虛構設定畫面或正式 VPN 結果。目標為 loopback，peer 地址不能證明公網出口。同機示例亦不能重現獨立託管瀏覽器或 CI 的路由。

自己的報告應包含瀏覽器啟動位置、API 執行位置、代理來源、Service Worker 處理、fixture 攔截、脫敏案例 ID 和目標結果。不包含帶 token 的控制 URL、認證儲存、含秘密的 trace 或真實用戶數據。

測試後關閉棄置 API context 與瀏覽器，還原臨時設定，沒有新證據就停止。頁面從快取成功而端點沒收到請求，先查快取及攔截，再推斷路線。結論只涵蓋實際測得的程序與嘗試，不保證全部 worker 走同一隧道。

總結

• 分別定位瀏覽器與 API 客戶端。
• 記錄代理、網絡共享、Service Worker 及本地攔截。
• 對自有端點發出無害請求，保留各自證據。
• 本地、遠端及 CI 結論只涵蓋實際觀察環境。

常見問題

在手提電腦啟動腳本，瀏覽器就一定在本機嗎？

只有在該本地 runtime 啟動的瀏覽器才屬該環境。connect 可以控制別處的瀏覽器，須查看啟動或連接程式及執行環境。

控制 WebSocket 決定頁面出口 IP 嗎？

控制連接與網頁請求屬不同流程。先記錄瀏覽器位置、代理及網絡暴露選項，再判斷目標請求從哪裏發出。

Cookie 共享可以證明路線相同嗎？

Cookie 共享是儲存關係，而非網絡路徑證據。導航與 APIRequestContext 各自量度，尤其程序可能位於不同主機時。

fixture 回應成功，可以證明網絡成功嗎？

fixture 只驗證本地測試提供的行為。不證明真實伺服器收到請求，也不確定前往目標流量的公網出口。

每個測試都應阻止 Service Worker 嗎？

只在有記錄且有助觀察的診斷 context 使用。要求實際應用 Service Worker 行為的測試，須保留並獨立驗證。

本地 VPN 涵蓋遠端 CI worker 嗎？

CI worker 有自己的網絡環境與權限。與負責人設定及核對該 worker 的獲准路線，不假定桌面連接影響它的請求。

回環示例究竟驗證了甚麼？

它驗證兩個不同本地客戶端完成無害示例請求。不證明公網出口、遠端瀏覽器路由或 VPN 改善效能。

免責聲明： 只測試自有或獲准端點。遵守當地法律及組織政策，保留 TLS 驗證，不用自動化作越權擷取或規避存取控制。

來源：

1. Playwright — Network — https://playwright.dev/docs/network
2. Playwright — BrowserType — https://playwright.dev/docs/api/class-browsertype#browser-type-connect
3. Playwright — API testing — https://playwright.dev/docs/api-testing
4. Playwright — Service Workers — https://playwright.dev/docs/service-workers
5. Playwright 1.62.1 — API request server implementation — https://github.com/microsoft/playwright/blob/v1.62.1/packages/playwright-core/src/server/fetch.ts

Sources checked 2026 年 10 月 7 日。

---

延伸閱讀：

• 分清網站 IP 規則與瀏覽器座標
• 比較瀏覽器及終端執行環境
• 區分系統隧道與應用代理
• 在執行電腦驗證連接