先說結論：差別在流量入口，不在是否「全域」

只需要讓瀏覽器及遵循系統代理設定的應用程式走代理，先使用系統代理；若要接管不會讀取代理設定的命令列工具、遊戲或其他 UDP 流量，再考慮啟用 TUN。兩者決定的是流量如何進入 Clash 核心；Rule、Global、Direct 則決定流量進入核心後如何選路，這兩組概念不能混為一談。

啟用 TUN 後，符合 DIRECT 規則的連線仍會直連；啟用系統代理後，即使選擇 Global，也不代表所有處理程序都會自動讀取代理設定。若遇到「全域模式已開，遊戲怎麼還是沒變」，應先確認遊戲連線是否進入核心，而不是一再更換節點。

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

連線流程與本機連接埠

系統代理通常會將 HTTP、HTTPS 等代理位址寫入作業系統設定。會讀取這些設定的應用程式，會先連線至本機代理連接埠，再由核心依據目標位址與規則建立後續連線。以本機混合連接埠 127.0.0.1:7890 為例，流程如下：

遵循系統代理設定的應用程式
  → 127.0.0.1:7890（HTTP / SOCKS 混合入口）
  → 核心規則與策略組
  → DIRECT 或選取的代理節點
  → 目標服務

這裡的 7890 只是範例，並非每個用戶端都使用這個連接埠。請在用戶端設定或目前生效的設定檔中確認 mixed-port、port、socks-port。HTTP 入口不能任意當作 SOCKS 入口使用；只有混合連接埠會同時接受這兩種代理協定。

HTTPS、UDP 與瀏覽器擴充功能的限制

  • HTTPS：應用程式通常會透過 HTTP CONNECT 建立通往目標的通道。一般代理轉送不代表核心解密了網頁的 TLS 內容，也不需要為了正常使用代理而安裝根憑證。
  • UDP：作業系統的 HTTP 代理設定不是通用的 UDP 轉送入口。SOCKS5 雖支援 UDP ASSOCIATE，但應用程式必須自行實作，代理端與節點也必須支援。
  • 瀏覽器：瀏覽器擴充功能、PAC 與瀏覽器自身的策略都可能覆寫系統設定。網頁可以開啟，不代表所有連線都經過相同入口；QUIC 等傳輸方式也取決於瀏覽器的實作與策略。
  • 終端機：許多命令列程式會讀取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY，或只接受程式本身的代理參數，不會自動遵循桌面系統代理設定。

在 Windows 11 中，可前往「設定」→「網路和網際網路」→「Proxy」檢查系統代理；在 macOS 中，可前往「系統設定」→「網路」→目前的網路服務→「詳細資訊」→「Proxy」檢查。這只能確認設定已寫入，無法證明某個應用程式確實採用了這些設定。

TUN：透過虛擬網卡接收 IP 封包

TUN 在網路層提供虛擬介面。用戶端或核心會設定路由，讓符合條件的 IP 封包進入該介面；核心中的協定堆疊會處理 TCP、UDP，再交由規則與對外連線處理。應用程式不必特別支援 HTTP 或 SOCKS 代理，因此涵蓋範圍通常比系統代理更廣。

應用程式送出的 IP 封包
  → 作業系統選擇路由
  → TUN 虛擬介面
  → 核心協定堆疊、DNS 對應與規則比對
  → DIRECT 或代理節點
  → 由實體網卡送出最終連線

這也說明了 TUN 為何需要較高權限：建立虛擬介面、修改路由及設定 DNS 劫持，通常都需要管理員權限、系統服務，或 Linux 上相應的網路權限。這不只是把代理位址換成另一組連接埠。

TUN 不代表所有網路環境都已涵蓋

自動路由可能設有排除項目，也可能被其他 VPN 的路由取代。區域網路、特定介面、IPv6、虛擬機器與容器都需要個別確認。尤其是 WSL2、Docker 與虛擬機器，流量可能先經過獨立的網路環境或虛擬交換器；主機已啟用 TUN，不代表這些環境的 DNS 與路由也已正確設定。

涵蓋範圍比較：瀏覽器、命令列、遊戲與區域網路

