Isoline 指南

每個瀏覽器設定檔的代理伺服器:DNS、驗證與失敗模式

設定檔代理是網址路由控制,不是全裝置通道。實際邊界取決於代理類型、DNS 歸屬、驗證支援、略過規則、替代路徑與非 HTTP 流量。

本指南以 Chromium 文件記載的網路行為為參考。其他瀏覽器與產品可能採不同方式,管理工具也可能在 Chromium 外加入本機網路中介。請驗證實際使用的確切版本。

從四個獨立問題開始

代理紀錄通常包含協定、端點、連接埠,有時有驗證參照,但仍留下四項政策問題:

  1. 涵蓋範圍: 哪些瀏覽器要求與協定指派給此代理?
  2. 名稱解析: 由裝置還是代理解析目的地主機名稱?
  3. 驗證: 哪些用戶端與代理驗證方式相容,憑證存在哪裡?
  4. 失敗: 連線錯誤時停止要求、嘗試另一代理,還是改為直接連線?

把這些視為單一「代理已開啟」開關,是許多意外的來源。Chromium 將代理選擇記為網址層級解析:目的地未必已解析,網址先產生有順序的代理選項清單。略過與替代規則都是決策的一部分。

設定檔代理涵蓋什麼

Google 的 ProxySettings 政策套用於 Chrome 設定檔層級,可選直接、系統、自動偵測、固定伺服器或 PAC 腳本模式,並提供明確略過與強制 PAC 欄位。

這個邊界比 VPN 或作業系統網路命名空間窄,只管理瀏覽器網路情境處理的要求,不自動管理:

  • 桌面管理工具自己的 API 呼叫;
  • 程序外 App 或瀏覽器更新器;
  • 作業系統 DNS 與連線檢查;
  • 從下載檔案啟動的其他 App;
  • 擴充功能的獨立原生輔助程式;
  • 透過隱含回送略過規則存取的本機服務;
  • 所選代理路徑無法承載的協定流量。

其中部分元件可能有自己的代理支援,但必須另外規定並測試。「設定檔流量走這個代理」應指明涵蓋程序與協定,不能暗示全裝置路由。

追蹤一次 HTTPS 要求

一般 HTTPS 導覽有幾個步驟。

1. 選擇路徑

瀏覽器評估固定規則、代理自動配置腳本或系統設定。符合略過規則可能直接連線。代理清單可先選主要代理再選替代項目;允許直接退回時也可能包含 DIRECT。

Chromium 對 localhost 與鏈路本地目的地也有隱含略過規則。這保護本機來源免受外部代理設定控制,但也意味著「所有流量」的描述需要限定。

2. 解析並連上代理

代理端點若是主機名稱,裝置仍需解析並連到它。目的地 DNS 在遠端進行,不會消除這個起始查詢。此處失敗,與已連到代理但代理無法解析目的地,是不同問題。

3. 向代理驗證

需要憑證的 HTTP 代理通常回傳 407 Proxy Authentication Required 與驗證挑戰。RFC 9110定義交換方式,以及 Proxy-Authenticate、Proxy-Authorization 欄位。

Chromium 不使用嵌入手動代理設定的帳號密碼。代理文件說明驗證改走瀏覽器一般憑證流程。因此管理工具需要明確整合支援的挑戰,不能承諾任何 user:password@host 字串都可用。

4. 建立目的地連線

使用 HTTP 代理時,Chromium 將目的地名稱解析交給代理。HTTPS 目的地則由瀏覽器要求代理建立 CONNECT 通道,再透過通道與目的地進行端對端 TLS。

代理仍知道目的地主機名稱與連線中繼資料。用戶端到代理使用明文 HTTP 時,該段的 CONNECT 要求與主機名稱不受保護。HTTPS 代理在瀏覽器與代理之間加入 TLS,防止兩者之間的旁觀者讀取這些資料,但不會讓代理本身看不到目的地。

代理通常無法讀取通道內的 HTTPS 頁面內容。TLS 攔截是另一種信任模型:用戶端信任某憑證機構,讓中介終止並重建 TLS。不能把它與一般轉送混為一談。

DNS 歸屬隨代理協定改變

Chromium 記載的行為依代理類型不同:

路徑 Chromium 的目的地解析位置 重要限制
直接或略過 裝置或瀏覽器解析器 目的地流量不經設定檔代理
HTTP 代理 代理端 明文用戶端到代理傳輸會暴露 HTTP 要求;HTTPS 使用 CONNECT
HTTPS 代理 代理端 用戶端必須驗證代理 TLS 憑證
SOCKS4 用戶端 僅 IPv4 目的地;Chromium 未實作 SOCKS4a 替代方式
SOCKS5 代理端 Chromium 用於 TCP 網址要求,文件說明不支援 SOCKS5 驗證

RFC 1928允許 SOCKS5 要求攜帶網域名稱,也定義多種驗證方法識別碼。但協定能力不保證用戶端有實作。Chromium 目前會將目的地名稱送給 SOCKS5 代理,卻說明內建 SOCKS5 用戶端不支援代理驗證。供應商若提供帳號密碼式 SOCKS5,可能需要受支援中介或另一代理協定。接受紀錄前先確認瀏覽器實作。

DNS-over-HTTPS 再加一層。Chrome 的 DnsOverHttpsMode 政策區分 automatic 與 secure:前者可能退回不安全 DNS,後者在安全 DNS 失敗時直接解析失敗。這個政策是瀏覽器層級,ProxySettings 卻是設定檔層級。這提醒我們,一項設定標示「設定檔」,不代表所有 DNS 控制都有相同範圍。

每個設定檔以獨立瀏覽器程序執行的產品,可能形成更窄的有效邊界,但那是實作選擇,必須測試。證據應區分:

  • 代理端點解析;
  • 要求目的地解析;
  • 直接或略過要求所用 DNS;
  • 安全 DNS 的起始解析與退回行為;
  • 設定檔瀏覽器網路情境之外元件執行的 DNS。

驗證同時涉及相容性與機密處理

Chromium 記載 HTTP 代理支援 Basic、Digest、Negotiate、NTLM;HTTPS 代理加入受保護的用戶端到代理通道,也可支援用戶端憑證。雖然 SOCKS5 規格有驗證方法,Chromium 內建代理用戶端仍未實作 SOCKS4、SOCKS5 驗證。

相容的方式在錯誤傳輸上也可能不安全。RFC 7617說明 Basic 憑證只是 Base64 編碼,需要 TLS 等保護通道。對明文 HTTP 代理使用 Basic,會向能觀察該段流量的人暴露代理密碼。

管理工具應分開下列資料:

  • 非機密端點中繼資料,如協定、主機、連接埠與供應商標示;
  • 生命週期或網路服務使用的機密參照;
  • 受保護儲存中的憑證值;
  • 介面與稽核軌跡使用的遮蔽連線狀態;
  • 只能透過受控支援流程取得的診斷細節。

一般畫面、紀錄、API、匯出與自動化輸出不需要代理密碼。操作人員通常需要知道驗證失敗、被要求哪種方式、涉及哪個端點,以及是否發生替代連線。

失敗模式及其表現

失敗 常見症狀 應驗證的邊界
代理協定錯誤 TLS 或協定交握失敗 是否將 HTTPS 端點宣告為 HTTP,或反之?
代理名稱無法解析 到達代理前就失敗 哪個解析器執行起始查詢?
代理連接埠不可達 逾時或拒絕連線 清單下一項是否為其他代理或 DIRECT?
不支援驗證挑戰 重複 407 或登入提示 瀏覽器有實作該驗證方式嗎?
憑證錯誤或到期 提交憑證後仍出現 407 機密參照是否成功解析,輸出是否遮蔽?
HTTPS 代理憑證失敗 代理安全連線被拒 憑證驗證是否完整保留?
代理無法解析目的地 代理特定主機或通道錯誤 用戶端是否避免改為直接重試?
CONNECT 被拒 該目的地 HTTPS 導覽失敗 拒絕是否當作政策,而非繞過許可?
PAC 檔不可用 代理解析停滯或改路徑 PAC 是否強制,還是能默默用 DIRECT?
略過條件過廣 部分網站直接連線 是否理解精確主機、子網域、連接埠及隱含規則?
WebRTC 使用其他介面 媒體路徑不同於頁面流量 該設定檔是否停用非代理 UDP?
變更後舊連線仍在 舊路徑暫時有效 是否排空連線或重新啟動設定檔?
診斷擷取過度詳細 網址、主機名稱或機密進入支援檔 適用哪種遮蔽模式與保留規則?

Chromium 的替代選擇會記住狀態。連線層級失敗的代理可被標記不良,並暫時排到其他項目後面。清單若含 DIRECT,之後要求可能不經代理。CONNECT 拒絕的處理不同,因為它可能是刻意的目的地政策,而非代理不可用。

