Clash TUN 模式原理與設定教學：讓全域流量經由核心處理

TUN 接管流量，不代表所有連線都會走代理

Clash TUN 模式會在系統中建立虛擬三層網路介面，並透過路由將符合條件的 IP 封包交給核心處理。核心會讀取目的位址、連接埠及可取得的網域資訊，再依規則選擇 DIRECT、代理節點或其他策略。除了瀏覽器之外，不讀取系統代理設定的命令列工具、遊戲及部分桌面應用程式，也能交由同一套規則處理。

標題中的「全域流量」指的是接管範圍，並非用戶端的 Global 模式。啟用 TUN 後仍可使用 Rule 模式：區域網路連線直連，指定網域走代理，其餘連線則由最後的 MATCH 規則決定。路由排除項、應用程式內建 VPN、其他網路命名空間及部分系統流量，都可能不在接管範圍內。

系統代理與 TUN 的接管範圍差異

TUN 也不是網路加速開關。節點壅塞、UDP 無法連線或規則比對錯誤，不會因為改用虛擬網卡就自動消失。先確認同一個節點透過一般代理能正常連線，再擴大接管範圍，較容易分辨是節點問題還是本機路由問題。

啟用前：確認核心、權限與設定來源

以下 YAML 適用於支援這些欄位的 mihomo，也就是 Clash Meta 後續採用的核心名稱。不同年代的 Clash 核心、行動版封裝及圖形介面用戶端，支援的設定不盡相同。不能只因為用戶端名稱含有 Clash，就認定整段參數都能直接使用。

1. 記下目前使用的核心。在用戶端的「關於」或「核心」資訊頁記錄版本字串；遇到 unknown field、unsupported stack 等錯誤時，先確認該版本支援哪些欄位，不要反覆切換節點。
2. 備份可用的設定。保留目前的設定檔，並截圖記錄規則模式、DNS 與 TUN 設定。需要還原時，先關閉 TUN，再恢復原有設定。
3. 確認設定修改位置。訂閱設定可能會在更新時遭到覆寫。優先使用用戶端提供的覆寫、合併設定或 TUN 設定面板；直接編輯訂閱快取檔案通常只能暫時生效。
4. 暫時關閉其他 VPN。先確保只有一條流量接管路徑。企業 VPN、加速器與另一款 TUN 用戶端同時修改預設路由，會讓故障位置難以判斷。

首次測試時可關閉系統代理，只保留 TUN，減少瀏覽器仍透過舊代理連接埠連線所造成的干擾。這是為了確認接管效果，並不代表系統代理與 TUN 一定不能同時使用。測試完成後，再依用戶端建議決定是否同時啟用。

mihomo 設定：TUN、Fake-IP 與 auto-route

以下是合併至現有設定的頂層片段，並非完整訂閱。保留既有的 proxies、proxy-groups 與 rules；若原檔已有 dns 或 tun，請合併對應內容，不要重複建立同名頂層鍵。範例使用 mixed-port 7890，DNS 則監聽 127.0.0.1:1053；兩者用途不同。

mixed-port: 7890
mode: rule

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

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

各欄位的用途

• stack: mixed：在支援此值的 mihomo 中，混合使用系統與使用者空間網路堆疊。若目前的用戶端不支援，請依其核心文件選用 system 或 gvisor；不要把切換堆疊當成通用修復方式。
• auto-route: true：由核心自動設定流量進入 TUN 所需的路由。這不能取代管理員權限，也不保證能接管所有外部 VPN 路由。
• auto-detect-interface: true：嘗試辨識實際的對外網路介面，避免代理流量再次進入 TUN。在使用雙網卡、熱點或企業 VPN 的環境中，仍需確認辨識結果。
• dns-hijack：將進入 TUN 且符合條件的普通 53 連接埠 DNS 要求交給核心 DNS 處理。範例涵蓋 UDP 與 TCP 的 53 連接埠要求。
• enhanced-mode: fake-ip：回傳虛擬位址，並在核心中保存網域對應資料。連線至這些位址時，核心便能還原網域並進行分流。

198.18.0.1/16 屬於基準測試用途的位址範圍，並非真實網站的出口位址。查詢結果出現這類位址，是 Fake-IP 的預期行為。若所在網路也使用此網段，應先排查位址衝突；不要把虛擬位址當成一般公網 IP，加入固定直連路由。

Fake-IP 過濾與加密 DNS 的限制

fake-ip-filter 中的網域會以真實位址回應，但這不會自動將連線改為 DIRECT。區域網路服務仍需在規則中正確分流。範例中的 *.local 也無法取代 mDNS 多播探索機制；若找不到印表機或投放裝置，還需檢查本機網路權限與多播路徑。

瀏覽器內建的 DoH 通常透過 443 連接埠傳送，DoT 則常用 853 連接埠，兩者都不會直接受到上述 53 連接埠劫持的接管。排查時可暫時關閉瀏覽器的「安全 DNS」及 Android 的「私人 DNS」，先測試系統 DNS 路徑，再決定長期採用哪一種解析策略。

各平台啟用 TUN 的操作順序

Windows：先安裝服務，再啟用虛擬網卡

