Clash TUN 模式與系統代理差異：流量接管原理與適用情境

先分清流量接管與規則分流

系統代理和 TUN 要解決的是同一個前置問題：應用程式的連線如何進入 Clash 核心。連線進入核心後，才由 mode、rules 和策略組決定直連、代理或拒絕。因此，「啟用 TUN」不等於「所有連線都走代理」；「開啟系統代理」也不代表「整台裝置都已被接管」。

本文的欄位範例以 Clash Meta 後續維護的 mihomo 核心為準。不同圖形介面用戶端可能會產生或覆寫部分設定；舊版 Clash 核心、行動裝置的 VPN 介面與桌面用戶端選項，不能直接視為完全相同。修改前，請先在用戶端的核心資訊或啟動記錄中確認實際執行的核心版本。

例如，在 mode: rule 下，進入 TUN 的連線仍可能符合 DIRECT 規則；經系統代理進入本機 7890 埠的連線，也可能依規則轉送至代理節點。請分開檢查流量的接管入口與出口選擇。

系統代理：應用程式主動連線至本機埠

圖形介面用戶端的「系統代理」通常會修改作業系統的代理設定，讓遵循這項設定的應用程式將請求送至本機監聽埠。以 mixed-port: 7890 為例，應用程式會先連線至 127.0.0.1:7890，再由核心建立後續連線。mixed 埠可接收 HTTP 代理與 SOCKS 代理連線。

HTTPS 經過代理，不代表 HTTPS 內容遭到解密

瀏覽器透過 HTTP 代理瀏覽 HTTPS 網站時，通常會以 CONNECT 建立通道。單純啟用系統代理不會自動解密網站的 TLS 內容，一般代理用途也不需要安裝網站憑證。代理協定使用 HTTP，與目標網站是否採用 HTTPS，是兩個不同層面的事。

系統代理未生效的常見情況

命令列程式：可能只讀取 HTTP_PROXY、HTTPS_PROXY 等環境變數，或需要另外指定代理參數。
遊戲與自訂網路程式：可能直接建立通訊端，不會讀取系統代理設定。
Windows 服務：執行帳戶與網路 API 可能和目前使用者不同。使用者的代理設定不等於所有服務的代理設定。
UDP 流量：啟用 HTTP 代理後，不能據此推斷遊戲 UDP、語音或 QUIC 流量也已經過代理。

系統代理適合用來初步確認訂閱、節點與基本規則。通常不必為了修改目前使用者的代理設定而持續以系統管理員身分執行，影響範圍也較容易判斷。若只有瀏覽器需要代理，不必為了擴大接管範圍而急著啟用 TUN。

TUN：透過虛擬介面接收 IP 封包

TUN 會在系統中建立虛擬網路介面，並搭配路由將符合條件的 IP 封包交給核心。應用程式仍以一般連網方式連線至目標位址，不必自行處理 HTTP 或 SOCKS 代理。mihomo 接收封包後會處理連線，再依規則選擇出口。

auto-route: true 用來自動設定相關路由；auto-detect-interface: true 用來自動偵測出口介面。這些設定無法取代所需權限，也不能保證與其他 VPN 的路由完全相容。連上公司 VPN、切換 Wi-Fi 或新增有線網卡後，出口介面與路由優先順序都可能改變。

比較項目	系統代理	TUN
進入核心的方式	應用程式連線至本機代理埠	透過路由將 IP 封包送入虛擬介面
是否需要應用程式配合	需要讀取代理設定或明確指定代理	通常不需要應用程式理解代理協定
UDP 接管	一般 HTTP 系統代理不能據此涵蓋 UDP	可接管路由範圍內的 UDP，但出口仍須支援
系統權限	通常可修改目前使用者的設定	通常需要提升權限、服務模式或平台授權
主要排查項目	埠號、應用程式設定、環境變數	虛擬介面、路由、DNS、出口介面

TUN 不會讓不支援 UDP 的節點突然具備 UDP 能力，也不代表任意 IP 協定都能透過遠端代理轉送。尤其不要只憑一次 ping 成功或失敗，就判斷 TCP 網站連線是否正常；ICMP 與實際應用連線的處理路徑可能不同。

DNS：解析路徑會影響規則比對

使用系統代理時，網域由誰解析取決於應用程式與代理協定。HTTP 代理可接收以網域表示的目標；SOCKS5 則可接收網域，也可接收應用程式已解析的 IP。終端機中的 socks5:// 與 socks5h:// 可能採用不同的解析路徑，因此不能只看出口 IP 是否改變。

TUN 接收到的通常是 IP 封包。若要讓網域規則穩定運作，核心需要搭配 DNS 對應資料、既有中繼資料，或視需要使用流量嗅探。只開啟虛擬介面卻不檢查 DNS，可能會遇到網站能連線、網域規則卻未如預期比對的情況。

fake-ip 與 DNS 劫持各自負責什麼

enhanced-mode: fake-ip：對適用的 DNS 查詢回傳對應位址，核心再將該位址關聯回網域。範例中的 198.18.0.1/16 用於這項對應，並非網站實際的出口位址。
dns-hijack：將符合條件的 DNS 流量交由核心 DNS 處理。常見設定會涵蓋 UDP 53 與 TCP 53。
nameserver：指定核心實際使用的上游解析器。是否加密、能否連線及分流策略，都需要另外評估。

IPv6 也要另外測試。只調整 IPv4 路由，不能據此認定 IPv6 也已依相同策略接管。企業內網網域、印表機名稱與區域網路服務若仰賴本機 DNS，應保留相應的解析路徑；不要把所有解析異常都歸咎於節點無法使用。

