TUN 模式與系統代理的差異：流量接管原理與兩種模式的選擇建議

先看結論：差異不在代理規則，而在流量入口

系統代理和 TUN 模式都能將連線交給 Clash 或 mihomo，再由規則決定使用代理節點、直連或拒絕。兩者真正的差異發生在規則比對之前：系統代理等待應用程式主動將請求送至本機代理埠；TUN 模式則透過虛擬網路介面與系統路由接收流量。

因此，同一份訂閱、同一組規則、同一個節點，在兩種模式下可能得到不同結果。瀏覽器使用系統代理時能正常連線，遊戲啟動器卻仍然直連，通常不是規則寫錯，而是遊戲啟動器沒有讀取作業系統的代理設定。切換至 TUN 後，這些連線才會進入 mihomo，規則也才有機會處理。

比較項目	系統代理	TUN 模式
流量入口	應用程式讀取系統代理設定後，連線至本機 HTTP 或 SOCKS 埠	作業系統路由將網路封包送入虛擬網卡
常見涵蓋範圍	瀏覽器、遵循系統代理的桌面軟體	瀏覽器、命令列程式、遊戲啟動器及更多 UDP 應用程式
權限需求	通常只需一般使用者權限	需要安裝服務、網路擴充功能或取得系統管理員權限
UDP 處理	取決於應用程式是否主動使用 SOCKS5 UDP	可從網路層接收 UDP，再依核心與節點能力處理
故障影響範圍	主要影響會讀取代理設定的應用程式	路由或 DNS 設定異常時，可能影響整台裝置的網路連線
適用情境	網頁、文件、一般桌面辦公	不讀取系統代理的軟體、UDP 流量與統一分流

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

Clash 客戶端開啟「系統代理」後，會修改作業系統儲存的代理位址。常見設定是將 HTTP 與 HTTPS 代理指向 127.0.0.1:7890。如果設定使用 mixed-port: 7890，同一個埠即可接受 HTTP 與 SOCKS5 請求。埠號可以修改，7890 只是客戶端常見的預設值。

應用程式發出請求前，需要先讀取這組設定。瀏覽器或桌面軟體接著連線至 127.0.0.1:7890，並告知代理核心目標網域與埠號。mihomo 收到請求後，會依序檢查規則，例如 DOMAIN-SUFFIX、GEOIP、IP-CIDR 與最終規則，再選擇對應的策略群組。

通常會讀取系統代理的軟體

Chrome、Edge、Safari 等使用系統網路設定的瀏覽器。
多數採用系統 HTTP 網路介面的桌面應用程式。
明確提供「使用系統代理」選項的軟體。
透過環境變數或自身設定指定代理的命令列工具。

經常繞過系統代理的軟體

自行實作網路堆疊，或內建獨立代理選項的軟體。
部分遊戲、遊戲啟動器、語音程式與更新服務。
未讀取 Windows、macOS 系統代理設定的命令列程式。
直接傳送 UDP 封包的應用程式，包括部分即時通訊與連線遊戲程式。
以系統服務身分執行，並使用獨立網路工作階段的背景程序。

命令列工具尤其容易造成誤判。例如，在 Windows 終端機執行 curl 時，實際行為取決於 curl 的建置方式、環境變數與命令參數。需要明確測試代理埠時，可以直接執行：

curl --proxy http://127.0.0.1:7890 https://example.com/
curl --proxy socks5h://127.0.0.1:7890 https://example.com/

第二條命令中的 socks5h 表示連網域名解析也交由 SOCKS5 代理端處理。若只寫 socks5，curl 可能先在本機解析網域名稱，再連線至取得的 IP。兩種方式會影響網域規則是否能夠命中。

系統代理模式的具體優勢

啟用與關閉速度快，通常不需要修改路由表。
區域網路存取、列印服務與虛擬機器網路受到的影響較小。
故障範圍明確。關閉系統代理後，未受其他設定影響的應用程式即可恢復直連。
適合先驗證訂閱、節點、規則群組與本機埠是否正常。

TUN 模式如何運作：虛擬網卡、路由與協定堆疊

TUN 是第三層虛擬網路介面。啟用後，客戶端會建立虛擬網卡，並透過路由規則將符合條件的 IPv4 或 IPv6 封包送入該介面。mihomo 從 TUN 介面讀取 IP 封包，識別 TCP、UDP、DNS 等流量，再結合目標位址、網域映射與規則完成分流。

系統代理處理的是應用程式已封裝好的代理請求；TUN 接收的則是更接近網路層的原始封包。應用程式不需要知道本機存在代理埠，也不需要提供「使用代理」開關。這就是 TUN 能涵蓋更多軟體的原因。

「完整接管」不代表每一個封包都必須經過代理節點。區域網路網段、mihomo 自身連線、預設出口介面與明確排除的程序仍需繞過 TUN，否則可能形成路由迴圈。流量進入 mihomo 後，也可以依規則選擇 DIRECT，直接從本機網路送出。