使用情境 系統代理 TUN
瀏覽器 HTTP / HTTPS 通常可用，但需留意擴充功能與 PAC 覆寫設定 路由接管後可進入核心，仍依規則分流
curl、Git 等終端機工具 通常需要設定環境變數或明確指定代理參數 通常不需設定應用程式代理參數，但要檢查實際執行環境的路由
遊戲 UDP 與語音 一般 HTTP 系統代理通常不支援 可接收 UDP，後續仍取決於節點與伺服器端的支援能力
區域網路印表機、NAS 通常透過系統略過清單直連 需檢查區域網路規則、路由排除項目與防火牆設定
權限與影響範圍 主要修改應用程式可讀取的代理設定 涉及虛擬介面、路由與可能的 DNS 接管

對遊戲來說，「TUN 已接管」和「遊戲適合使用這個節點」是兩回事。節點必須支援 UDP，伺服器端也必須允許相關轉送；遊戲伺服器區域、往返延遲、延遲抖動、封包遺失與 NAT 行為也都會影響體驗。代理面板上一次 HTTP 延遲測試顯示 60 ms，不代表遊戲的 UDP 往返延遲也是 60 ms，更不能據此判斷語音是否穩定。

啟用前檢查：權限、路由、DNS 與節點支援

依序記錄目前狀態

  1. 記錄目前狀態：儲存目前生效的設定檔，記下系統代理連接埠、DNS 設定及其他 VPN 的狀態。若需要遠端維護，請先確認有其他方式可以恢復網路。
  2. 確認核心：在用戶端的核心資訊或記錄中確認是否使用 mihomo，以及其版本。不能只憑用戶端名稱判斷是否支援相同的 TUN 欄位。
  3. 檢查權限：依照用戶端提供的服務模式或權限提示操作。已安裝服務但仍然失敗時，請檢查啟動記錄中的介面建立、權限不足與路由寫入錯誤，不要只是不斷切換開關。
  4. 暫時停用衝突入口：排查期間先關閉其他 VPN 與系統代理，只保留 TUN，避免同時存在兩個入口而無法確認測試路徑。
  5. 確認對外介面：切換 Wi-Fi、有線網路或熱點後，請檢查自動偵測到的對外介面是否正確。選錯介面可能導致連線失敗，嚴重時甚至會形成路由迴圈。

mihomo 設定片段說明

以下僅示範 TUN 與 DNS 的相關設定，不包含節點、訂閱提供者及完整分流規則，因此不能直接當作可連線的完整設定檔。請將欄位合併至現有設定中，避免重複建立頂層 dns 或 tun 鍵；由用戶端管理的項目，應優先透過用戶端的覆寫機制設定。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
  • stack: mixed 是協定堆疊選項，不是 mixed-port，也不是「同時啟用系統代理」的開關。可用的堆疊及其平台行為，請以目前核心的文件為準。
  • auto-route 會讓核心設定接管路由；auto-detect-interface 用於偵測對外介面。在使用多張網卡或其他 VPN 的環境中，仍需手動確認。
  • dns-hijack 的 any:53 用於接管進入 TUN 的一般 UDP DNS 請求；若要處理 TCP 53，請依目前核心支援情況設定 tcp://any:53。
  • 127.0.0.1:1053 是核心的 DNS 監聽位址，不代表可以直接在作業系統的 DNS 設定中填入含連接埠的位址。
  • 198.18.0.1/16 是此處使用的 Fake-IP 位址池。回傳合成位址不代表解析失敗，前提是後續連線仍能回到保留對應資訊的核心。

範例選用了一個特定的 DoH 上游，但是否能連線仍取決於目前的網路與 DNS 對外連線設定。網路已中斷時，不要連續更換多種 DNS 選項；請先確認 DNS 請求是否進入核心，再檢查上游解析與連線錯誤。

DNS 與 IPv6：TUN 已啟用卻仍直連的常見原因

一般 DNS 接管不等於涵蓋加密 DNS

UDP/TCP 53 的劫持規則無法直接識別任意 HTTPS 連線中的 DoH 請求，也不會自動將 DoT 轉成核心 DNS 查詢。瀏覽器啟用「安全 DNS」後，可能會使用自己的解析路徑；該連線本身或許仍由 TUN 接管，但核心不一定能取得相同的網域對應資訊。

