Tailscale 與 Clash 並存：路由與 DNS 分步核對（2026）

讀完本篇你能獨立完成什麼

你會拿到一套可複製的工作流：先隔離變因判斷是 Tailscale 在改預設路由／出口，還是 Clash 的 TUN 或繞過大陸／GEOIP在吃流量；再在作業系統讀出目前生效路由表與DNS 查詢順序；隨後在 Clash 設定裡前移針對 Tailscale 位址空間與 subnet routing 回程網段的直連規則，避免整段 mesh 被撞進全域代理或不適合的策略組；最後單獨驗證 MagicDNS 後綴與 Clash DNS 段落是否互相打架。文末有一段可照著勾的簡短清單，適合邊改邊記在紙上，而不是在社群串文裡隨機搜關鍵字試錯。

為什麼會出現「上不了網／國內走錯隧道／解析怪怪的」

第一，Tailscale 一旦啟用全網出口／Exit Node或使用某些「讓本機看起來像在別的網路」的選項，等同有人往系統路由表塞進新的預設或較高優先順序的前綴；而 Clash 若在 TUN 模式下同樣接手預設路由語意，兩邊就有機率先後順序不穩定——表現是「重開機後變好」「睡眠喚醒又壞」，本質常是誰晚啟動誰蓋掉誰，而不是玄學。

第二，subnet routing（子網路由通告）會把公司區網、機房網段、家用路由器後面的 /24從另一個節點「拉」到你的機器上。若 Clash 規則過於強硬（例如 GEOIP 非 CN 一刀切進代理），這些本該走 Tailscale overlay 的封包可能被錯誤塞進某個海外節點再繞回來，輕則延遲爆表，重則直接黑洞。站內國內直連與 GEOIP 核對清單能幫你看規則順序是否正確，但本篇額外強調：Tailscale 帶進來的是「第二張網」，要在規則裡為它單獨開一支。

第三，MagicDNS 會在你的 tailnet 提供一套可讀的機器名後綴解析；當它疊到系統內建解析器、路由器 DNS、瀏覽器 DoH 與 Clash 的 nameserver-policy 之上，常見症狀是：dig 或系統解析器看到的是一串與 Clash fake-ip 不相容的中間結果，而應用在連線階段卻拿著占位位址亂撞。別把這類問題誤判成分流順序；先釘死 DNS 敘事，再回到規則。

第一步：關掉「二分法」，用隔離變因拆開 Tailscale／Clash

真正省時間的做法，是永遠只做一組對照：先暫停 Exit Node與「強制所有流量經由 Tailscale」（各客戶端文案略不同）；再暫時把 Clash 從 TUN 切成規則較保守的系統代理或直接關掉核心接管，只用瀏覽器可驗證的層級檢查出站是否恢復。若這樣能立刻正常，你已證明衝突集中在預設路由爭搶而不是遠端節點品質。

反之，若在「只開 Tailscale、不開 Clash」下存取 tailnet 內服務正常，一開 Clash 立刻異常，十有八九是 Clash 沒有為 Tailscale 使用的位址族放夠前面的 DIRECT／專用策略。此時不要急著重寫整份 YAML，請先往下看第三步的網段與白名單寫法；需要網域粒度時對照自訂規則教學把例外前移。

第二步：讀出「是誰在寫路由表」（比猜圖示開關可靠）

在排查階段，請務必開終端機看實際路由結果，而不是只靠系統匣圖示。Windows 可用 route print 或 Get-NetRoute 觀察預設路由是否出現重複的 0.0.0.0、較低的度量值，或預料介面以外的路徑。macOS 與桌面 Linux 則用 netstat -rn 或 ip route／ip -6 route，盯住 default 與指向 utun／tailscale 類介面的路徑。

若你看到兩套預設出口各自指向 Tailscale 虛擬介面與 Clash 虛擬網卡，接下來要在不改變各自功能目標的前提下，想清楚業務優先權：哪些前綴必須永遠不經 Clash 策略堆疊（典型是 tailnet／子網回程），哪些可以交給 Clash 做 GEOIP但要注意順序。這不是「選一個關掉另一個」的假議題，而是用更細的前綴消掉歧義。路由表在這裡只是物證鏈：它告訴你系統在送出封包前到底想把封包交給哪張網路卡。

