先釐清流量接管與出站規則

系統代理和 TUN 要解決的是同一個前置問題：應用程式發出的連線，如何進入 Clash 核心。進入核心後，才由運作模式、分流規則和策略組決定直連、代理或拒絕。啟用 TUN 不代表啟用全域代理；啟用系統代理也不代表所有程序都會遵循設定。

本文以使用 mihomo 核心的 Clash 用戶端為例。不同用戶端、核心和作業系統的 TUN 實作不盡相同，不能直接將某個用戶端的開關名稱套用到所有軟體。操作前請先在用戶端的核心資訊中確認實際執行的是 mihomo，再核對其支援的設定欄位。

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

瀏覽器如何將連線交給 Clash

用戶端啟用「系統代理」後，通常會將作業系統的 HTTP、HTTPS 代理位址改為本機監聽位址。例如，設定中的 mixed-port: 7890 表示在同一個連接埠接受 HTTP 代理和 SOCKS 要求。這裡的 7890 只是範例，檢查時應以目前生效的設定為準。

支援系統代理的瀏覽器讀取設定後，會先連線至 127.0.0.1:7890。瀏覽 HTTPS 網站時，通常會透過 HTTP CONNECT 建立通道，再於通道中進行 TLS 通訊。一般代理轉送不需要為瀏覽器安裝用來解密網站流量的根憑證。

支援系統代理的應用程式
  → 127.0.0.1:7890
  → mihomo 規則比對
  → DIRECT 或所選代理節點

系統設定不等於所有程式的設定

因此，「瀏覽器能連線、終端機卻不行」不一定代表節點失效。兩者可能根本沒有經過相同的接管路徑。同樣地，Windows 的 WinHTTP 代理與使用者介面的代理設定並非同一組狀態，不能只根據 netsh winhttp show proxy 的輸出判斷瀏覽器是否使用代理。

TUN：透過虛擬網卡與路由接管流量

TUN 是第三層虛擬網路介面。啟用後，用戶端或輔助服務會建立虛擬網卡，並依設定調整路由。目的位址符合這些路由的 IP 封包會送入核心處理，不必要求應用程式先支援 HTTP 代理或 SOCKS 協定。

應用程式送出 IP 封包
  → 作業系統選擇路由
  → TUN 虛擬網卡
  → mihomo 網路堆疊與規則比對
  → DIRECT 或所選代理節點

這條路徑讓不遵循系統代理的應用程式也有機會進入分流規則，但不保證所有協定都能透過任意代理節點轉送。例如，遊戲語音需要 UDP，仍須節點協定、伺服器和相關設定都支援 UDP；ICMP 能否取得預期回應，也不能直接用來判斷 HTTPS 代理是否正常。

三個常見欄位各自的用途

欄位用途檢查重點
auto-route自動設定通往 TUN 的路由是否與公司 VPN 或其他虛擬網卡衝突
auto-detect-interface自動辨識用於連線的網路介面切換 Wi-Fi 或有線網路後，是否選對出口
stack選擇 TUN 使用的網路堆疊依核心支援狀況與系統相容性選擇

建立網卡和修改路由通常需要管理員權限、系統服務或平台授權。用戶端的「服務模式」常用來讓輔助服務執行這些操作；它不等於代理伺服器，也不代表安裝服務後節點就一定可用。如果 TUN 開關立即彈回，請先查看權限、服務和網卡建立記錄，再排查節點。

DNS 與 fake-ip：網域如何參與分流

使用系統代理時，應用程式可能會將網域直接交給本機代理，也可能先在本機解析；實際行為取決於應用程式和代理協定。TUN 接收到的則是 IP 封包，若核心沒有相應的網域對應資訊，單憑目的 IP 不一定能準確還原應用程式原本存取的網域。

fake-ip 模式會替網域回傳一個合成位址，並保存網域與位址的對應關係。例如，mihomo 常用的 198.18.0.0/16 範圍就是用於這類對應，並不代表網站的實際出口位址。應用程式接著連線至合成位址時，核心便能取回網域，再套用 DOMAIN-SUFFIX 等規則進行比對。

設定片段應合併至既有 Profile

以下是用來說明欄位關係的 mihomo YAML 片段，不含節點與策略組，不能直接當作完整訂閱使用。範例採用 IPv4 DNS；請勿直接覆蓋既有 Profile，也不要在檔案中重複新增第二個頂層 dns 或 tun。若用戶端採用覆寫或合併機制，請檢查最終生效的設定。

