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

系統代理與 TUN：差異在於流量進入核心之前

要判斷該開啟哪個選項，先釐清兩件事：應用程式的連線是否進入 Clash 核心，以及進入後要依哪些規則處理。系統代理與 TUN 主要解決第一個問題；規則模式、全域模式與策略組選擇，則主要決定第二個問題。開啟 TUN 不代表所有連線都會經過代理節點；開啟系統代理也不代表所有應用程式都會採用這項設定。

本文主要以桌面用戶端搭配 Clash Meta 後續發展的 mihomo 核心為例。不同用戶端的選項名稱、權限要求與設定合併方式可能不同；舊版 Clash 核心也未必支援相同的 TUN 欄位。建議先在用戶端的核心資訊中確認實際執行的核心，再核對設定；只看用戶端名稱並不可靠。

系統代理：應用程式主動將連線交給本機連接埠

開啟系統代理後，用戶端通常會將作業系統的代理位址設為本機監聽位址，例如 127.0.0.1:7890。採用這項設定的瀏覽器或桌面應用程式會連至該位址，由核心接收 HTTP 代理請求或 HTTPS CONNECT 隧道請求，再依規則決定直接連線或透過節點轉送。

關鍵在於「應用程式是否採用這項設定」。Windows 的使用者代理設定與 WinHTTP 設定並不相同；背景服務、部分更新程式和命令列工具可能使用另一套設定。Linux 桌面環境中的代理選項也不是所有程式都會採用的強制入口。因此，瀏覽器能連線，並不足以證明終端機、遊戲和背景處理程序都已納入接管。

TUN 模式：透過虛擬網卡與路由接收 IP 流量

TUN 提供虛擬的第三層網路介面。用戶端或核心建立介面並設定路由後，符合路由條件的 IP 封包便會進入 TUN，再由核心處理連線。應用程式通常不必知道本機代理連接埠，也不必支援 HTTP 代理設定。這就是 TUN 能涵蓋更多命令列程式、遊戲與 UDP 應用程式的原因。

不過，「涵蓋更多」不代表無條件接管所有流量。路由排除、綁定特定介面的連線、IPv6 設定、其他 VPN，以及區域網路流量都可能影響結果。TUN 也不是乙太網路橋接器，不能因此推論廣播探索或所有鏈路層協定都能透過代理節點傳輸。

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

常見使用情境與接管條件
情境	系統代理	TUN 模式
瀏覽器網頁	瀏覽器採用系統設定時，通常就足夠。	可接管路由涵蓋的連線；需留意 DNS 與 QUIC。
curl、Git 等命令列工具	不能假設會自動生效，可明確指定代理位址。	通常不必逐一設定代理，但要檢查路由與執行環境。
遊戲與語音通話	許多程式不會採用 HTTP 系統代理，涵蓋範圍有限。	可處理進入 TUN 的 TCP、UDP；節點也必須具備相應能力。
容器、虛擬機器、WSL	通常需要在各自的環境內設定代理。	取決於虛擬網路拓撲；主機端的選項無法保證涵蓋全部流量。
區域網路存取	可透過系統代理的例外清單略過代理。	需一併檢查路由排除設定與核心的直連規則。

能否使用 UDP，不能只看 TUN 選項

一般 HTTP 系統代理無法讓任意應用程式的 UDP 自動透過節點傳輸。SOCKS5 協定雖然支援 UDP 轉送，但應用程式與本機入口都必須支援並採用這項功能；只在系統中填入 HTTP 代理位址，不會自動建立這條傳輸路徑。

TUN 能將符合路由條件的 UDP 封包交給核心處理，但後續傳輸仍受出站協定、節點設定、遠端服務與防火牆限制。即使設定了 udp: true，也無法讓原本不支援 UDP 的出站鏈路憑空具備這項能力。若遊戲能登入但語音失效，應分別檢查語音連線，而不是只測試網頁。

依情境選擇：先用系統代理，再補足未涵蓋的應用程式

瀏覽網頁與一般桌面應用程式：優先使用系統代理

如果主要需求是瀏覽網頁，而且瀏覽器會採用系統代理設定，可以先關閉 TUN，只開啟系統代理與規則模式。這樣影響範圍較小，遇到問題時也較容易分辨是本機連接埠、規則還是節點故障。Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」確認代理伺服器；macOS 可前往「系統設定」→「網路」→目前使用的網路連線→「詳細資訊」→「代理伺服器」檢查，實際項目名稱可能因系統版本而略有不同。

