系統代理與 TUN：流量進入方式不同

瀏覽器可以上網，但命令列工具、遊戲或其他應用程式沒有出現在 Clash 連線清單中，首先應檢查流量從哪裡進入。系統代理只是提供代理位址給應用程式，例如 127.0.0.1:7890。應用程式採用這項設定後，才會將請求傳送至本機代理；自行直接連線、只讀取環境變數，或使用獨立網路設定的程式，不一定會使用系統代理。

TUN 是第三層虛擬網路裝置。作業系統依據路由表將 IP 封包送入虛擬網卡，再由 mihomo 讀取封包、辨識連線並套用分流規則。不必要求每個應用程式都支援 HTTP 或 SOCKS 代理，因此更適合接管一般直接連線應用程式的 TCP、UDP 流量。

比較項目系統代理TUN 虛擬網卡
連線方式應用程式連線至本機代理連接埠由系統路由引導 IP 封包
應用程式條件必須採用代理設定一般 IP 應用程式通常不必另行設定
UDP僅設定 HTTP 系統代理通常無法涵蓋可接管，但節點與協定仍須支援
權限通常不必建立網路裝置桌面版通常需要提升權限或使用背景服務
故障排查重點代理位址、連接埠、應用程式設定網卡、路由、DNS、權限與分流規則

啟用前檢查：核心、訂閱與權限

Clash 常用來泛指一系列用戶端與核心生態，但不代表每個安裝套件都支援相同的 TUN 參數。本文的 YAML 範例適用於 mihomo，也就是常說的 Clash Meta 核心。舊版 Clash、其他分支及行動版用戶端可能採用不同欄位或設定入口，不能只憑軟體名稱判斷相容性。

  1. 確認核心。在用戶端的「關於」、核心資訊或執行記錄中尋找 mihomo 標示。若介面沒有 TUN 開關，請先確認用戶端是否支援，不要直接加入大量不明設定。
  2. 先確認訂閱可用。先透過系統代理確認至少有一個節點可連線，且策略群組已選取有效節點。TUN 解決的是流量入口問題，無法修復失效的訂閱或節點驗證錯誤。
  3. 記下原有設定。記錄系統代理連接埠、目前的 DNS、正在使用的 VPN 和區域網路網段。首次設定時請保留本機操作方式，避免在遠端 SSH 工作階段中直接修改預設路由。
  4. 準備系統授權。Windows 通常需要服務模式或系統管理員權限；macOS 需依用戶端提示安裝特權輔助元件；Linux 則需要存取 /dev/net/tun，並具備管理網路的權限。

先退出其他使用虛擬網卡的 VPN，再測試 Clash TUN。多個用戶端同時新增預設路由或變更 DNS，容易造成流量路徑反覆切換。如需同時使用，請先確認各自能正常運作，再逐項設定排除路由與出口介面。

gvisor、system 與 mixed 網路堆疊

tun.stack 用來指定虛擬網卡流量採用哪種網路堆疊處理，不是節點協定選項，也不會把 Trojan 節點轉成 VLESS 節點。mihomo 常見的值有 gvisor、system 和 mixed；實際支援情況請以所用核心版本為準。

  • gvisor：使用使用者空間網路堆疊處理連線。排查相容性時可用來比較，但不能因此保證它在所有系統上都更穩定。
  • system：使用作業系統的網路堆疊處理連線。效能與相容性會受作業系統、驅動程式和網路環境影響，不宜直接認定它在所有裝置上都比較快。
  • mixed：mihomo 會組合兩種處理方式：TCP 使用 system，UDP 使用 gvisor。這是網路堆疊的組合，與同時接收 HTTP 和 SOCKS 請求的 mixed-port 無關。

如何判斷是否要切換網路堆疊

每次只變更一個參數，接著重新啟動核心並建立新的測試連線。若網頁正常，但語音或遊戲無法使用，先檢查節點是否支援 UDP，以及規則是否命中，再比較不同網路堆疊。若所有連線都沒有出現在面板中，應先檢查權限與路由；此時反覆切換 gvisor、system 通常無法找到根本原因。

mihomo TUN 設定：一併設定路由與 DNS

以下是要合併至現有設定檔的片段，不是完整訂閱。內容未定義節點、策略群組或分流規則，無法取代可用的完整設定。若頂層已有 tun 或 dns，應合併欄位，避免重複鍵值遭解析器覆寫。

config.yaml · TUN 與 DNS 設定片段
mixed-port: 7890
allow-lan: false
mode: rule