mixed-port: 7890
mode: rule

tun:
  enable: true
  stack: system
  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:
    - 223.5.5.5

dns-hijack 中的 any:53 表示劫持被 TUN 捕獲的相關傳統 DNS 要求，預設比對 UDP；若要處理 TCP DNS，可依核心文件加入 tcp://any:53。這不會強制將所有 DNS 協定轉為本機解析：瀏覽器內建的 DoH 通常使用 HTTPS，單靠連接埠 53 的規則無法接管。

如何選擇：先依應用程式需求判斷

使用情境優先嘗試驗證方式
瀏覽器、會讀取系統代理的桌面應用程式系統代理開啟網頁，確認用戶端連線記錄中出現相應網域
單一命令列工具工具本身的代理參數明確指定本機連接埠，並與未指定代理時的結果比較
忽略系統代理的應用程式TUN關閉系統代理後，檢查應用程式的新連線是否仍進入核心
遊戲、語音等 UDP 應用程式TUN 搭配支援 UDP 的節點檢查 UDP 連線、策略組選擇及實際連線是否正常
同時使用公司 VPN先保留現有網路設定檢查內網路由、網域解析和位址排除項目，再逐項啟用

兩種方式可以同時啟用，但首次排查時不建議這麼做。支援系統代理的應用程式可能仍連至本機代理連接埠，其他應用程式則走 TUN。即使連線記錄看起來都正常，也難以判斷實際生效的是哪種接管方式。請先確認單一路徑正常，再依需求組合使用。

也不要以「啟用 TUN 後延遲更低」作為通用判斷。TUN 改變的是本機接管路徑，遠端出口地區、線路負載和伺服器狀態仍由節點決定。比較時至少固定目標網站、節點、規則模式和測試工具，避免將更換節點造成的變化誤認為是虛擬網卡的效果。

切換步驟：每次只調整一個變因

  1. 儲存目前的設定。記下 Profile 名稱、本機連接埠、運作模式和策略組選擇。複製自訂覆寫設定，避免訂閱更新後無法還原。
  2. 先確認本機代理入口。暫時關閉 TUN，保持核心運作，使用明確指定代理的命令存取測試位址。若失敗，先檢查連接埠、節點或規則。
  3. 確認系統代理。啟用系統代理，用瀏覽器存取相同位址，並在用戶端連線頁查看網域、命中的規則和實際出站方式。測試後請關閉系統代理。
  4. 單獨啟用 TUN。依用戶端要求授權或啟動服務，確認記錄中沒有網卡建立或路由寫入失敗，再測試未設定代理的應用程式。
  5. 檢查非主要用途的連線。測試區域網路裝置、公司內網、語音，以及從休眠狀態喚醒後的網路。確認需要直連的流量沒有被錯誤送往遠端節點。

用命令區分連接埠問題與路由問題

以下位址僅供測試。Windows 可使用 curl.exe，macOS 和 Linux 可使用 curl。請將範例連接埠換成目前設定中的實際值；第二個命令會移除本次要求的明確代理設定，但若已啟用 TUN，封包仍可能由虛擬網卡接管。

# 測試本機 HTTP 代理入口
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/

# 不使用 curl 的代理入口，觀察系統路由路徑
curl --proxy "" --noproxy "*" --connect-timeout 10 -I https://example.com/

收到 HTTP 狀態碼只能表示該次要求獲得回應，不能單獨證明流量是否經過代理。還要在用戶端連線頁確認是否出現該要求、命中了哪條規則，以及最後選用的是 DIRECT 還是代理節點。瀏覽器可能重用舊連線，切換後請關閉舊連線或重新啟動測試應用程式再觀察。

常見問題：依序檢查入口、DNS 與路由

系統代理可用，TUN 無法連線

網頁正常，遊戲或語音無法連線

先確認應用程式的連線是否進入 TUN，再確認相應策略組實際選用的節點支援 UDP。網頁主要測試 TCP 或瀏覽器本身的連線路徑，不能證明遊戲的 UDP 通道可用。也不要只看節點延遲測試結果；測試網址連線成功和業務協定正常是兩回事。

結束用戶端後仍無法連上網路

先檢查系統代理是否仍指向已停止監聽的 127.0.0.1 連接埠，再透過用戶端正常關閉 TUN，確認路由與 DNS 設定已還原。若用戶端異常結束，可重新啟動後正常關閉；問題仍未解決時，請儲存記錄並依作業系統的網路設定逐項還原，不要直接一次刪除所有網卡或路由。