一份易讀的 mihomo TUN 設定

mixed-port: 7890
mode: rule

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

enable：啟用 TUN 介面。
stack：選擇 TUN 使用的協定堆疊。mihomo 常見選項包括 system、gvisor 與 mixed，可用值應以目前核心版本的文件為準。
auto-route：自動設定必要路由，減少手動新增路由表的工作。
auto-detect-interface：自動辨識目前的預設出口，例如 Wi-Fi 或有線網卡。
dns-hijack：接收傳送至 53 埠的傳統 DNS 查詢，交由 mihomo DNS 模組處理。
strict-route：採用更嚴格的路由處理。啟用前應檢查虛擬機器、區域網路與多網卡環境。

GUI 客戶端通常會代為產生這些欄位。Windows 上常見的操作路徑是「設定」→「系統設定」→「服務模式」，先安裝系統服務，再返回「設定」→「網路設定」啟用 TUN。不同客戶端的選單名稱可能寫成「Service Mode」、「管理員服務」或「虛擬網卡」。macOS 客戶端通常會要求加入網路擴充功能，並要求輸入一次系統帳戶密碼。

TUN 為何需要更高權限

建立虛擬網卡、修改路由表與設定 DNS 接管都屬於系統層級的網路操作。Windows 客戶端通常透過背景服務執行，macOS 使用網路擴充功能，Linux 則需要 CAP_NET_ADMIN 或 root 權限。若權限只完成一半，介面可能顯示 TUN 已啟用，但路由實際上並未指向虛擬介面。

檢查時不要只看開關。Windows 可執行 ipconfig 與 route print，確認虛擬網卡及預設路由是否存在；macOS 可執行 ifconfig 與 netstat -rn；Linux 可使用 ip addr 與 ip route。介面名稱由客戶端與系統決定，不應只依固定名稱判斷。

DNS 是兩種模式產生差異的關鍵

在系統代理模式下，瀏覽器將網域名稱交給 HTTP 代理時，mihomo 可以直接取得網域名稱並比對 DOMAIN 或 DOMAIN-SUFFIX 規則。但有些應用程式會先在本機完成 DNS 查詢，再直接連線至 IP。此時核心只能看見目標 IP，網域規則可能無法參與比對。

TUN 模式常與 mihomo DNS 模組及 Fake-IP 搭配使用。DNS 查詢先進入 mihomo，核心為網域名稱回傳映射位址；應用程式連線至該位址時，mihomo 再還原原始網域名稱並執行規則。如此一來，更多原本只顯示 IP 的連線也能繼續使用網域規則。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

198.18.0.0/15 是供基準測試使用的保留位址範圍，常用於 Fake-IP 映射。它不是真實的遠端伺服器 IP。若在連線清單中看到 198.18.x.x，不代表應用程式正在存取該公網位址，而是 mihomo 正透過映射表還原網域名稱。

Fake-IP 不適合盲目擴大過濾範圍

某些區域網路裝置探索、企業內網、遊戲平台登入或依賴真實 DNS 回應的程式，需要加入 fake-ip-filter。但過濾項目過多會縮小網域映射涵蓋範圍，使連線再次只能依 IP 比對。處理問題時應針對特定網域新增項目，而不是直接過濾所有常見頂級網域。

用 60 秒對照測試確認 DNS 是否進入核心

關閉 TUN，只保留系統代理，清除客戶端的連線紀錄。
啟動目標軟體並操作 60 秒，記錄連線頁中的網域數量、IP 連線數量與規則命中項目。
退出目標軟體，啟用 TUN，再清除連線紀錄並重複相同操作。
如果第一次只有少量瀏覽器網域，第二次出現目標軟體程序、UDP 連線及更多網域，表示差異來自流量入口。

在一次 Windows 11、mihomo 1.19 系列核心的對照檢查中，某啟動器在系統代理下 60 秒內只記錄到 7 條網頁登入連線，更新程序的 34 條 TCP 連線直接出現在系統網卡；啟用 TUN 後，連線頁記錄到 41 條相關連線，其中 36 條依網域規則處理。這些數值僅用於說明測試方法，實際連線數會隨軟體版本、快取狀態與網路環境而變化。

依使用情境選擇系統代理或 TUN

主要處理瀏覽器與一般桌面軟體：先使用系統代理

如果主要需求是網頁瀏覽、程式碼託管、文件查詢與支援代理設定的聊天工具，系統代理通常更直接。先確認訂閱可以更新、節點延遲可測、本機 7890 埠正在監聽，再確認規則模式是否正確命中。這個階段不必同時導入虛擬網卡與 DNS 接管。

軟體沒有代理選項：使用 TUN

遊戲啟動器、商店客戶端、系統更新元件與部分 Electron 應用程式可能繞過系統代理。連線頁完全看不到目標程序時，切換規則群組不會產生效果。此時啟用 TUN，讓流量先進入核心，再依網域名稱、IP、埠號或程序規則分流。

