進階設定 閱讀時間約 10 分鐘

TUN 虛擬網卡與系統代理比較：流量接管範圍、權限與相容性

系統代理仰賴應用程式遵循設定；TUN 則在網路層接管流量。本文比較兩者的涵蓋範圍、權限需求與相容性，並提供選擇建議。

一、先分清流量接管與代理分流

系統代理和 TUN 解決的是同一個前置問題：應用程式建立的連線如何進入 Clash 核心。連線進入核心後，才由規則、策略組和節點決定要直連、代理或拒絕。因此，啟用 TUN 不代表啟用全域代理；系統代理也不代表只能使用規則模式。

本文以 Clash Meta（mihomo）核心為例說明 TUN 設定。不同用戶端提供的開關、服務安裝方式和預設連接埠各不相同；舊版 Clash 用戶端也不一定支援下文提到的所有欄位。操作前，請先在用戶端的核心資訊中確認實際執行的是 mihomo，而非只看應用程式名稱是否含有 Clash。

兩種常見的連線路徑

  • 系統代理：瀏覽器讀取系統代理設定，將連線送至本機 HTTP 代理連接埠，再由核心進行分流。
  • TUN：應用程式照常發起 IP 連線，由作業系統路由將符合條件的封包送進虛擬網卡，再交由核心處理。
  • 應用程式內的代理設定：在 Git、命令列工具或聊天軟體中個別填入 SOCKS5 或 HTTP 位址。這是第三種連線入口，不必依賴系統代理開關。

二、涵蓋範圍比較：瀏覽器、命令列與 UDP

系統代理本質上是一組供應用程式讀取的設定，並非網路層攔截器。Windows 的不同網路 API、應用程式自有的網路函式庫，以及 macOS 應用程式對代理設定的支援程度都可能不同。瀏覽器能使用代理，只能證明該瀏覽器的連線可用，不代表同一台裝置上的所有應用程式都已接入。

兩種連線入口常見的適用範圍
使用對象 系統代理 TUN 模式
遵循系統設定的瀏覽器 通常可接入，適合瀏覽網頁 通常可接入，仍受路由與規則影響
curl、Git 與建置工具 不一定會讀取設定，通常需要環境變數或應用程式設定 通常不必逐一設定代理位址
遊戲、語音與 QUIC HTTP 系統代理通常不會代理這些應用程式的 UDP 連線 可接管受支援的 UDP 流量，但節點與連線路徑也必須支援
區域網路印表機、NAS 取決於代理略過清單和應用程式行為 需確認本機路由、直連規則和位址排除設定
其他裝置的流量 只設定本機代理，不會自動涵蓋其他裝置 只在本機啟用 TUN，也不會自動成為區域網路閘道

UDP 支援須檢查整條連線路徑

HTTP 代理連接埠不是通用的 UDP 通道。SOCKS5 雖然定義了 UDP 轉送，但應用程式是否實作、用戶端是否支援，以及出口節點是否具備相應能力，都是不同條件。TUN 能將更多 UDP 流量送進核心，但無法讓不支援 UDP 的節點因此支援 UDP。

例如，HTTP/3 通常使用 UDP 443；網頁能透過 TCP 開啟，不代表 QUIC 連線也正常。若遊戲可以登入但語音無法使用，應分別檢查登入和語音連線的目標位址、通訊協定與策略，不要只看單一延遲測試數值。

三、權限與設定：代理連接埠與虛擬網卡

系統代理：先確認本機監聽位址

以下以 127.0.0.1:7890 作為明確的連線入口範例，不代表所有用戶端都預設使用這個連接埠。mihomo 的 mixed-port 可在同一個連接埠接受 HTTP 與 SOCKS 請求。實際值請以用戶端顯示的混合連接埠或目前生效的設定為準。

# mihomo 設定片段：本機混合代理入口
mixed-port: 7890
allow-lan: false
mode: rule

Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」→「手動設定 Proxy」，確認位址和連接埠；用戶端也可能透過自動設定指令碼設定系統代理，因此不能只看手動代理欄位。macOS 可前往「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「代理伺服器」檢查。顯示的連線入口必須與用戶端的監聽連接埠一致。

在本機使用時，建議維持回環位址。不要只因瀏覽器無法連線，就直接將監聽位址改成所有網路介面。要對區域網路開放代理，還需另行設定存取控制並配合防火牆。

TUN：路由設定與背景服務權限

TUN 必須建立虛擬網路介面並調整路由，桌面用戶端通常會透過系統管理員權限或特權服務完成。Windows 用戶端可能需要先安裝服務模式；macOS 用戶端則可能使用特權輔助程式或網路延伸功能，授權方式視實作而定。並非所有 macOS Clash 用戶端都會要求相同的網路延伸權限。

# mihomo TUN 設定片段，並非完整訂閱
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
  • stack: mixed 在目前的 mihomo 實作中會結合系統 TCP 堆疊與 gVisor UDP 堆疊；可用值與相容性請依所使用的核心版本確認。
  • auto-route: true 會自動設定相應路由。成功建立網卡，不代表路由一定已安裝完成。
  • auto-detect-interface: true 用於自動偵測出口介面。Wi-Fi、有線網路和其他 VPN 同時使用時，仍需確認實際出口。
  • dns-hijack 是 tun 底下的欄位，範例分別比對 UDP 和 TCP 的 53 連接埠請求，並交由內建 DNS 模組處理。

四、DNS 與 IPv6：TUN 啟用後仍可能漏接的原因