PAC 失敗尤其要注意。Chromium 記載 PAC 檔不可用時,除非標為強制,否則可默默退回直接連線。ProxySettings 提供 ProxyPacMandatory,正是為了防止這種退回。

WebRTC 與 UDP 需要獨立決策

網頁可使用不同於一般 HTTP、HTTPS 網址要求的 WebRTC 路徑。Chrome 預設 WebRtcIPHandling 政策可使用所有可用介面。disable_non_proxied_udp 模式限制 WebRTC 在公用介面使用 TCP,除非配置的代理支援 UDP。

此政策為設定檔層級,因此與設定檔代理有關,但仍是另一項控制。它可能降低媒體效能,或破壞需要直接 UDP 的流程。明確選擇並測試取捨,不要只因頁面載入成功就宣稱所有流量都受代理限制。

決定失敗時封鎖,還是維持可用

重視可用性的一般瀏覽設定檔,允許直接退回可能合理;但如果授權、隱私或區域測試有效性依賴指定出口,這就不安全。

良好政策會明說預期行為:

  • 必須使用代理: 無法使用選定路徑時停止受影響要求。
  • 核准代理集合: 只嘗試政策等效的具名替代代理。
  • 允許直接退回: 顯示路徑已改變,記錄事件但不含機密。
  • 明確略過: 記錄目的地類別與必須直接存取的理由。

介面應在啟動前與失敗後顯示路徑狀態。悄悄從代理改成直接連線,會將網路錯誤變成完整性錯誤:流程看似成功,卻走錯路。

安全的驗證矩陣

使用自有或獲准檢查的端點與 DNS 區域,執行前先記錄預期結果。

  1. 核對宣告協定與實際端點傳輸。
  2. 確認 HTTP、HTTPS、WebSocket 及必要 WebRTC 行為。
  3. 在受控目的地觀察出口位址。
  4. 觀察哪個解析器接到目的地查詢,哪個解析器處理代理名稱。
  5. 讓測試憑證到期,確認介面、紀錄與自動化輸出無原始值。
  6. 讓測試代理不可達,確認配置的封鎖或替代結果。
  7. 拒絕一個受控 CONNECT 目的地,確認政策拒絕不會變成直接存取。
  8. 讓測試 PAC 不可用,確認強制行為。
  9. 演練流程需要的精確、子網域、本機、鏈路本地、IPv4 與 IPv6 略過案例。
  10. 連線有效時更換代理,驗證新路徑何時生效。
  11. 只擷取測試必要診斷,再驗證保留與刪除。

Chromium 的 NetLog 指引將網路記錄視為隱私與安全議題。遮蔽模式可省略敏感欄位,更詳細模式可能包含 Cookie 或驗證標頭。支援檔應依實際擷取模式處理,不是依檔名。

關於本指南

AI 協助
本文使用 AI 從英文原文翻譯。Isoline 對發布內容負責。目前尚無人工語言審閱紀錄。

來源

來源支持下列主題。查閱日期表示引用資料何時經過確認。

  1. 支持的主題
    代理選擇、協定、DNS 歸屬、略過規則、替代路徑與驗證實作限制。
    查閱日期
  2. Chrome Enterprise ProxySettings 政策 Google Chrome Enterprise
    支持的主題
    設定檔範圍的代理模式、略過配置與強制 PAC 行為。
    查閱日期
  3. 支持的主題
    DNS-over-HTTPS 自動與安全模式,包括替代與失敗行為。
    查閱日期
  4. 支持的主題
    WebRTC 介面政策,以及停用非代理 UDP 的模式與取捨。
    查閱日期
  5. RFC 9110:HTTP 語意 Internet Engineering Task Force
    支持的主題
    HTTP 代理驗證挑戰、CONNECT 通道語意與代理授權欄位。
    查閱日期
  6. RFC 7617:Basic HTTP 驗證方案 Internet Engineering Task Force
    支持的主題
    Basic 驗證編碼,以及敏感憑證需要受保護傳輸的要求。
    查閱日期
  7. RFC 1928:SOCKS 第 5 版協定 Internet Engineering Task Force
    支持的主題
    SOCKS5 網域名稱位址形式,以及協定層級的驗證方法協商。
    查閱日期
  8. 支持的主題
    NetLog 擷取模式、遮蔽邊界,以及診斷檔可能包含的敏感欄位。
    查閱日期
提出更正建議