本機位址通常是 127.0.0.1，連接埠則應以用戶端的實際設定為準。本文以 7890 為例，並非所有用戶端都固定使用這個預設值。如果用戶端監聽的是其他連接埠，系統代理、終端機環境變數與應用程式內的手動代理設定也要一併更新。

終端機與開發工具：明確指定代理，方便控制適用範圍

如果只想讓單次下載透過代理，不必立刻接管整台裝置，可以只為該命令指定入口。以下命令用來驗證本機 HTTP 代理入口能否建立 HTTPS 隧道；在 Windows PowerShell 中請寫成 curl.exe，避免舊環境中同名別名造成干擾。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

這只能證明該請求使用了指定的代理入口，不能證明遊戲或其他終端工作也已納入接管。如果使用 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 等環境變數，還要確認工具是否支援相應變數，以及 NO_PROXY 是否排除了目標位址。變數名稱中的 HTTPS 通常表示目標請求類型，不代表本機代理位址必須使用 https://。

遊戲、語音或不支援代理的應用程式：再考慮 TUN

當應用程式不會採用系統代理，也沒有可用的代理設定時，TUN 更適合用來擴大接管範圍。啟用前，先確認用戶端具備建立虛擬網卡與調整路由所需的權限；Windows 上可能透過服務模式或提升權限完成，macOS、Linux 上則視用戶端的輔助程式與權限設計而定。不應簡單認定所有平台都必須長期以系統管理員身分執行整個介面。

兩種入口可以同時啟用，但初次排查時建議分開測試。系統代理開啟時，瀏覽器可能仍透過本機連接埠運作，即使 TUN 未成功接管，也會呈現「網頁正常」的狀況。若要驗證 TUN，請先暫時關閉系統代理，並清除測試程式本身的代理設定，再查看連線記錄。

mihomo TUN 設定：路由、DNS 與規則各自負責不同環節

以下是協助理解欄位的局部範例，適用於支援這些欄位的 mihomo 核心，並非可獨立執行的完整訂閱設定。用戶端可能會透過介面選項產生或覆寫同名欄位；修改前請先備份設定，修改後再檢查最終生效的設定，避免訂閱更新覆蓋手動變更。

mixed-port: 7890
mode: rule

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

mixed-port：在同一個監聽連接埠提供 HTTP 與 SOCKS 入口。這是供明確指定的代理連線使用，並非 TUN 虛擬網卡的連接埠。
stack: mixed：選用核心支援的 TUN 協定堆疊實作。這與規則模式中的「全域」無關；可用值及各平台的實際表現，請以目前核心的文件為準。
auto-route：要求自動設定 TUN 路由。介面建立成功，不代表路由一定已正確安裝；仍須搭配記錄與系統路由表判斷。
auto-detect-interface：嘗試辨識出站網路介面。在多張網卡、使用其他 VPN 或特殊虛擬網路環境中，自動選擇的結果可能不符合預期。
dns-hijack：將進入相應接管路徑的指定 DNS 流量交由核心 DNS 處理。範例涵蓋常見的 UDP 53 與 TCP 53，但不代表會攔截所有網域名稱解析。

DNS 仍需另外設定

上述片段未提供完整的 dns 設定。實際使用時，還要確認核心 DNS 已啟用、上游解析器可連線，以及 fake-ip 或 redir-host 等解析模式與現有設定相容。fake-ip 常用的位址範圍為 198.18.0.0/16；回傳的是用於連線對應的位址，不應誤認為目標網站的真實伺服器位址。

瀏覽器的安全 DNS、應用程式內的 DoH 與 DoT，不會只因監聽了 53 連接埠就自動按一般 DNS 查詢處理。若網域規則未命中或解析結果異常，請先確認解析實際發生的位置，再決定是否調整瀏覽器設定或核心 DNS 規則；不要反覆更換節點來掩蓋解析問題。

規則依然決定直連或代理

流量進入核心後，在規則模式下仍會依設定比對策略。網域規則、IP 規則與最後的 MATCH 備援規則共同決定出站方向；TUN 不會略過這套邏輯。網域能否用於比對，也會受到 DNS 對應與流量探測等機制影響，不能假設每個只有目標 IP 的連線都能還原出原始網域。

