全隧道 VPN 與程式代理有何不同？裝置涵蓋、DNS 及失效行為

全隧道 VPN 與程式代理的核心分別，是由誰控制流量路徑。全隧道通常更改裝置路由，把 IP 數據包送入虛擬介面；應用程式代理只處理主動使用代理的程式請求。兩個名稱都不能單獨證明每個 DNS 查詢、本機連線或已排除流量實際走哪條路。［1］［2］［3］

完整 VPN 指南介紹加密與路由。本文集中處理涵蓋範圍：哪些流量進入連線、哪些可能留在外面，以及如何以證據核實。

關鍵要點

• 全隧道改變裝置路由政策；應用程式代理改變參與程式的連線方式。
• 路由型隧道可涵蓋背景服務及非瀏覽器程式；代理無法處理客戶端從未交給它的流量。
• DNS、IPv6、UDP、本機網絡及排除規則均須分開驗證。
• 「已連線」只證明工作階段存在，不代表涵蓋完整。
• 應按任務選擇最小而足夠的範圍，再以受控目的地測試。

全隧道 VPN 與程式代理如何進入流量路徑？

全隧道一般建立虛擬網絡介面，並把 IPv4、IPv6 預設路由指向它。Android VpnService 讓 VPN 程式從介面讀取外發 IP 包，經受保護的隧道 socket 傳輸，再把解密後的入站包寫回介面。隧道本身的 socket 必須排除在該路由之外，以免形成循環。［1］

應用程式代理則提供 HTTP、SOCKS 等入口，由瀏覽器或兼容程式決定是否使用。PAC 檔案可因應每個 URL 回傳代理或 DIRECT；這是應用層請求決策，並不會取代作業系統的 IP 路由表。［3］ 因此，網頁代理與 VPN在加密及出口位置之前，流量入口已經不同。

維度	全隧道 VPN	應用程式代理
主要選擇器	裝置路由與隧道政策	應用程式或單次請求設定
處理單位	IP 數據包	受支援的連線或請求
背景服務	路由吻合時通常納入	服務主動使用代理時才納入
UDP	視乎隧道實作是否承載	視乎代理類型及客戶端支援
DNS	可設定為隧道內解析，仍須驗證	可在本機、代理端或應用程式內解析
本機網絡	由明確路由及例外決定	程式不代理時通常直接連線
失效影響	可能波及整部裝置	通常只影響參與程式

整部裝置的路由可涵蓋哪些流量？

路由表按目的地前綴與優先次序選擇介面。強制隧道會設定 VPN 預設路由，也可保留較窄的例外。Microsoft 對強制及分流路由的說明顯示，更具體的路由和名稱解析政策都會改變實際路徑。［2］

這項選擇發生在一般應用程式之下，因此瀏覽器、更新服務、同步程式及指令列工具等，都可能毋須逐一設定便進入隧道。若要求針對整部裝置、背景程序或多種協議，這是路由型方案的主要價值。

不過，「全」是政策目標，不是物理定律。設定可能遺漏 IPv6、容許本機子網、排除某個程式，或在網絡切換後失去優先權。虛擬機器、容器及獨立網絡 namespace 亦可能有自己的路由。應查看實際生效的路由，而非只看模式名稱。

為何 DNS 與本機網絡須分開檢查？

應用程式可使用系統 resolver，也可使用內置加密 DNS。VPN 能下發 DNS 設定，但查詢實際經哪個介面，仍受平台政策、程式行為和路由可達性影響。還須檢查解析結果所建立的連線，不能以一次 DNS 查詢代替完整路徑證明。

打印機、路由器及裝置探索常用私人地址、multicast 或 broadcast。全隧道可容許、封鎖或只部分保留這些流量。能連到本機路由器本身不代表洩漏，關鍵是結果是否符合書面政策與威脅模型。

為何應用程式代理的涵蓋範圍可能較小？

代理只有在程式願意使用時才生效。瀏覽器及受管企業程式通常讀取代理設定；另一程式可能直接建立 socket、使用獨立網絡程式庫、讀取自己的設定，或繼續沿用舊連線。因此，瀏覽器可用而桌面程式不可用並不矛盾。

協議支援亦有限。HTTP 代理處理 HTTP 語義及客戶端支援的 CONNECT；SOCKS 可表示更多連線，但 UDP 與 DNS 仍取決於版本及實作。PAC 只能為 URL 請求作決定，無法截取從未查詢 PAC 的程序所發出的 datagram。［3］

較窄範圍不一定是缺點。若只需一個瀏覽器設定檔、測試工具或受管程式使用獨立出口，代理影響面較小，也能保留本機服務。刻意限制涵蓋與意外繞過應分開描述。

連線失效時會發生甚麼？

全隧道的失效政策可能作用於整部裝置。Fail closed 方案會保留路由或防火牆封鎖，直至保護路徑恢復；fail open 則恢復一般預設路由。若結束時清理不完整，即使 VPN 程序已停止，裝置仍可能沒有可用網絡。

應用程式代理失效時，參與程式通常無法連到代理，或執行明確容許的直連後備；其他程式繼續使用一般路由。PAC 可主動回傳 DIRECT，所以頁面成功開啟並不能證明請求經過代理。［3］