流量接管和網域名稱解析都必須一併檢查。應用程式會先查詢網域名稱，再建立連線；如果 DNS 請求走了另一條路徑，可能導致解析失敗、規則無法取得網域資訊，或連線目標與預期不同。只看到虛擬網卡名稱，無法證明 DNS 連線路徑正確。

劫持 53 連接埠不涵蓋所有 DNS 流量

上述 dns-hijack 範例適用於傳統 DNS。瀏覽器的 DNS over HTTPS 會使用 HTTPS 連線；DNS over TLS 通常使用 TCP 853。設定 53 連接埠劫持後，這些流量不會自動變成由核心處理的 DNS 查詢。疑難排解時，可暫時關閉瀏覽器的安全 DNS，在相同條件下再測試一次，然後再決定長期設定。

這段 TUN 範例還需要搭配已啟用的 mihomo DNS 模組，例如 dns.enable: true，並保留可用的上游解析伺服器。fake-ip 與 redir-host 是 DNS 解析模式，不能取代 TUN；使用 Fake-IP 時，仍須依實際應用程式的相容性設定過濾清單。

IPv6 需另外驗證

如果網路同時提供 IPv4 和 IPv6，而目前用戶端只正確接管其中一種，應用程式可能會優先使用另一種位址。疑難排解時，請分別測試兩種 IP 位址類型，確認核心的 IPv6 設定、DNS 的 AAAA 回應，以及系統路由。不要只依據一次 IPv4 測試，就判定所有連線都經過 TUN。

五、驗證方式：一次只切換一種連線入口

建議依序檢查「明確指定代理 → 系統代理 → TUN」。測試時固定使用同一個策略組和節點，並關閉其他代理或 VPN；切換連線入口後重新建立連線，避免瀏覽器重複使用既有連線而影響結果。以下命令使用公開範例網站，僅用於說明測試方法，回應時間並非本文的實測結果。

  1. 確認連接埠可用。關閉 TUN，以命令明確指定本機代理。如果這一步失敗，請先檢查核心、連接埠或節點，不要急著調整虛擬網卡。
  2. 確認系統代理。啟用系統代理，使用遵循系統設定的瀏覽器前往同一個目標，並在用戶端的連線清單中確認目標網域、符合的規則和策略鏈。
  3. 確認 TUN。關閉系統代理，只保留 TUN。讓命令列工具不使用應用程式層級的代理連線至目標，並檢查連線記錄；必要時也確認系統路由。
  4. 確認實際使用情境。接著測試遊戲、語音、區域網路存取等需求。網頁能正常開啟，不能取代 UDP 或本機資源的驗證。
# Windows PowerShell：使用 curl.exe，避免舊版 PowerShell 將 curl 當作別名
curl.exe -I --connect-timeout 10 --proxy http://127.0.0.1:7890 https://example.com/

# TUN 對照測試：不使用 curl 的代理設定
curl.exe -I --connect-timeout 10 --noproxy "*" https://example.com/

# 分別測試 IPv4 與 IPv6
curl.exe -4 -I --connect-timeout 10 --noproxy "*" https://example.com/
curl.exe -6 -I --connect-timeout 10 --noproxy "*" https://example.com/

macOS 和 Linux 可將命令中的 curl.exe 改為 curl。--noproxy "*" 只會讓 curl 不使用應用程式層級的代理，不會略過 TUN。收到 HTTP 回應只代表該請求有收到回應；是否經過代理節點，還需查看核心連線記錄或確認出口位址。

Windows 可用 route print 查看路由；macOS 可用 route -n get 1.1.1.1 檢查指定 IPv4 目標的路由；Linux 可用 ip route get 1.1.1.1 查看路由選擇。不同系統可能採用介面路由或策略路由，不能一概以「必須出現某條預設路由」作為判斷標準。

六、相容性與取捨：選擇最小範圍的流量接管方式

適合優先使用系統代理的情況

  • 主要使用瀏覽器，其他應用程式希望維持原本的網路路徑。
  • 工作裝置已連接企業 VPN，不適合再自動調整整台裝置的路由。
  • 只需讓少數開發工具使用代理，可直接在工具中設定 HTTP 或 SOCKS5 入口。

適合考慮使用 TUN 的情況

  • 目標應用程式不會讀取系統代理，也沒有個別的代理設定。
  • 需要接管受支援的 UDP 流量，而且已確認節點具備相應能力。
  • 希望多個應用程式統一進入核心，再依網域、IP 或處理程序等規則分流。

TUN 與其他 VPN 同時使用時，容易發生預設路由、DNS、網段重疊和回程路徑衝突。例如，企業網路也使用私有位址時，直接新增「所有私有網路直連」規則，可能會繞過企業 VPN 所需的路由。請先記錄企業網路使用的目標網段，再依用戶端支援的路由排除和規則功能進行設定，不要把通用的私有網路規則當成完整解決方案。

兩種連線入口可以同時啟用，但不建議在疑難排解期間這麼做。應用程式明確連線至本機代理時，可能直接走回環入口；其他應用程式才走 TUN。這會讓「關閉一個開關後仍能連線」的結果難以判斷。保留一個主要入口，更容易確認問題出在權限、DNS、連接埠還是規則。

後續設定可參閱系統指南確認各平台差異，或依照使用說明匯入訂閱並設定規則模式。最終應以目標應用程式的實際連線記錄為準，而不是用戶端介面上單一的「已啟用」狀態。

下載 Clash選擇裝置平台