Tailscale 與 Clash 同時開？【2026】TUN、區網繞過與路由優先

為什麼「第二條隧道」特別容易打架

Tailscale 會在作業系統上建立 utun（macOS／部分 Linux）或 wintun／類似介面（Windows），並將 100.64.0.0/10（Tailscale 常用的 CGNAT 空間）與您允許的子網路由掛進主機路由表。Clash 開啟 TUN 時，通常也會註冊另一張虛擬網卡、拉高攔截範圍，並透過 auto-route 一類選項把「預設出囗」往代理堆疊送。

問題不在於誰比較好，而在於兩套軟體都在同一張路由表上寫規則：若 Clash 把本應走區網交換器或實體 Wi‑Fi 出口的流量拐進隧道，您會覺得「區網突然變成在國外繞一圈」；若預設路由或更明細的前綴被後寫入的程式覆蓋，則可能出現偶發斷線、特定網段只剩下單向封包。解法不是關掉其中之一，而是明確劃出：哪些前綴必須維持在本機區網介面、哪些必須留在 Tailscale、哪些才交給 Clash 依規則轉送。

心智模型

把 Clash 想成「應用層策略裁判」，把 Tailscale 想成「第三層專用疊加網路」。路由表是共享白板；誰寫了更明細的 destination／mask 與較低的度量（metric），作業系統就偏向用那條路。

先對症狀分桶，再動設定

請先在紙上或備忘錄把現象分類，避免同時改三個面板後無法還原：

僅 RFC1918 區網壞掉（192.168.x、10.x、172.16–31.x）：優先檢查 Clash 是否把私有位址也納入 TUN，以及 bypass-private-network 是否開啟。
僅 100.x 或 MagicDNS 主機名失敗：多半是 Tailscale 路由沒有比 Clash 更明確地勝出，或 TS 介面被 Clash 錯誤地當成「要轉送給代理」的閘道。
全機斷線或只有瀏覽器能開：可能是預設路由、DNS 或一條過寬的 MATCH 規則；請交叉比對本站的 DNS 與 fake-ip 排查。

第一步：收斂 Clash／Mihomo 的 TUN 邊界

在 Clash Meta／Mihomo 系核心中，tun 區塊是最常與 Tailscale 交叠的地方。實務上您會希望：

私有網段不要硬進代理堆疊：啟用 bypass-private-network: true（或依您核心版本的對應開關），讓 RFC1918 與常見區網目的地的下一跳維持在實體介面。
排除 Tailscale 介面：若核心支援以介面名稱排除，將 Tailscale 使用的介面（例如 macOS 上常見的 utun 系列、或狀態頁上顯示的名稱）列入排除清單，避免 Clash 對該介面再做二次封包決策。
謹慎使用 strict-route：strict-route 能把「泄漏」減到最小，但在多 VPN 併存時也最容易把本該直連的細目的地誤導向錯誤介面；調整時請一次只改一個旗標，並準備好還原。

以下為示意組態，實際鍵名請以您使用的核心版本文件為準；註解一律使用英文以利版本控制與搜尋。

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  # Keep RFC1918 off the Clash tunnel when possible
  bypass-private-network: true
  # Example only — replace with your Tailscale interface from `ifconfig` / `ip link`
  exclude-interface:
    - utun4

Windows 上若使用 Clash for Windows、Clash Verge Rev 等前端，往往有等價的「繞過私有網路」或「排除介面」勾選項；概念相同。首次建議依 Windows 安裝與 TUN 基底或 macOS Verge Rev 權限流程先把單一 TUN 跑穩，再疊加 Tailscale。

別在同一輪排查裡混用兩種「全域模式」

若 Clash 暫時切到 Global、Tailscale 又開著 Exit Node，等於把診斷變因乘起來。請回到 Rule 並保留最小可重現路徑。

第二步：校準 Tailscale 側的子網與 Exit

Tailscale 不只是一條「加密管道」；當您啟用子網路由器（subnet router）、Exit Node 或分割 DNS 時，它會在路由表中加入額外前綴。與 Clash 並存時，請逐一確認：