亦要分清認證與數據路徑。代理 TCP 連線可能成功，之後請求或憑證才被拒；VPN 控制工作階段可能顯示在線，但路由、DNS 或數據包不可用。應記錄失效層：設定、可達性、認證、路由、DNS 或程式。

應如何選擇設計？

先確定規則針對的對象。如果政策適用於整部裝置、背景流量、多種協議，或無法單獨設定的程式，路由型隧道通常是合適的基礎。如果需要的只是一個瀏覽器、一項開發工作，或一個明確支援代理的程式，程式代理可能較簡單，干擾也較少。

然後在部署前界定例外。列出必須保持可達的本機服務、絕不能走替代路徑的程式、需要的地址族、DNS 歸屬，以及失效時會發生甚麼。一條帶有未記錄排除項目的寬泛隧道，可能比一個約定精確的窄範圍代理更難令人信任。

最後考慮管理。裝置 VPN 設定檔可能需要提升的權限、受管設定、路由協調和生命週期處理。程式代理則需要逐一程式的兼容性、憑證分發，以及確認「直接連線後備可以接受」。兩種方案都免不了監察伺服器和輪換密鑰。

如何驗證實際涵蓋範圍？

使用一個受控的矩陣，而不是只看一個「我的 IP 是甚麼」頁面。連線前，記錄預設的 IPv4 和 IPv6 路由、resolver 設定，以及瀏覽器和非瀏覽器客戶端各自看到的公網地址。連線後重複這些觀察；只有在獲得授權且受支援時，才加入 UDP 測試。

至少檢查以下路徑：

1. 設定為使用代理或 VPN 的瀏覽器。
2. 不繼承瀏覽器設定的指令列客戶端。
3. 一個由你控制的背景同步或更新服務。
4. IPv4 和 IPv6 目的地（如兩者均已啟用）。
5. 一個你能觀察到權威結果的 DNS 名稱。
6. 一個政策明確容許或封鎖的本機私人地址。
7. 連線程序意外停止後，再檢查同一組路徑。

在容許的範圍內使用端點記錄、本機路由檢查和封包元數據。公網地址改變只證明該次請求使用了不同的出口。本機存取不變只證明被測試的本機路徑仍然可用。把每項觀察對照書面的涵蓋規則。

全隧道與應用程式代理模型能否描述 AethoVPN？

要用 AethoVPN 檢查涵蓋範圍，先在開啟全局模式（所有應用程式的流量都經 VPN 轉送）的狀態下連線，然後在瀏覽器做一次洩漏測試，再開啟一個非瀏覽器應用程式，確認兩者都從所選位置出口；接著關閉全局模式重複一次，看存取你所在地區網站的流量是否改為直連。它的公開頁面只說明了這個開關，沒有介紹按應用程式排除或隧道中斷時的處理政策，所以這些行為應在自己的裝置上觀察，而不是當作功能來規劃。開始 3 天試用，完成這兩輪測試。

總結

• 全隧道主要改變裝置路由，應用程式代理主要改變參與程式的行為。
• 路由捕獲可包含背景及非瀏覽器流量，但仍受地址族、DNS、例外和 namespace 影響。
• 代理涵蓋取決於客戶端支援、代理類型、解析方式及直連後備。
• 隧道失效可能影響整部裝置；代理失效通常局限於參與程式。
• 聲稱涵蓋完整之前，應驗證多條具代表性的流量路徑。

常見問題

全隧道 VPN 會把絕對所有數據包都送入 VPN 嗎？

不一定。排除路由、本機網絡例外、IPv6 缺口、其他 namespace 及程式繞過規則均可改變範圍。「全隧道」必須以生效路由和政策核實。

應用程式代理一定比 VPN 不安全嗎？

不能一概而論。它保護的範圍較窄，可能不符合整機要求，卻適合單一受管程式。安全亦取決於代理協議、認證、傳輸保護及是否容許直連。

應用程式代理能處理 UDP 嗎？

部分代理及客戶端可以，但「代理」名稱不保證 UDP。須核對版本、客戶端、伺服器及 DNS 行為。

為何瀏覽器與其他程式顯示不同 IP？

瀏覽器可能使用代理，其他程式則直接開 socket；IPv4、IPv6、DNS 或程式規則不同亦會造成差異。應以同一目的地和時間比較。

全隧道一定會封鎖本機打印機嗎？

不會。設定可以容許私人子網、封鎖它們或只保留部分探索功能。本機存取是獨立政策選擇。

Kill switch 與全隧道是同一功能嗎？

不是。全隧道描述正常連線的路由範圍，kill switch 描述保護路徑失效後的動作；兩者可以獨立存在。

哪一種較容易排查？

代理範圍通常較小，隧道則有標準介面與路由證據。真正容易排查的方案應有清晰政策、可觀察日誌及可重複失效測試。

免責聲明：本文只提供一般網絡資料。請遵守所管理網絡、裝置及服務的規則。

來源：

1. Android Developers, “VpnService”: https://developer.android.com/reference/android/net/VpnService
2. Microsoft Learn, “VPN routing decisions”: https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/vpn/vpn-routing
3. 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 日。

---

延伸閱讀：

• 理解 VPN 架構與涵蓋範圍
• 分辨網頁代理與 VPN
• 比較 TUN 捕獲與系統代理
• 解釋瀏覽器與桌面程式差異