區域網路印表機、NAS 和公司內網通常需要保留直連路徑。例如存取 192.168.1.10 時，應確認該位址是否已正確排除或命中直連規則。如果某條自動路由讓封包根本沒有進入核心，調整核心內的規則也不會改變該連線；必須先找出問題所在的層級。

逐步驗證：區分入口故障、分流錯誤與節點問題

記錄基準狀態。記下本機連接埠、執行中的核心、目前的策略組與目標網域。先用瀏覽器連線至固定目標；每次測試時不要同時更換節點、DNS 和接管模式。
只測試系統代理。關閉 TUN、開啟系統代理，並使用前述的明確代理命令再次確認。如果明確指定代理的命令可正常運作，但瀏覽器連線失敗，請優先檢查瀏覽器獨立代理設定、系統例外清單與擴充功能設定。
只測試 TUN。關閉系統代理，移除測試程式中的代理設定，啟用 TUN 後建立新連線。查看記錄中是否出現目標、網路類型、命中的規則與出站策略。
檢查路由與解析。Windows 可查看 route print，Linux 可查看 ip route 與 ip rule，macOS 可查看 netstat -rn。不要只憑虛擬網卡圖示判斷是否成功接管。
個別驗證 UDP。使用實際遊戲或語音功能建立連線，並在用戶端的連線清單中尋找對應的 UDP 工作階段。網頁測試與 ICMP ping 結果，都不能取代代理鏈路的 UDP 測試。

若要排除明確設定的代理變數，可使用以下命令。但請注意：--noproxy "*" 只會讓 curl 略過其明確代理路徑；如果 TUN 已啟用，該連線仍可能經由系統路由送進核心，不能稱為「確保直連」的命令。

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

也應先關閉舊連線，再重新測試。瀏覽器連線池、遊戲長連線與 DNS 快取都可能保留切換前的狀態。切換選項後既有連線仍可傳輸，不代表新建立的連線也會走相同路徑。

常見問題：權限、VPN 共存與退出後的網路復原

開啟 TUN 後，為什麼整台裝置反而無法上網？

先關閉 TUN，恢復基準狀態，再分別檢查核心記錄、DNS 上游與路由。虛擬介面雖已建立，但核心無法正常處理流量，或路由指向錯誤的出站介面，都可能造成連線中斷。如果只有網域存取失敗，而已知 IP 位址的連線有回應，應優先排查 DNS；這只是排查線索，並非適用於所有服務的通用連線測試。

TUN 可以和公司的 VPN 同時啟用嗎？

這取決於兩者的路由、DNS 與安全策略，無法保證能共存。若兩個程式都改寫預設路由，可能互相覆蓋或形成異常路徑。請先分別確認兩者都能正常運作，再查看公司內網網段、預設路由與 DNS 是否遭到變更；使用受組織管理的裝置時，請遵循既定網路策略，不要任意刪除路由或調整安全設定。

退出用戶端後，為什麼瀏覽器仍顯示代理連線失敗？

系統代理可能仍指向已關閉的 127.0.0.1:7890。請先在系統代理設定中確認是否還留有這個位址，並檢查瀏覽器是否另外設定了代理。如果問題出在 TUN，請優先重新啟動用戶端並正常關閉 TUN，讓用戶端清除路由；不建議在不了解網路拓撲的情況下，大量刪除虛擬網卡與系統路由。

TUN 模式一定比系統代理快嗎？

不一定。兩者首先是接管範圍不同，實際速度仍會受到節點頻寬、路徑壅塞、封包遺失、DNS、MTU 與裝置處理能力影響。只有在目標、節點、時段與傳輸類型盡量一致時，比較才有意義。TUN 讓原本未進入核心的應用程式取得代理路徑，這是涵蓋範圍的變化，不能直接解讀為同一條鏈路變快了。

實際選擇可以很簡單：瀏覽網頁優先用系統代理，少量命令列工作優先明確設定代理；需要涵蓋不支援代理的應用程式或 UDP 情境時，再啟用 TUN。每次只調整一個環節，透過連線記錄確認入口與規則，再判斷節點品質，通常比一次開啟所有選項更容易找出原因。