是否需要 --accept-routes：若網內有人廣播區網前綴，客戶端必須同意學習這些路由；否則症狀會像「只有部分裝置 ping 不到」。
Exit Node 是否必要：Exit 會把預設網際網路出口改到遠端；此時若 Clash 也想接管預設路由，衝突會最大化。除錯錯誤時可先關閉 Exit，專心讓區網與 100.x 互通。
MagicDNS 與本機 DNS 轉發：若 Clash 使用 fake-ip，而 Tailscale 依賴私有 DNS 名稱，請確保兩邊的 upstream 鏈路不互相短路；細節仍建議對照 fake-ip 專文分段測試。

同類 mesh VPN（例如自建 Headscale、其他 WireGuard 網實作）在「會寫路由表」這點上與 Tailscale 類似，本文步驟同樣適用，只是介面名稱與管理後台用詞不同。

第三步：用系統路由表驗證「誰贏了」

當 GUI 看不出結果時，路由表是最誠實的裁判。

Windows：以系統管理員開啟終端機，執行 route print -4，檢查清單頂端與您區網、100.64.0.0/10 相關項目的 Metric。較小值通常優先；若 Clash 或 VPN 介面的度量異常地低，可能壓過實體閘道。
macOS／Linux：使用 netstat -rn -f inet 或 ip route，檢查 default 與細前綴的 interface 欄位是否指向預期的 en0、wlan0、Tailscale 介面或 Clash TUN。

若您發現「預設走 Clash，但 192.168.1.0/24 仍莫名其妙進隧道」，回到上一節確認 bypass-private-network 是否生效；若根本沒有產生對應前綴，則要懷疑是否有第二支程式（企業 VPN、外掛防火牆）在清理路由。

觀察欄位	健康狀態的直覺
區網前綴 → 介面	應落在實體 LAN／Wi‑Fi，而非 Clash TUN（除非您刻意要鑽隧道）
`256:100:…` 之類位址線	比對 Tailscale 文件版本的位址族，確認仍在 TS 介面上轉發
預設路由 metric	單一清晰勝者；輪替或重複預設通常是斷線前兆

第四步：固定排查順序（減少「隨機修好」）

關閉 Exit Node 與全域覆寫類選項，僅保留「內網／100.x」必要路由。
在 Clash 開啟 bypass-private-network，必要時排除 Tailscale 介面。
重新載入 Mihomo／重啟前端，執行 route print 或 ip route 拍照備份。
測試：區網 IP ping、NAS SMB、Tailscale ping 另一節點的 100.x。
最後才調 DNS、規則集與 MATCH；若需 TUN 進程規則，可比照 Steam／Epic TUN 進程分流的「規則順序」段落。

這套順序與 WSL2 與宿主 Clash 文中「先確認宿主路由，再談子系統」的精神一致：共享宿主網路堆疊的元件，一定要先對齊平台路由與介面綁定，應用程式層的 YAML 才有意義。

常見問題

開 Clash 後 NAS 名稱解析得到怪 IP

可能是 fake-ip 或規則提前攔截了本機 DNS 請求。請暫時對區網主機使用明確的 IP 測試；若 IP 通而名字不通，就集中火力在 DNS 鏈路而非 TUN 堆疊。

印表機只在關掉 TUN 時可用

典型是廣播／多播與二層探索被虛擬介面打斷。開啟私有網路繞過、確認列印伺服器的 IP 走實體區網。若印表機 App 強依賴 bonjour 名稱，可評估把該名稱的解析改到不經 fake-ip 的查詢路徑。

我用 Headscale，還要看 Tailscale 介面名稱嗎？

要。Headscale 替換的是控制面，資料仍走 WireGuard 系實作；作業系統上仍會出現 utun／tailscale0 類名字，Clash 排除介面時請以 ifconfig 實測為準。

小結

Clash 與 Tailscale 並存的本質，是把私有前綴、mesh 前綴與「需要分流的公網」分開裁判。先把 TUN 邊界與路由度量穩下來，您的規則集、節點測速與應用程式進程規則才會回到可預期的狀態。

立即免費下載 Clash，在可用的網路基線上疊加分流

Tailscale 與 Clash 同時開總衝突？TUN、區網繞過與路由優先順序逐步修復