如果網域規則比對異常，可以暫時關閉瀏覽器自訂的安全 DNS，重新建立連線，觀察核心是否能記錄網域與對應規則。確認原因後，再決定採用哪一種解析策略，不要長期疊加多套難以釐清的 DNS 設定。

IPv4 正常，不代表 IPv6 也正常

目標同時提供 A 與 AAAA 記錄時，應用程式可能會優先使用 IPv6。若只測試 IPv4 路由，IPv6 仍可能透過另一條路徑連線。請分別查看 IPv4、IPv6 的測試結果、路由與連線記錄；只有 IPv6 失敗時，應檢查本機 IPv6 連線能力及核心相關設定，而不是直接判定整個節點失效。

Fake-IP 也需要完整的連線路徑配合：若 DNS 已回傳合成位址，但應用程式連線繞過 TUN，這個位址通常無法像真實伺服器位址一樣在公網存取。切換模式後若部分應用程式持續無法連線，請先清除該應用程式的 DNS 或連線快取，並確認系統 DNS 沒有留下指向已停止本機服務的設定。

驗證方式：分開測試「是否進入核心」與「是否走代理」

第一步：明確測試本機代理入口

先關閉 TUN，讓核心維持運作，再使用下列命令明確連線至範例混合連接埠。--noproxy "" 用來清空本次請求的略過清單，避免 NO_PROXY 造成干擾。在 Windows PowerShell 中，可將命令名稱寫成 curl.exe，避免舊環境中的同名別名造成問題。

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

這項測試只會確認明確指定的代理入口及該次請求的對外連線，不代表系統代理已生效，也不代表 UDP 可用。若此時連線失敗，請優先檢查連接埠監聽、規則與節點，不要先排查虛擬網卡。

第二步：只保留 TUN，停用本次請求的明確代理

關閉系統代理、啟用 TUN，再執行以下命令。--proxy "" 會停用本次 curl 請求的代理設定；--noproxy "*" 表示不使用應用程式層級的代理，但不會繞過作業系統的 TUN 路由。

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

請在用戶端的「Connections」或連線清單中尋找相應時間的請求，再對照「Logs」查看規則、策略組與最終對外連線。有些介面會顯示 TUN 入站類型；若沒有，可參考虛擬介面計數與路由檢查結果。網頁成功載入本身不是流量已接管的證據，因為它原本也可能可以直連。

第三步：使用實際應用程式測試 UDP

進入遊戲伺服器區域或開始語音通話，記下測試時間，並在連線清單中尋找 UDP 連線、目標位址、規則與代理鏈。若連線已進入核心卻命中 DIRECT，請調整對應規則；若已命中節點但持續逾時，則檢查節點的 UDP 支援與伺服器端限制。瀏覽器測速與 ICMP ping 都無法取代這項測試。

故障排查與復原：一次只調整一個項目

  • 瀏覽器能用，終端機無法連線：使用系統代理時，先檢查終端機環境變數與程式代理參數；使用 TUN 時，先確認終端機是否在容器、WSL2 或遠端主機中執行。
  • 一啟用 TUN 就斷網：先關閉 TUN，還原原本狀態，再檢查服務權限、虛擬介面建立、預設路由、實體對外介面與 DNS 上游；暫時關閉其他 VPN，避免路由衝突。
  • 遊戲已走代理，卻變得更卡：檢查遊戲伺服器區域的連線路徑、UDP 封包遺失與延遲抖動，並比較同一時段的直連與代理結果。不要只依據 HTTP 延遲數值選擇遊戲節點。
  • 無法連線至 NAS 或印表機：確認區域網路位址範圍是否套用直連規則、是否需要排除路由，並檢查本機防火牆。DIRECT 是核心的對外連線決策，不一定代表封包完全繞過虛擬介面。
  • 退出用戶端後網路異常：檢查系統代理是否仍指向已關閉的連接埠、DNS 是否仍指向已停止的本機監聽服務，以及 TUN 路由與虛擬介面是否已還原。

最後的選擇可以很簡單：應用程式會使用代理，需求以瀏覽網頁為主，就維持系統代理；需要涵蓋不支援代理的程式或 UDP，再啟用 TUN，並逐項確認權限、路由、DNS 與節點支援。涵蓋範圍變大不代表速度一定更快；能釐清每條連線的入口與出口，才算完成設定。