瀏覽器自動化的代理繞過與 PAC 規則稽核指南
瀏覽器顯示「已設定代理」，不代表所有流量都會通過代理。PAC 規則、作業系統例外、NO_PROXY、擴充功能、Service Worker、WebSocket 用戶端與獨立網路函式庫，都可能讓部分請求直接連線。頁面成功載入，只能證明頁面載入了，不能證明購買的代理覆蓋所有關鍵請求。
本指南面向獲得授權的資料蒐集、市場研究、在地化 QA 與廣告驗證團隊，提供一套可重現的代理繞過驗收方法。
測試前先定義路由承諾
寫清楚哪些請求必須走代理、哪些可以直連，並列出瀏覽器版本、自動化執行環境、協定、目的網域群組、工作階段模式及 IP 位址族。將結果分成三類：
- 已代理：請求使用預期代理出口；
- 核准直連：例如有紀錄的本機健康檢查；
- 意外直連：任何其他繞過代理的請求。
不要把「瀏覽器使用代理」當成驗收條件，這句話無法涵蓋 DNS、子資源、背景請求與 WebSocket。
建立受控觀測點
使用自有或獲授權的測試端點，記錄來源位址、請求時間、協定、主機名稱與隨機執行編號。編號不可含憑證、Cookie 或客戶資料。若代理閘道提供記錄，再使用同一編號關聯瀏覽器、閘道與端點證據。
每次執行至少保存：
| 欄位 | 用途 |
|---|---|
| 執行與請求編號 | 關聯三處證據 |
| 目的主機 | 找出規則特定的繞過 |
| 資源類型 | 區分文件、圖片、腳本、API 與 WebSocket |
| 觀測到的來源 IP | 區分代理出口與用戶端網路 |
| 要求的工作階段 | 發現靜默切換 |
| IPv4 或 IPv6 | 揭露雙棧差異 |
| 時間戳記 | 分析輪替與設定變更 |
測試端點應回傳最小回應並採用保守限速。它是量測工具，不是流量產生器。
建立路由矩陣
不要只測最上層文件。矩陣應包含：
- HTTPS 文件與同源子資源；
- 位於自有網域的跨來源圖片、腳本與 API；
- 工作負載使用時的 WebSocket；
- 新 DNS 名稱與已解析名稱；
- 同時涉及兩種位址族時的 IPv4 與 IPv6 主機；
- 預期直連的 localhost 或私有端點；
- 能明確命中每一條 PAC 或繞過規則的主機名稱。
先在全新瀏覽器設定檔執行，再於暖快取設定檔重複。兩者比較能找出 Service Worker、快取及持續連線造成的差異。
逐層檢查繞過來源
代理例外可能來自多個層級。要記錄執行時真正生效的值，而不是只查看設定檔。
PAC 決策
依實際評估順序列出規則，並測試精確主機、子網域、大小寫、結尾句點、不同連接埠，以及工作負載使用的國際化網域名稱。寬泛的字尾匹配必須特別小心：原本只為一項內部服務設定的例外，可能意外涵蓋無關網域。
環境與作業系統
檢查代理環境變數、作業系統網路設定及自動化啟動參數。繼承的 NO_PROXY 或平台預設值，可能覆蓋原本正確的瀏覽器設定。
瀏覽器與擴充功能
擴充功能可能在啟動後修改代理設定；Service Worker 可以發出背景請求；預先連線及預先擷取也可能出現在可見頁面流程之外。測試時應採用與正式環境相同的擴充功能組合。
外部網路函式庫
下載器、媒體元件、原生訊息助手或獨立 HTTP 用戶端不一定使用瀏覽器網路堆疊。只要工作流程會呼叫，就應視為獨立用戶端測試。
在不洩露用戶端位址下證明路由
使用兩個獨立受控端點：一個預期接收代理流量，另一個作為明確的直連金絲雀。比較觀測來源與已知代理出口及去識別化的用戶端網路指紋。報告只需保留是否相符，不應長期保存操作者的精確住宅位址。
若正式環境不需要直連金絲雀，就把它限制在隔離測試環境。不要為了證明問題，讓真實客戶目的地意外收到直連流量。
分開測試輪替與黏性工作階段
輪替工作階段應建立新的、有紀錄的工作階段鍵，並確認一次邏輯交易中的所有資源都遵循預期策略。黏性工作階段則要在承諾時長內重複矩陣，同時記錄出口與路由類別變化。
新的代理 IP 不等於繞過，應分別分類：
- 出口改變，但流量仍走代理；
- 流量從代理改為直連；
- 只有某一協定繞過；
- IPv6 直連、IPv4 走代理；
- 第一次失敗後的重試改變路由。
可搭配住宅代理工作階段黏性測試與代理重試預算指南進一步驗證。
計算能支援採購的指標
報告必須列出分母，並依瀏覽器版本、路由規則、目的網域群組、協定及位址族分段：
- 代理覆蓋率：已代理請求除以必須代理的請求；
- 意外直連率：未核准直連請求除以全部觀測請求；
- 交易完整率：所有必要請求皆走預期路徑的交易占比；
- PAC 決策正確率：得到預期直連或代理結果的規則案例占比；
- 路由穩定率：沒有無法解釋的路由類別變化之工作階段占比；
- 證據完整率：可跨瀏覽器、閘道與端點關聯的請求占比。
對隱私或地理準確性敏感的工作，即使整體比例很低，一次意外直連也可能是上線阻斷項目。
設定上線門檻
實用門檻可要求：
- 必須代理的矩陣中沒有意外直連；
- 每一條核准直連都有負責人與理由；
- 正式主機模式的 PAC 決策 100% 正確；
- 除非為明確設計，不允許 IPv4 與 IPv6 使用不同路由；
- 全新與暖快取設定檔表現一致；
- 路由證據不包含機密與個人載荷；
- PAC 或瀏覽器變更後的回復流程已驗證。
採用通過、條件通過、失敗、證據不足四種結論。條件通過必須限制瀏覽器版本、市場、協定與停用功能；證據不足應補齊量測，而不是擴大無效流量。
疑難排解順序
找到直連請求時：
- 確認主機名稱、協定、資源類型與位址族；
- 以全新設定檔及單一請求重現；
- 評估該精確主機名稱的 PAC 結果；
- 檢查環境、系統與瀏覽器例外；
- 確認是否由擴充功能或外部助手發出；
- 對齊用戶端、閘道與端點時間戳記；
- 縮小到具體規則，再重跑完整矩陣；
- 記錄修正方式及迴歸案例。
在理解合法的本機與內部流量前，不要急著加入全面代理的寬泛規則，否則可能破壞健康檢查及私有服務。
採購檢查清單
- 定義必須代理與核准直連的範圍。
- 涵蓋文件、子資源、API 與 WebSocket。
- 同時測試全新與暖快取設定檔。
- 明確命中每條 PAC 與繞過模式。
- 分開統計 IPv4 與 IPv6。
- 找出會靜默改變路由的重試。
- 用去識別化編號關聯三處證據。
- 對重大直連風險採用零容忍門檻。
- 瀏覽器、擴充功能、PAC 或作業系統更新後重測。
- 測試記錄不保存憑證、Cookie 與個人資料。
常見問題
查看瀏覽器公用 IP，能證明所有請求都走代理嗎？
不能。它只能證明這一次查詢顯示該位址；子資源、WebSocket、DNS 行為或外部助手仍可能走不同路徑。
localhost 是否一定要直連？
通常如此，但不是絕對。應記錄預期並測試各種名稱與位址形式，避免寬泛例外涵蓋正式網域。
PAC 檔案會造成間歇性故障嗎？
會。依賴 DNS 的規則、快取決策、回退指令與不同主機名稱形式都可能造成不一致，應使用確定性案例並記錄最終決策。
連線失敗要算成繞過嗎？
可用性與路由應分開統計。失敗本身不能證明繞過，但失敗後的重試若改為直連，就必須計為意外路由變更。
合規說明
只在自有或獲授權的系統與目的地執行路由稽核，遵守供應商合約、目的地條款、隱私要求及速率限制。不得利用代理規避存取控制、隱藏濫用行為、冒充身分或製造流量。只保留工程及採購決策所需的最低限度去識別化證據。
