進階設定 閱讀時間約 12 分鐘

Clash TUN 模式設定

從虛擬網卡與路由表說明 TUN 模式和系統代理的差異，並介紹 stack、auto-route、dns-hijack 設定及各桌面平台的啟用方式。

TUN 接管流量的運作流程

Clash TUN 模式透過虛擬網路介面接收 IP 封包，再由核心辨識連線、比對規則並選擇出口。適合不會讀取系統代理設定的程式，例如部分命令列工具、遊戲，以及自行建立網路連線的桌面應用程式。啟用前請先確認用戶端使用的核心支援 TUN；用戶端名稱相同，不代表不同發行版本採用相同核心或權限設定。

本文以 Clash Meta 後續發展的 mihomo 為設定基準。原版 Clash、舊版 Premium 核心及其他分支支援的欄位可能不同。請先在用戶端的核心資訊或啟動記錄中確認實際使用的核心，再依照對應文件檢查設定；不能只因介面上有「TUN」開關，就認定所有欄位都能生效。

  1. 應用程式發起連線：作業系統依目標位址查詢路由表。
  2. 路由導向虛擬介面：符合接管條件的封包會進入 TUN，而不是直接經由實體網卡送出。
  3. 核心執行分流：依據網域、IP、程序等規則，選擇代理、直連或拒絕。
  4. 連線抵達出口：代理連線仍須經過實際網路介面；核心必須避免自己的對外連線再次送回 TUN。

TUN 與系統代理的差異

系統代理通常會將 HTTP 或 SOCKS 入口提供給支援這些設定的應用程式。以本機 127.0.0.1:7890 為例，只有主動使用該入口的連線才會交由核心處理。TUN 則透過網路介面與路由運作，應用程式不必知道這個代理連接埠。

比較項目系統代理TUN 模式
連線方式應用程式連線至本機代理監聽連接埠系統路由將封包送入虛擬介面
應用程式相容性需由應用程式支援系統代理或手動設定代理通常可涵蓋不讀取代理設定的應用程式
UDP 流量一般 HTTP 系統代理無法直接處理可以接管，但出口協定與節點也必須支援
權限需求通常不需要建立網路介面的權限需要建立介面及調整路由的權限
常見衝突應用程式內建代理、代理環境變數其他 VPN、虛擬網卡、路由重疊與 DNS 接管

「全局流量」只是方便理解的說法，並不保證一定能全部接管。既有連線、未被接管的 IPv6 路徑、其他 VPN 的優先路由，以及特定平台限制，都可能影響實際涵蓋範圍。請先確認要接管哪些應用程式，再透過連線記錄驗證，不能只看開關是否啟用。

初次排查時，建議先關閉系統代理，只啟用 TUN，以減少變因。兩者可以同時使用，但若一起開啟，瀏覽器能正常連線並不能證明 TUN 運作正常，因為瀏覽器可能仍透過系統代理連接埠連線。

啟用前先確認三件事

先確認代理出口可用

先透過系統代理正常連線一次，確認訂閱已匯入、策略組有可用節點，且規則沒有引用不存在的策略名稱。節點連線失敗、訂閱內容為空或驗證錯誤，都不會因啟用 TUN 而自動修復。排查時請保留原始設定備份，每次只調整一類參數。

確認服務權限與網路環境

  • Windows：建議優先使用用戶端提供的服務模式。以系統管理員權限安裝服務後，由服務管理核心執行；不必將所有日常使用的應用程式都提升為系統管理員權限。
  • macOS：用戶端可能透過輔助程式取得網路管理權限。請依系統提示授權，並確認安全軟體沒有阻止介面建立。
  • Linux：建立 TUN 裝置與修改路由通常需要 root 權限或適當的網路管理權限。容器也必須能存取 /dev/net/tun；單純提高程序權限不一定足夠。

暫時停止其他隧道

請先中斷其他 VPN、遊戲加速器及同類代理用戶端。企業 VPN 和虛擬機器網路不一定非得關閉，但初次驗證時應盡量簡化環境。若必須同時使用，後續應比較路由前綴與優先順序，而不是讓兩個用戶端反覆覆寫預設路由。

mihomo TUN 設定範例

以下是合併至現有設定的片段，不是包含節點的完整訂閱。請保留既有的 proxies、proxy-groups 和 rules。如果原始檔案已有 tun 或 dns，請修改原有段落，不要在相同層級重複加入同名鍵。