tun:
  enable: true
  stack: gvisor
  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:
    - 1.1.1.1
    - 9.9.9.9

範例中的兩個上游 DNS 位址是明確的設定範例，並非適用於所有網路的推薦值。請選擇目前網路可連線且符合使用需求的 DNS 解析服務。若訂閱已有完整的 DNS 策略，建議保留原有上游與網域分流設計，只補上必要的 TUN 欄位。

auto-route 與 auto-detect-interface

auto-route: true 會讓核心自動設定路由，將流量導入 TUN；auto-detect-interface: true 則用於自動辨識實際出口介面，協助代理連線經由實體網路送出，避免再次進入自身的 TUN。若使用多張網卡、虛擬機橋接、企業 VPN，或同時連接 Wi-Fi 與有線網路，自動辨識仍可能選錯介面，需查看記錄確認。

不要只確認路由表中是否有 0.0.0.0/0。不同平台可能透過更細分的路由、不同路由表或策略路由來接管流量。請一併參考路由查詢結果和用戶端連線記錄，判斷設定是否生效。

dns-hijack、1053 與 fake-ip

dns-hijack 會將符合條件的 DNS 流量交由 mihomo 內建 DNS 處理。範例中的 any:53 適用於常見的 UDP 53 查詢；若確實需要處理 TCP 53，可依核心支援情況加入 tcp://any:53。它並非所有 DNS 解析協定的總開關，也無法直接辨識或劫持瀏覽器透過 HTTPS 傳送的 DoH 請求。

127.0.0.1:1053 是 DNS 監聽位址範例，不代表要在系統 DNS 設定中填入含連接埠的字串。多數系統的 DNS 設定只接受 IP 位址；TUN 接管路徑、監聽連接埠和系統 DNS 設定應分開理解。

fake-ip 會為網域指派虛擬位址，再由核心記錄網域與連線之間的對應關係。範例位址池 198.18.0.1/16 屬於保留的測試位址範圍，解析出這個範圍內的位址不代表 DNS 發生錯誤。需要取得真實解析結果的區域網路服務，應透過適當的 fake-ip-filter 和 DNS 分流處理，而不是排除所有網域。

Windows、macOS 與 Linux 的 TUN 設定步驟

各用戶端的選單名稱並不一致，以下依功能入口說明。若介面提供 TUN、網路堆疊和 DNS 接管選項，建議優先使用這些設定。不少用戶端會在執行時重新產生設定檔，直接修改產生的檔案可能在下次啟動時失效；訂閱更新也可能覆寫手動修改，請使用用戶端提供的持續性覆寫或合併功能。

Windows：服務權限與虛擬網卡

  1. 匯入訂閱，確認透過系統代理可連線至目標服務，再暫時關閉其他 VPN。
  2. 前往用戶端設定中的服務模式，依提示安裝並啟動服務；若用戶端採用其他提升權限的方式，請依其說明授予系統管理員權限。
  3. 開啟 TUN，選擇核心支援的網路堆疊，並套用設定。若出現安裝驅動程式或授權網路裝置的提示，請先確認提示來自目前使用的用戶端。
  4. 開啟 PowerShell，檢查新增的虛擬網卡和 IPv4 路由；同時查看用戶端記錄，確認是否有權限不足、建立裝置失敗或新增路由失敗等訊息。
Get-NetAdapter
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Format-Table DestinationPrefix,InterfaceAlias,NextHop,RouteMetric

網卡名稱取決於用戶端和設定，不一定會叫做 Clash。網卡存在只代表裝置已建立，不能單憑這點確認應用程式流量已套用代理策略。

macOS：輔助元件與 utun 介面

  1. 確認目前使用的用戶端和核心支援 TUN，並完成所需的特權輔助元件安裝。
  2. 在用戶端啟用 TUN 或同等的虛擬網卡功能，並依提示確認系統授權。
  3. 使用以下命令查看介面、路由和系統 DNS，再與啟用前的結果比較。
ifconfig
netstat -rn -f inet
scutil --dns

macOS 可能同時有多個 utun 介面，其他 VPN 和系統功能也會建立這些介面。不要只因看到 utun 就認定它屬於 Clash，也不要手動刪除所有同類介面。請比較啟用前後的差異，並參考路由和記錄確認介面所屬。

Linux：TUN 裝置與網路管理權限

桌面用戶端通常會透過服務程序提升權限。以命令列部署時，程序至少必須具備建立 TUN 和管理路由的權限，通常會涉及 CAP_NET_ADMIN；其他所需權限則須視核心功能、服務限制和執行方式確認。不要直接套用來路不明的 capabilities 清單。