第三步：在 Clash 裡為 Tailscale／子網放回「直連快車道」

實務中最常見、也最容易被遺忘的一條，是替 Tailscale配置的 IPv4 空間與文件列出的IPv6 ULA前綴寫上直連規則，並排在 GEOIP 或「FINAL→PROXY」等大規則之前。原因很單純：這些目的地本該在加密封裝層以內完成選路；你若交給遠端代理節點，等同讓根本不知道你 tailnet 拓樸的主機代為決定下一站。

同時，一旦你在 tailnet 開啟 subnet routing，請把通告端聲明給 mesh 的子網前綴（例如某公司 10.0.0.0/8 片段、庫房 192.168.x.0/24）逐條記在紙上，再在 Clash 裡以IP-CIDR／IP-CIDR6放進 DIRECT 或你要的區網專用策略組。Tailscale 管理後台裡路由是否已核准、用戶端是否接受，也要與實體網路是否可達分開理解：核准了路由≠你的 Clash 規則不會攔截。

若你希望「區網／專網語意」更清楚，可把相關前綴整理成獨立的 rule-provider 或 RULE-SET，用版本管理維護——但入門階段用顯式前綴就夠把大問題砍到十分之一；細節語法仍以你手上的 Mihomo／Meta 核心文件為準。分流例外是否生效，請以 Clash 連線日誌裡的目的 IP與選中策略組為準，而不要只看儀表板延遲數字。

第四步：MagicDNS 與 Clash DNS 對齊，避免「三套解析故事」

當你在瀏覽器輸入帶 MagicDNS 後綴的主機名，請求路徑可能是：作業系統 stub → 路由器 → Tailscale 注入的上游；而同機的 Clash 若啟用攔截 DNS／TUN 級 DNS 轉向，會再裁切一遍。若要和純 Linux 場景的 systemd-resolved 專文對照，可看Linux 端 resolved 與 Clash DNS 分步核對的思路：核心是只保留一層「對外發問」的真相來源，其它層只做快取或封裝。

若你使用 fake-ip，要確保 tailnet後綴、mDNS／.local、公司與家庭分割 DNS（split horizon）相關後綴出現在合適的 fake-ip-filter 或等效略過名單；否則核心會給應用一串占位位址，而應用在 TLS／HTTP 層的 SNI／Host 仍指向真實主機名——這種「半真半假」非常像DNS 壞了，其實只是兩套 fake 語意打架。

快速驗收建議：在同一個終端機對出問題的主機名跑明文解析指令（隨系統而異），再開一個僅經 Clash 上游的解析探測（若你的客戶端提供），比對 CNAME／AAAA 鏈是否分叉；分叉點在哪，就在那裡收斂設定。盡量不要把 MagicDNS與遠端 DoH（經過代理）串成一圈「繞圈圈」鏈路。

第五步：TUN／系統代理模式下與 Windows 宿主機的特例

不少讀者在 Windows 11 上同時用兩者：Tailscale GUI 勾出口，Clash Verge／同類客戶端開 TUN。此時除了路由，還要順手確認允許區網／allow-lan、WFP 篩選與 Defender 防火牆對虛擬網卡類別的影響——當你在 tailnet 存取兄弟主機時，SYN 可能因本機出站被錯誤分類而被擋。可先讀Windows 11 首次安裝與斷網排查與區網代理與防火牆，把宿主側鏈路跑通後再回頭看 Tailscale 疊加。

若你還有 WSL2、Hyper‑V VM、Android 模擬器等第二層 NAT 世界，請參考站內WSL2 共用代理與Hyper‑V 閘道教學，始終把「宿主可達性」與「tailnet／子網路由」分開寫進筆記：否則工單只寫「上不了網」，工程師看到的卻是五層拓樸同時存在。

第六步：Docker／Linux Server 場景：誰是「宿主」、誰在容器裡反問 DNS