mixed-port: 7890
mode: rule
log-level: info

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://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

stack：選擇封包處理方式

mihomo 常見的值有 system、gvisor 和 mixed。system 使用與系統網路堆疊相關的實作；gvisor 使用使用者空間網路堆疊；mixed 通常由 system 處理 TCP、gVisor 處理 UDP。實際支援情況取決於平台與核心建置版本。

初次設定可先沿用用戶端預設值，範例採用 mixed。只有在重現特定連線問題後，才切換堆疊並重新啟動核心測試。不同堆疊並非效能排名，不能宣稱某一種在所有裝置上都比較快。

auto-route 與出口介面

auto-route: true 會讓核心自動建立接管流量所需的路由，但無法取代管理員授權。auto-detect-interface: true 用於自動辨識對外連線的介面，協助代理流量避開自身隧道。若 Wi-Fi、有線網卡與 VPN 同時存在，仍應確認辨識結果是否正確。

如果只有在休眠喚醒或切換 Wi-Fi 後才斷網，請先重新啟動核心，讓它重新辨識出口，再檢查路由。不要急著將實體網卡位址固定寫入設定；切換網路後，固定的介面名稱可能失效。

dns-hijack 與 DNS 監聽連接埠

any:53 用於接管進入 TUN 的一般 UDP DNS 請求，tcp://any:53 則涵蓋對應的 TCP DNS 請求。這兩項設定會將符合條件的請求交給核心 DNS 模組處理，不要求系統 DNS 伺服器位址必須是 127.0.0.1:1053。

listen: 127.0.0.1:1053 則是 DNS 模組額外提供的本機監聽入口。這與 mixed-port: 7890 用途不同，不能把 7890 當成 DNS 連接埠。應用程式內建的 DoH、DoT 不屬於一般 53 連接埠 DNS，無法只靠這兩條劫持規則直接攔截。

Windows、macOS 與 Linux 啟用步驟

Windows：先啟動服務，再啟用 TUN

  1. 在用戶端設定中確認使用支援 TUN 的 mihomo 核心，並完成訂閱連線測試。
  2. 找到服務模式或服務管理入口，依照提示安裝並啟動服務。不同用戶端的選單名稱可能不同，請以目前介面為準。
  3. 啟用 TUN，檢查記錄中是否出現權限、介面建立或新增路由的錯誤。
  4. 開啟「設定」→「網路和網際網路」→「Proxy」，暫時關閉手動代理，排除瀏覽器仍透過系統代理連線的影響。
  5. 使用 PowerShell 檢查網路介面與 IPv4 路由，再建立一筆新連線。
Get-NetAdapter -IncludeHidden
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object DestinationPrefix, RouteMetric
curl.exe --noproxy "*" -I https://example.com/

--noproxy "*" 會讓這次 curl 請求不使用明確指定的代理，但不會繞過 TUN 路由。範例網址僅用於連線檢查；成功連線後，還要在用戶端連線清單中確認該請求所套用的規則與出口。部分隧道介面不一定會完整顯示在網卡清單中，請搭配路由與記錄判斷。

macOS：完成授權並檢查路由

  1. 透過用戶端的設定入口安裝或啟用所需的輔助程式，並完成系統權限確認。
  2. 關閉其他 VPN 後啟用 TUN。開啟「系統設定」→「網路」，檢查是否有其他網路隧道同時啟用。
  3. 若要排除系統代理的影響，請在目前網路服務的「詳細資訊」→「代理」中檢查 HTTP、HTTPS 和 SOCKS 代理設定。
  4. 在終端機檢查介面與路由，再對照用戶端連線記錄進行測試。
ifconfig
netstat -rn -f inet
route -n get 1.1.1.1
curl --noproxy '*' -I https://example.com/

macOS 常見的虛擬介面名稱包含 utun，但其他系統服務也可能建立這類介面。只看到一個 utun，不能證明它屬於目前使用的用戶端。請比較啟用前後的變化，並確認測試目標實際使用的路由。

Linux：檢查裝置、權限與策略路由

圖形介面用戶端通常會提供權限提升或安裝服務的流程。直接執行核心時，請先檢查設定語法，再透過已設定好的系統服務啟動。不要為了快速測試，讓一般應用程式或整個使用者目錄取得過寬的權限。