1. 匯入設定並選擇 Rule 模式，先透過系統代理確認節點可用。
2. 在用戶端設定中尋找「服務模式」選項；若提供安裝服務按鈕，請依提示完成管理員授權。沒有服務模式的用戶端可能需要以管理員身分執行。
3. 啟用標示為「TUN 模式」或「虛擬網卡」的開關。選單名稱依用戶端而異，請勿將「系統代理」開關誤認為 TUN。
4. 查看記錄中是否出現建立虛擬網卡、成功設定路由等訊息；接著關閉系統代理，單獨測試 TUN。

可執行 route print 檢查路由。介面名稱與路由前綴會隨核心及系統版本而異，不必要求一定出現特定網卡名稱。若記錄顯示 access denied 或 operation not permitted，應先修正權限或服務狀態，而不是修改 DNS 位址。

macOS：確認輔助服務與路由權限

在支援 TUN 的用戶端中安裝所需的輔助服務，再啟用 TUN。若系統顯示網路延伸功能或背景服務的授權提示，請確認應用程式名稱後再允許；不同用戶端使用的授權機制可能不同。切換 Wi-Fi、乙太網路或熱點後，請重新確認對外網路介面是否正確。

可在終端機使用 netstat -rn 查看路由，並以 scutil --dns 查看系統解析器。系統可能同時有多個 utun 介面，僅看到 utun 並不能證明 Clash 已成功接管，還需搭配用戶端的連線記錄判斷。

Linux：區分網卡裝置與網路管理權限

確認 /dev/net/tun 存在；自動設定路由通常需要相應的網路管理權限，例如透過受控服務取得 CAP_NET_ADMIN。不要為了成功啟動，就長期授予整個桌面用戶端不必要的高權限。容器環境還需明確開放 TUN 裝置與相關權限；主機能使用，不代表容器內也能使用。

使用 ip rule、ip route show table all 與 resolvectl status，分別檢查策略路由、所有路由表及解析狀態。只查看主要路由表，可能會漏掉核心建立的策略路由。

Android 與 iOS：使用系統 VPN 授權

Android 上支援此功能的用戶端通常會透過 VpnService 接管流量。點選連線後，請允許系統 VPN 要求，並確認「分應用程式代理」沒有排除要測試的應用程式。電池背景執行限制可能導致鎖定螢幕後中斷連線；「一律開啟 VPN」與「封鎖未使用 VPN 的連線」則是額外的系統策略，應先確認基本連線穩定後再啟用。

iOS 與 iPadOS 請選擇支援相應設定格式的用戶端，並透過系統 VPN 設定授權啟動網路延伸功能。桌面版安裝驅動程式或取得管理員權限的步驟不適用於行動裝置。行動版應用程式可能自行管理路由與 DNS，甚至忽略桌面版的 tun 欄位，請以其支援的設定範圍為準；系統 VPN 已連線，也不代表訂閱中的所有規則都相容。

確認流量接管：分別檢查入口、DNS 與出口

開啟網頁只能證明某條連線可用，無法證明 TUN、DNS 與規則都依預期運作。請依照以下順序測試，每次只變更一項條件，並記錄應用程式、目標網域、命中規則及實際出口。

1. 測試未設定代理參數的應用程式。關閉系統代理，清除終端機的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 等環境變數，再執行以下命令。連線應出現在用戶端記錄中。
2. 測試核心 DNS。查詢本機 1053 連接埠並確認回應結果。Fake-IP 模式下，未經過濾的一般網域通常會取得 198.18 網段的位址。
3. 測試系統 DNS。直接執行系統預設的 DNS 查詢，並搭配記錄確認是否經過核心。直接查詢 1053 成功，只能證明 DNS 監聽器正常，無法證明系統要求已遭劫持。
4. 檢查規則出口。分別連線至預期直連與預期代理的目標，確認連線記錄中的規則與策略群組。不要把「進入核心」誤認為「使用代理節點」。

# Windows PowerShell：先確認目前工作階段沒有代理環境變數
Get-ChildItem Env: | Where-Object Name -Match 'proxy'
curl.exe --noproxy "*" -I https://example.com
nslookup example.com

# macOS / Linux：curl 的 --noproxy 會略過明確設定的代理，但不會略過 TUN
curl --noproxy '*' -I https://example.com
dig @127.0.0.1 -p 1053 example.com A
nslookup example.com

若未安裝相關工具，不必為了執行命令而變更系統，也可改用用戶端的 DNS 查詢功能。測試 UDP 時，請選擇已確認支援 UDP 的節點與應用情境；一般 HTTPS 網頁連線成功，不代表遊戲 UDP 或 QUIC 可正常使用。

常見問題：依序排查權限、路由與 DNS

一開始不要盲目加入 strict-route

部分 mihomo 設定支援 strict-route，可用來加強路由限制，在某些平台也會影響 DNS 路徑。這可能改變區域網路、虛擬機器或其他 VPN 的連線能力。請先用最精簡的設定驗證，再依目前核心文件與實際需求新增；不要將它視為「代理更徹底」的通用選項。

關閉後仍無法上網時的復原方式

先在用戶端內關閉 TUN，讓核心正常移除路由，再結束用戶端。確認系統代理是否仍指向已停止監聽的 127.0.0.1:7890，並檢查 DNS 是否留有手動設定。接著重新連線網路；必要時可透過用戶端的服務修復選項復原。企業裝置請勿直接清空整個路由表，以免刪除辦公網路所需的設定。