開啟 3 天免費試用
註冊即可免費體驗全部高級功能。
*只限新用戶；每位用戶只可獲得一次試用。
TUN 模式與系統代理有何不同？直接連線、路由排除與程式範圍
Ryan Foster
2026年9月12日· 7 分鐘讀完
TUN 模式與系統代理分別代表「捕獲數據包」和「由應用程式配合」兩種入口。TUN 接收作業系統路由選中的 IP 包；系統代理只是一項偏好設定，程式可以遵從、覆蓋或忽略。某項流量從未進入選定機制時，程式便會表現為繞過 VPN。［1］［2］［3］
完整 VPN 指南介紹一般隧道模型。本文把入口獨立拆開，避免把瀏覽器成功、程式直連和路由排除誤認為同一故障。
關鍵要點
- TUN 處理被路由的 IP 包；系統代理依賴支援代理的應用程式。
- 直接 socket、內置網絡程式庫、程式獨立設定及不受支援流量都可能繞過系統代理。
- TUN 涵蓋較廣但並非絕對：路由、IPv4/IPv6、程式排除、DNS 及 namespace 仍會限定範圍。
- 公網 IP 檢查應跨程式及地址族重複。
- 應找出失效層，而非一次更換協議、伺服器、DNS 和代理類型。
TUN 模式與系統代理如何進入流量路徑？
TUN 是第三層虛擬介面。作業系統按現行路由政策，把選中的 IP 包交給它。Android 說明 VPN 程式從介面讀取外發包，經受保護隧道 socket 傳送，再把解密後的入站包寫回介面。［1］
系統代理則由軟件讀取。瀏覽器或網絡 framework 可查詢某個 URL 應使用的代理，完成認證並傳送受支援請求。PAC 可回傳代理鏈或 DIRECT，但不會在主機上強制截取每一個 socket。［3］
| 問題 | TUN 模式 | 系統代理 |
|---|---|---|
| 誰選擇流量 | 路由與 VPN 政策 | 支援代理的程式或 framework |
| 入口單位 | 被選中的 IP 包 | 受支援請求或連線 |
| 直接 socket | 通常仍跟隨路由 | 可完全忽略代理 |
| UDP | 隧道實作支援時可承載 | 視乎代理及客戶端 |
| IPv6 | 需要相應路由與實作 | 視乎程式解析及代理路徑 |
| DNS | 可獨立路由或設定 | 可在本機、代理或程式內完成 |
| 排除 | 路由、程式、目的地或平台政策 | PAC DIRECT、繞過清單或程式覆蓋 |
應用程式為何繞過系統代理？
最常見原因是程式根本不讀取系統設定。它可能直接建立 TCP/UDP socket、使用內置 runtime、只讀取環境變數或自己的設定，也可能繼續沿用設定改變前建立的連線。瀏覽器頁面成功不能證明另一程式使用同一入口。
應用程式亦可設定優先權更高的專用代理。企業軟件可能接收受管設定，開發工具讀取自己的檔案，瀏覽器 extension 只影響一個設定檔。因此，extension 與桌面 VPN 顯示不同位置可能正是兩條獨立路徑的結果。
繞過清單也可以是刻意設計。PAC 可為吻合 URL 回傳 DIRECT，桌面代理通常也會排除本機主機名稱或地址範圍。PAC 快取、設定檔優先次序及認證錯誤，會令顯示相同代理地址的程式出現不同結果。［3］
哪些流量最容易顯示差異？
語音、遊戲、裝置探索及即時程式經常使用 UDP，基本 HTTP 代理不會自動承載。部分 SOCKS 實作支援 UDP association，但客戶端與伺服器必須同時支援，DNS 亦可能走另一條路。
非 HTTP 的 TCP 有時可透過 CONNECT，前提是程式主動請求且代理容許該目的地。只使用 raw socket 的程式，不會因系統開關啟用便自動支援代理。這是整合邊界，不代表加密失效。
TUN 模式為何仍可能遺漏流量？
TUN 捕獲由路由決定。若設定只安裝部分前綴，其他目的地仍走一般介面。Microsoft 文件指出，路由具體程度及 metric 會影響 VPN 路徑，強制隧道與分流隧道亦安裝不同的預設路由。［2］
地址族不完整十分常見。IPv4 預設路由進入 TUN，並不會自動涵蓋 IPv6。支援雙棧的服務可能在不同程式或請求間選擇不同路徑，因此須同時核對兩套路由表和實際連線地址。
平台亦可能按程式納入或排除、容許本機網絡，以及為 VPN 本身提供受保護 socket。容器、虛擬機器及獨立網絡 namespace 也可有自己的路由。TUN 應描述為「在聲明環境內作路由層捕獲」，不能寫成無條件截取整機所有數據包。
DNS 可以繞過 TUN 嗎？
可以。resolver 流量可能吻合排除路由，程式可能使用內置加密 DNS，平台亦可能選擇另一介面。相反，DNS 查詢進入隧道也不代表連往解析地址時一定走隧道。
應以受控域名檢查，觀察解析結果，再核對目的連線及路由。一個 resolver 設定或快取答案不足以證明完整路徑。
如何診斷應用程式繞過？
先固定可重複對照：一個看似受保護的程式和一個看似直連的程式，使用同一目的地、時間、網絡及地址族。目的地不同便無法獨立判斷捕獲機制。
檢查系統代理的生效來源、程式覆蓋項、PAC 結果、繞過清單、認證及是否須重啟；檢查 TUN 的介面狀態、路由前綴、metric、程式排除、IPv4/IPv6，以及隧道 socket 是否正確避開回圈。
然後記錄 TCP 或 UDP、目的 IP 與連接埠、DNS 路徑、本機或遠端範圍，以及是否沿用舊連線。瀏覽器可連線而桌面程式不能只有在這些事實清楚後，才適合歸因。
每次只改一個變數：固定地址族、只重啟目標程式、移除一條已授權排除規則，或比較一條直連與一條代理請求。同時更換協議、端點、DNS 和程式設定會失去定位證據。
如何建立可靠測試矩陣？
可以瀏覽器、指令列客戶端、受控背景服務及 UDP 工具作為各行；以系統代理、TUN、斷線狀態、IPv4、IPv6、DNS 結果、出口地址及本機存取作為各欄。不受支援的組合應清楚標示，不應當作故障。
每次測試前後記錄路由、介面身份、代理設定來源、可取得的 PAC 決定和已刪除敏感資料的程式日誌。伺服器日誌可證明請求抵達預期端點；沒有記錄也可能表示問題更早出現在 DNS 或路由。
用政策語言定義通過條件，例如「除獲准更新服務外，所有受管程式均使用隧道」。同時寫明是否容許直連後備、本機服務是否保留，以及重連是否必須中止舊 socket。「VPN 正常」不是可測試條件。
何時使用哪一種方式？
若需求涉及多個程式、不支援代理的軟件、UDP 或裝置層網絡政策，應優先考慮 TUN，並承擔路由、DNS、介面生命週期、MTU 及失效安全管理。若範圍明確限於兼容程式，其他軟件容許直連，而且需要按請求選擇，系統代理較合適。
兩者也可以組合：TUN 捕獲 IP 流，再把合資格的連線轉換到代理 stack。診斷時仍須分層，TUN 決定「甚麼進入」，代理 stack 決定「如何表示及傳輸」。
TUN 與系統代理模型能否描述 AethoVPN？
用 AethoVPN 做受控測試時，開啟全局模式連線，然後分別檢查三項：瀏覽器洩漏測試、DNS 洩漏測試顯示的解析器，以及一個會忽略系統代理設定的命令列工具或 App。三項都從所選位置出口，表示你觀察到全系統涵蓋，但 AethoVPN 的文件沒有說明這是透過 TUN 介面、代理還是兩者結合實現，所以只記錄結果，不要推定機制。開始 3 天免費試用，完成這三項檢查。
總結
- TUN 捕獲被路由的 IP 包；系統代理依賴程式配合。
- 直接 socket、獨立設定、UDP 限制及
DIRECT規則常會造成代理繞過。 - TUN 仍受路由、地址族、排除項、namespace 和 DNS 限制。
- 應在多個程式中比較同一目的地，並每次只改一個變數。
- 測試前先寫明涵蓋及失效規則。
常見問題
TUN 能保證任何應用程式都無法繞過 VPN 嗎？
不能。平台排除、路由缺口、其他 namespace、IPv6、本機路由或特權行為都可能形成不同路徑。保證必須針對實際平台政策驗證。
為何瀏覽器使用代理而遊戲不使用？
瀏覽器支援代理，遊戲可能直接使用 TCP 或 UDP socket。應核對遊戲支援的代理方式及實際流量類型。
系統代理就是分流隧道嗎？
不是。系統代理是一種入口機制，可能造成部分程式代理、部分程式直連的分流結果；分流隧道亦可按程式、路由、目的地或域名選擇。
TUN 與代理可以一起使用嗎？
可以。客戶端可用 TUN 捕獲 IP 包，再轉換到代理 stack。捕獲、代理協議、傳輸、路由及 DNS 仍是不同層。
為何 IPv6 顯示不同公網地址？
設定可能只捕獲 IPv4，程式亦可能以不同方法解析並連到 IPv6。應在同一個雙棧目的地核對兩套路由表。
更改系統代理後須重啟程式嗎？
有時需要。程式可能快取設定、PAC、DNS 或現有連線。重啟是受控診斷步驟，但不證明往後所有流量都會使用代理。
直連後備一定是洩漏嗎？
只有違反書面政策時才是洩漏。排除程式或本機服務可能獲准直連；要求 fail closed 時必須明確禁止並測試後備。
免責聲明：本文只提供一般網絡資料。請遵守所管理網絡、裝置及服務的規則。
來源：
- Android Developers, “VpnService”: https://developer.android.com/reference/android/net/VpnService
- Microsoft Learn, “VPN routing decisions”: https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/vpn/vpn-routing
- MDN Web Docs, “Proxy Auto-Configuration file”: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file
Sources checked 2026 年 9 月 12 日。
延伸閱讀：