test -c /dev/net/tun && echo "TUN device available"
ip link show
ip rule show
ip route show table all
resolvectl status

resolvectl 適用於使用 systemd-resolved 的系統；找不到此命令不代表 TUN 故障。在容器中執行時，主機也必須提供 TUN 裝置和相應的網路權限，只在容器內改用 root 不一定足夠。首次測試請在本機進行，避免路由變更中斷遠端管理連線。

Android 與 iOS：系統 VPN 授權

Android 用戶端通常透過系統 VPN 介面接管流量，不必照搬桌面版的網卡驅動程式安裝步驟。匯入相容的設定後，選擇 VPN 或虛擬網卡模式；首次連線時，請允許系統 VPN 權限。若已啟用依應用程式代理，請確認目標應用程式在接管範圍內；遭排除的應用程式不會因桌面範例設定了 auto-route 就自動納入。

iOS 用戶端通常使用系統提供的網路延伸功能。請先確認 App 支援相應的設定格式，再新增系統 VPN 設定並授權連線。桌面版 mihomo 的所有 TUN 欄位不能直接視為通用的 iOS 設定，也不能假設每個支援 Clash 訂閱的 App 都採用 mihomo 核心。

行動裝置通常無法同時啟用兩個同類型的一般 VPN 通道。若連線後立即中斷，請先檢查其他 VPN、隨選連線規則和系統背景限制，不要反覆更換節點協定。

確認流量接管：連線記錄、DNS 與 UDP

先排除系統代理造成的誤判

暫時關閉用戶端的系統代理，保留 TUN。使用原本未設定代理的程式送出新請求，並查看連線面板中的程序、目標、規則和出口策略。也可執行以下命令，明確要求 curl 不使用顯式代理；這只能排除該請求使用顯式代理的可能，無法單獨證明 TUN 已接管流量。

curl --noproxy '*' -I https://example.com

若網頁可正常存取，且連線記錄中找到對應請求，再確認命中的策略。命中 DIRECT 是正常的規則結果，不代表 TUN 失效。切換節點後，已建立的長連線也可能繼續使用原有路徑；測試時請重新建立連線。

分別測試 DNS 與 UDP

  • DNS：使用系統解析工具查詢未快取的網域，並觀察核心記錄。若瀏覽器啟用了安全 DNS，查詢結果不一定會經過系統的 UDP 53 路徑。
  • UDP：使用實際的語音、遊戲或 QUIC 應用程式檢查連線清單。網頁能透過 TCP 443 開啟，不代表 UDP 443 也能正常使用。
  • IPv6：雙協定網路需分別檢查 IPv4 和 IPv6。若只設定 IPv4 接管，部分應用程式可能優先使用另一條 IPv6 路徑。
  • 區域網路：測試路由器管理頁面、印表機和內網網域。需要直連的目的位址應設定明確規則；特殊網路環境也可能需要排除路由。

啟用 TUN 後無法上網：逐層排查與復原

狀況優先檢查處理方式
未建立虛擬網卡服務、授權、裝置存取權限修正權限後重新啟動核心，並查看第一筆啟動錯誤
網卡已建立，但連線清單空白路由、依應用程式排除、IPv6確認實際請求是否進入接管路徑
無法連線至網域DNS 上游、接管、快取確認解析服務可連線，再檢查 fake-ip 設定
網頁正常，遊戲無法連線節點的 UDP 支援與分流規則檢查目標規則，再比較不同網路堆疊
切換網路後無法上網出口介面與舊路由重新建立 TUN，讓核心重新辨識出口介面
無法連線至區域網路裝置私有網路規則、路由衝突、內網 DNS明確設定直連與排除範圍，保留內網解析

復原時，先在用戶端關閉 TUN，再正常結束用戶端，並確認系統代理是否仍指向 127.0.0.1:7890。若代理程序已停止，但系統代理仍開啟，瀏覽器可能持續顯示連線失敗；這和殘留的 TUN 路由是兩種不同問題。

接著還原先前記錄的 DNS，並中斷後重新連線目前的網路。若路由仍有異常，再檢查背景服務是否仍在執行；必要時重新啟動系統，還原網路狀態。不要批次刪除不熟悉的路由或網卡，企業網路、虛擬機和其他 VPN 可能仍在使用它們。

若要進一步整理設定結構，請參閱Clash 設定說明；尚未決定使用哪個用戶端，可先閱讀用戶端選擇指南，依平台和核心功能挑選。