mihomo 設定：從最小幅度的修改開始

以下是用來說明欄位的設定片段，並非完整訂閱內容。請將它合併至現有設定的對應位置，並保留原有的 proxies、proxy-groups 與 rules。同一層級不要重複宣告兩個 dns 或兩個 tun；若用戶端提供覆寫功能，請使用可持續保存的覆寫入口，以免訂閱更新後修改內容消失。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - "any:53"
    - "tcp://any:53"

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

127.0.0.1:1053 是此處明確開啟的本機 DNS 監聽位址，不代表作業系統會自動向這個埠發出查詢。TUN 的 DNS 劫持則是另一條進入核心 DNS 的路徑。範例上游採用傳統 DNS，目的是讓欄位關係更清楚；實際部署時，應依網路環境與隱私需求選擇上游，不要將這兩個位址視為通用的最佳設定。

stack 該選 system、gvisor 還是 mixed？

system：使用系統協定堆疊處理連線，須依目前的系統與核心實作確認相容性。
gvisor：使用使用者空間協定堆疊，可作為排查特定相容性問題的對照方案。
mixed：在 mihomo 中組合使用協定堆疊；TCP 使用 system 路徑，UDP 使用 gVisor 路徑。

不要把某種 stack 當成適用所有裝置的速度排名。測試時維持相同節點、目標與規則，只變更 stack，重新啟動核心並確認舊連線已結束，再比較連線成功率與實際使用情況。若目前的用戶端或核心不支援某個值，請先還原預設值，不要反覆套用其他版本的設定。

權限與搭配方式：先分別驗證，再決定是否同時使用

在 Windows 上，建立虛擬網卡與設定路由通常需要系統管理員權限，部分用戶端會透過服務模式執行這些操作。macOS 與 Linux 也需要相應的提權或服務權限；Linux 另外涉及 TUN 裝置與網路管理權限。圖形介面顯示 TUN 已開啟，只能表示操作已送出；仍應查看啟動記錄，確認是否有權限不足、介面建立失敗或新增路由失敗等問題。

依使用範圍選擇接管方式

瀏覽器與一般桌面應用程式：先只開啟系統代理，確認節點、規則與本機埠運作正常。
終端機工具：優先使用明確指定代理的參數進行測試，再決定是否設定環境變數。設定暫時變數比修改全域設定更容易還原。
不讀取代理設定的程式：關閉系統代理後單獨測試 TUN，避免兩個入口同時變動而難以找出問題。
確實需要多個入口：驗證無誤後可同時開啟。應用程式明確指定本機代理時會走該入口，其他符合路由條件的流量則可由 TUN 接管。

同時開啟不一定代表重複代理，也不會自動改善網路品質。正常情況下，核心需要讓自己的出站連線避開 TUN 接管，以免形成迴圈。手動路由、其他 VPN 或錯誤的出口介面可能破壞這項前提；因此同時使用後若發生異常，請先退回只使用單一入口的設定。

系統代理開關也可能保留「略過本機位址」等規則；TUN 的私有網路路由則屬於另一個設定層面。若需要連線至 NAS、區域網路印表機或公司內網，請分別檢查系統代理略過清單、路由與 mihomo 規則，不要假設兩者的例外範圍相同。

驗證與排除問題：確認連線實際走哪條路徑

使用同一個目標進行比對，先確認本機代理埠可用，再判斷系統接管是否生效。以下命令僅供測試，不代表已有實測結果。在 Windows 上建議明確使用 curl.exe，避免部分 PowerShell 環境中的同名別名影響參數。

第一步：明確指定代理，排除系統接管的影響

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/
curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

即使關閉系統代理，這時命令仍會嘗試連線至指定的本機埠。若連線遭拒，請先確認核心是否已啟動，以及實際監聽埠是否為 7890。若已連上核心但仍無法存取，接著檢查記錄中的解析、規則、節點交握與遠端連線錯誤。

第二步：取消明確指定的代理，測試 TUN 路徑

curl --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com/

--noproxy "*" 會讓這次 curl 請求不使用應用程式層的代理設定，但不會略過作業系統的 TUN 路由。關閉系統代理並開啟 TUN 後執行此命令，同時在用戶端的連線頁面檢查目標、符合的規則與策略。僅憑命令執行成功，仍不足以證明流量使用了代理節點，因為規則可能選擇 DIRECT。

第三步：依照現象縮小排查範圍

明確指定代理後成功，TUN 失敗：先檢查權限、虛擬介面與路由；Windows 可用 route print，Linux 可用 ip route 檢查路由表。
瀏覽器可用，終端機失敗：檢查終端機環境變數及工具本身的代理選項，不要直接判定是節點故障。
網域連線失敗，但已知 IP 可連線：優先檢查 DNS，並使用適合的測試服務；直接將 HTTPS 網域替換成 IP 會造成憑證與 SNI 差異。
TCP 正常，但語音或遊戲異常：檢查 UDP 接管、節點的 UDP 支援能力與服務端限制，不要只切換規則模式。
啟用另一套 VPN 後發生異常：暫時關閉其中一套，比對預設路由、DNS 與出口介面，再設定兩者的共存範圍。

每次只變更一個變數，並記錄「入口、DNS、符合的規則、實際策略、錯誤記錄」五項資訊。需要還原時，先關閉 TUN 並還原原設定，再確認系統代理位址；結束用戶端前，請清除仍指向 127.0.0.1:7890 的代理設定，避免本機監聽停止後，應用程式仍連線至舊埠。

首次設定可從入門教學開始；需要確認規則與設定結構時，請參閱完整文件。