mihomo -t -f config.yaml
test -c /dev/net/tun && echo "TUN device available"
ip link show
ip rule show
ip route show table all
curl --noproxy '*' -I https://example.com/

mihomo -t 主要用於確認設定是否能解析，無法證明執行時已取得路由權限。Linux 也可能使用策略路由表，只查看主路由表可能會漏掉接管規則，因此還要一併檢查 ip rule 與所有路由表。

驗證流量接管、DNS 與 UDP

有效的驗證需要分層進行。網頁能開啟，只能代表某一條連線路徑可用，無法證明 DNS、UDP、IPv6 以及所有應用程式都如預期運作。建議依照以下順序逐步確認。

  1. 介面層：比較啟用前後的虛擬介面與路由，確認沒有持續出現錯誤。不必要求所有平台都顯示完全相同的介面名稱或預設路由項目。
  2. 連線層：關閉系統代理，使用帶有 --noproxy 的 curl 建立新連線，並在用戶端連線清單中找到對應請求。
  3. 規則層：確認符合的規則與策略組。符合 DIRECT 是分流結果，不代表 TUN 自動失效。
  4. DNS 層：查看 DNS 記錄，區分一般 53 連接埠請求、應用程式的加密 DNS 與既有快取。
  5. UDP 層：使用確實會發出 UDP 封包的應用程式測試，同時確認所選節點與協定支援 UDP 轉發。TCP 測試成功不能取代 UDP 測試。

使用 Fake-IP 時，部分被接管網域的解析結果可能是 198.18.0.0/16 範圍內的映射位址。這是該設定的預期行為，並非網站的實際公網位址。被過濾的網域、使用獨立加密 DNS 的應用程式，以及命中快取的請求，結果可能不同。

啟用 TUN 後無法連線的排查順序

狀況優先檢查處理方式
開關啟用後立即跳回服務狀態、建立介面的權限、設定解析記錄先修正權限或語法錯誤，再重新啟動核心
網域無法開啟DNS 上游連線、DNS 模組與接管記錄確認 53 連接埠請求是否進入核心，並改用可連線的上游
瀏覽器正常，其他應用程式失敗確認瀏覽器是否仍在使用系統代理關閉系統代理後重新測試，核對目標應用程式的連線記錄
網頁正常，遊戲無法連線UDP 出口能力、策略組、應用程式錯誤碼改用確認支援 UDP 的節點，逐項找出問題
連線反覆逾時其他 VPN 路由、出口介面、代理迴圈停用互相衝突的隧道，重新辨識出口並重啟核心
休眠或切換網路後失效確認是否仍在使用舊介面與舊路由重新啟動核心，比較恢復前後的路由與記錄

如果無法連線至區域網路印表機、NAS 或路由器管理頁面，請先查看目標私有位址符合的規則。如果流量被送往代理出口，請依實際網段新增直連規則；若已直連仍無法使用，再檢查區域網路路由與防火牆。不要直接將所有內網問題歸咎於 Fake-IP。

調整規則只能解決出口選擇問題。如果封包根本沒有進入核心，新增網域規則也不會有作用；如果代理節點本身無法連線，反覆切換 stack 同樣無法修復節點。建議記下「具體應用程式、目標、符合的規則、錯誤記錄、是否啟用其他 VPN」這五項資訊，再進行下一次調整。

訂閱更新與退出後還原

部分用戶端會將 TUN 開關儲存為本機設定，另一些則會將介面選項合併至執行中的設定。編輯訂閱檔案後，遠端更新可能覆寫修改內容。請使用用戶端支援的覆寫、合併或持續保存設定功能，並在更新後查看實際生效的設定，而不只是檢查編輯器中儲存的片段。

停止使用時，請先關閉 TUN，再正常退出用戶端，讓核心清除自動建立的路由。若程序異常結束後網路仍不正常，可重新啟動用戶端，再關閉 TUN 完成清理，同時檢查是否留下系統代理設定。不要在不清楚來源的情況下大量刪除系統路由。

  • 只需要代理瀏覽器流量：系統代理通常更容易設定與排查。
  • 需要接管不支援代理的應用程式：啟用 TUN，並驗證路由與連線記錄。
  • 需要同時使用多個 VPN：先確認各自接管的位址範圍，再規劃規則與路由。
  • 需要進一步排查問題：查看故障排除；基本匯入與模式設定請參閱Clash 設定教學。
下載 Clash 用戶端