在伺服器上只讓 Tailscale 對宿主機入網時，常見反面是 docker0／bridge 後面的容器仍照預設閘道出去，與你的 tailnet 策略無關；可一旦在宿主設了 iptables／nft 或 Clash 的TUN 轉送，就要查回程（reverse path）是否不對稱。若在容器裡反問 MagicDNS，而容器內建 /etc/resolv.conf 仍指向宿主 stub，可能出現與宿主完全不同的 NXDOMAIN行為。

這類問題請先回到第二層原則：每個網路命名空間裡，只允許一條解析故事。需要把宿主 tailnet轉送給容器網路時，應明寫DNS 伺服器與閘道，而不是指望 Clash 自動「猜到你的 mesh 拓樸」。與Docker Desktop 與宿主對齊一文類似：代理與組網各管一層，混談就浪費時間。

一份可勾選的分步核對清單（建議列印）

路由層：Tailscale 是否啟用 Exit／等效全隧道能力；關掉後是否瞬間恢復？路由表預設出口是否唯一且符合預期？subnet routing 核准後，無 Clash 時能否 ping 通子網閘道？

Clash 規則層：Tailscale 典型 IPv4 空間與 ULA IPv6 前綴是否前移直連？通告的子網前綴是否整段放行到 DIRECT／專組？GEOIP／FINAL 等大規則是否太晚才看到直連例外？對照GEOIP／繞過大陸核對時，別把 tailnet誤判成「他國」。

DNS 層：MagicDNS 開關是否對症狀有幾乎二元的影響？瀏覽器 DoH 與系統／Clash 上游是否各說各話？fake-ip-filter 是否漏了 tailnet 後綴？逐項只改一檔，複述一次誰在問誰。

宿主雜項：防火牆／WFP 是否把虛擬網卡當公用網路；WSL／VM 是否需另寫靜態路由或 Proxy 環境變數。Tailscale ACL與管理員核准路由只是「遠端策略允許」，並不代表本機 Clash會自動禮讓。

典型症狀一頁對照（快速歸因）

A. 只有 MagicDNS 後綴打不開，改成 IP（若你知道）卻可以：優先當 DNS 鏈路。B. 只有啟用 Exit Node／等效全隧道後國內變慢：預設路由語意問題。C. 只有開 Clash TUN 後存取 tailnet 失敗：多半是沒把 overlay 前綴前移直連。D. 瀏覽器正常、CLI 怪怪的：多半是不同工具走了不同解析器／Proxy 環境變數，對齊終端機與桌面工作階段。

安全、合規與現實邊界

請在你有權設定的裝置上使用 Tailscale／Clash，並遵守公司及所在地合規要求。Exit Node 可能把出站流量轉到受託友人或家庭頻寬，既牽涉法律責任也可能違反對方 ISP 條款；請勿把他人節點當匿名跳板。本文不涉及破解、規避監管或攻擊用途，僅描述自用裝置共存排錯；若你想了解 Clash核心與社群的公開維護狀態，可在正文之外自行查閱開源倉庫與發行說明。安裝包分發仍以本站下載頁作為一般讀者的主入口。

小結

Tailscale 改的是你和 mesh／子網的拓樸關係與路由事實，Clash 改的是在既定五元組上如何選節點；兩者疊乘時最大的坑，是用過粗的規則尾部把本該走 overlay／專網前綴的流量誤判進代理。先做路由表取證，再做 MagicDNS／系統 DNS／Clash DNS 的單一路徑收斂，最後用前置直連例外落實 subnet routing 與 Tailscale 常見位址空間的 DIRECT 語意，就能把「玄學斷網」壓成可逐項勾掉的工程問題。

若你已習慣用規則客戶端把流量拆細，並希望從本站取得維護積極的發行版與可讀教學鏈路，可走下載頁搭配總覽教學建立自己的「網路變更日誌」。相較零碎論壇串文式試錯，把這種組網 + 分流場景寫成一頁核對表，長期更省事。→ 立即免費下載 Clash，開啟流暢上網新體驗。