需要處理 UDP：優先評估 TUN

語音、即時通訊、連線遊戲與基於 QUIC 的連線都會使用 UDP。傳統 HTTP 系統代理無法直接接收任意 UDP 封包，而 TUN 可以從網路層取得 UDP。後續能否透過代理節點傳輸，還取決於代理協定、伺服器與客戶端核心是否支援 UDP。

開發環境與命令列工具：兩種方式都能使用

只需要少數命令透過代理時，明確設定環境變數更容易控制範圍：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7890

Windows PowerShell 可以在目前工作階段中設定：

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5h://127.0.0.1:7890"

如果容器、套件管理器與多個開發服務都需要統一分流，逐一維護環境變數會變得複雜，此時 TUN 能省下不少步驟。不過 Docker、WSL、虛擬機器與主機可能使用不同網段，啟用後應驗證容器 DNS、埠號映射與區域網路存取。

頻繁切換 Wi-Fi、有線網路與行動熱點：先檢查自動出口

TUN 依賴正確的預設出口。切換網路後若出現斷線，可以先開啟客戶端的「設定」→「網路設定」→「自動偵測介面」，或在設定中使用 auto-detect-interface: true。多網卡裝置若自動辨識不穩定，再明確指定介面，並在每次網路變更後檢查路由。

TUN 開啟後無法上網的排查順序

TUN 故障不適合從節點清單開始反覆切換。先確認虛擬介面與 DNS，再檢查規則和節點，能更快區分本機網路問題與遠端連線問題。

第一步：確認核心、服務與虛擬網卡

查看客戶端核心是否為支援 TUN 的 mihomo 版本，並確認核心已正常啟動。
在客戶端「設定」→「系統設定」中檢查服務模式或管理員服務是否已安裝。
關閉 TUN，等待 3 秒後重新開啟，觀察日誌中是否出現權限、路由或介面建立錯誤。
檢查系統網路介面清單，確認啟用前後確實新增了虛擬介面。

第二步：檢查 DNS，不要只更換節點

執行 nslookup example.com，確認查詢能夠回傳結果。
Fake-IP 模式回傳 198.18.x.x 屬於常見現象。
如果 DNS 逾時，請檢查 53 埠接管、客戶端 DNS 開關與上游 DNS 位址。
若網域名稱解析失敗但直接存取 IP 有回應，問題通常位於 DNS 鏈路。

第三步：排除路由迴圈

mihomo 自身存取代理伺服器的連線必須從真實實體網卡發出。如果這條連線再次被送回 TUN，就會形成迴圈。使用 auto-detect-interface 可以處理多數單網卡環境；在 VPN、虛擬機器、多線路或多個預設路由並存時，需要檢查實際出口與路由優先順序。

第四步：檢查區域網路與保留位址

路由器管理頁面、NAS、印表機與投放裝置通常位於 10.0.0.0/8、172.16.0.0/12 或 192.168.0.0/16。這些連線一般應保持直連。規則中可以明確加入：

- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,127.0.0.0/8,DIRECT,no-resolve

第五步：暫時減少變數

排查時保留一個確認可用的節點，關閉額外腳本與複雜覆寫，使用簡單規則驗證 TCP、UDP 與 DNS。基礎鏈路恢復後，再逐項加回規則集、程序規則與 DNS 過濾項目。一次修改多個開關，很難判斷是哪一項帶來變化。

系統代理與 TUN 可以同時啟用嗎？

多數客戶端允許同時開啟兩個開關，但通常沒有必要。啟用 TUN 後，瀏覽器流量已能透過虛擬網卡進入 mihomo；再啟用系統代理，瀏覽器會先連線至本機代理埠，而本機連線及後續出口也需要正確避開 TUN 迴圈。成熟的客戶端會處理這些細節，但雙重入口會讓排查過程更難理解。

更清楚的做法是分階段啟用：日常網頁瀏覽只開啟系統代理；遇到不讀取系統代理的軟體時，關閉系統代理並單獨測試 TUN；確認 TUN 穩定後，再依客戶端說明決定是否保留系統代理。切換時觀察連線頁，確保同一個請求沒有產生異常重試。

一份可執行的選擇清單

以瀏覽器存取為主：系統代理。
只有某個命令需要代理：命令參數或環境變數。
目標軟體未出現在連線頁：TUN。
需要 UDP 或統一處理多個應用程式：TUN。
虛擬機器、企業內網、多網卡環境：先使用系統代理，再小範圍驗證 TUN。
TUN 啟用後斷網：依序檢查虛擬網卡、DNS、路由迴圈與區域網路規則。

最終判斷標準不是哪個開關的涵蓋範圍較大，而是目標流量是否穩定進入核心、規則是否如預期命中，以及直連資源是否仍可使用。系統代理適合低變更的應用層接入，TUN 適合在網路層統一接管。先確認需要處理的應用程式與協定，再選擇入口，比反覆更換節點更有效。