1 典型症狀與搜尋意圖
若您已用 Tailscale 把家裡 NAS、遠端伺服器或同事電腦掛在同一張虛擬網，同時又在本機開 Clash（多為 TUN 或系統代理＋本機 DNS），很常出現這幾類現象：一般上網突然不穩，但關掉其中一邊又恢復；能 ping 到某些 100.x 主機，卻打不開瀏覽器裡的常用站；或 MagicDNS 機器名昨天還能解析，今天卻變成查無此主機；進階使用者會在日誌裡看到封包在 Clash 與實體介面之間來回打轉，懷疑「流量環路」。
這類搜尋意圖很明確：不是放棄其中之一，而是希望兩套工具能並存——Tailscale 照樣組內網，Clash 照規則分流或走代理，且路由表與 DNS 解析不要互相覆寫。實務上最有效的心法是「先路由、後 DNS」：若預設閘道與細部目的網段送往錯誤介面，後面再怎麼調 nameserver-policy 也會像在霧裡修車。站內企業 VPN 與 Clash 分流一文偏重企業 SSL VPN 與分割通道，本文則鎖定 Tailscale 與 Clash 同時改寫系統狀態時的優先順序與排查步驟。
建議先只動一個旋鈕做對照：例如暫時關閉 Clash TUN、或暫停 Tailscale，確認症狀跟誰綁在一起，再回頭優化「並存」設定；比同時改三份 YAML 更容易收斂。
2 為何兩套工具疊加容易出問題
Tailscale 會在作業系統內新增虛擬介面與主機路由（典型含 100.64.0.0/10 這類 CGNAT 位址空間），並可能透過管理後台啟用 MagicDNS，讓 *.ts.net 這類名稱在內建解析器有一份答案。另一方面，Clash／Mihomo 在 TUN 模式時常會建立較高優先序的預設路由，讓「未指定」的 IPv4 流量先進核心；同時若開啟 DNS 劫持（或搭配 FakeIP），應用程式向系統發出的查詢會被導到本機埠，由核心再決定上游。
兩邊同時存在時，作業系統必須在多張路由表項目中挑一條「最適合」的路徑，且解析器鏈也要決定先問誰。若 Clash 把預設流量全拉進 TUN，卻沒有正確繞過（bypass） Tailscale 相關網段，可能出現連線被送到「代理鏈」或錯誤閘道；若 MagicDNS 與 Clash 的 DNS 模組各說各話，則同一個網名在不同 App 裡會得到不同 IP，規則匹配就對不起來。這些都不是單一設定「壞掉」，而是優先順序沒對齊的典型結果。
0.0.0.0/0，以及系統是否同時存在多個預設路由。「DNS 劫持」指 Clash 把系統 DNS 查詢改導到本機監聽位址；與惡意軟體無關，本文僅討論使用者自願啟用的客戶端行為。
3 建議排查順序總覽（可列印）
下列順序刻意與多數論壇「先貼設定檔」相反，目的是把觀察得到的系統狀態放在第一位，避免在錯的基底上調規則。
- 凍結變因：記錄現象（哪個 App、IPv4／IPv6、Wi‑Fi 或乙太網路），並各試一次「只開 Tailscale」「只開 Clash」「兩個都開」。
- 路由表：確認
100.64.0.0/10（或您環境中的 TS 網段）是否仍指向 Tailscale 介面；預設路由是否落在 Clash TUN；是否存在衝突的 metric。 - 系統 DNS 狀態：Windows 可用
ipconfig /all、PowerShell 的Get-DnsClientServerAddress；macOS 可用scutil --dns，檢視誰在列表最上層。 - MagicDNS：在 Tailscale 管理後台檢視是否啟用 MagicDNS、是否覆寫本機 DNS（Override local DNS）；暫時關閉或改分割 DNS 做對照。
- Clash 側：確認 TUN 的 stack、是否開 DNS 劫持、FakeIP 與
bypass／route-address是否涵蓋 Tailscale；必要時為100.64.0.0/10設DIRECT 規則並置於代理規則之前。 - 日誌與抓包：仍無解時再對照核心日誌與介面計數器，排查封包迴圈或上游節點問題。
4 第一步：路由表與「誰是預設閘道」
當您覺得「開 Clash 就像整條線掛掉」，第一件事不是改訂閱，而是確認預設路由是否被 TUN 介面拿走、而較明確的 Tailscale 路由是否仍在。一般會希望：100.64.0.0/10（或您帳戶實際使用的 CGNAT 範圍）優先走 Tailscale；其餘流量的預設路徑則依您要的「全局代理」或「規則分流」進入 Clash。若較明細的路由遺失，或 metric 讓 TS 流量誤上 TUN，就會出現單邊不通、延遲暴衝或TCP 重傳。
實務上請同時看IPv4 與 IPv6：有些人只處理了 IPv4 預設路由，應用卻走 AAAA 記錄出區，症狀會像「只有某些站怪」。若短期要收窄問題，可在客戶端或系統層暫時停用 IPv6做對照（確認後再恢復並正規處理）。
5 Windows：檢視路由與介面度量
在命令提示字元或 PowerShell 執行 route print -4，聚焦在「Active Routes」裡是否存在指向 Tailscale 介面的 100.64.0.0 這類網路，以及 0.0.0.0 預設路由的Interface 與 Metric。若您裝了多個虛擬介面，也可在 PowerShell 使用 Get-NetIPInterface 檢視 InterfaceMetric：數字越小越優先（此處語意請以當前 Windows 文件為準，重點是「別讓 TS 與 TUN 在預設路由上打架」）。
當 Clash 類客戶端以 TUN 接管時，常會插入較低 metric 的預設路由；若 Tailscale 子網或 Exit Node 相關路由被蓋掉，就需要在 Clash 設定裡為 TS 網段排除於 TUN（見後段「繞過」），或調整客戶端提供的「繞過 / Bypass」清單。若您剛從企業環境切換回家用機，亦可對照站內Windows 企業 VPN 與 Clash文，思考「哪些前綴一定要留在企業／TS 介面」。
6 macOS：服務順序、路由與 DNS 解析器
在 macOS 上，除了 netstat -rn -f inet 觀察 Kernel Routing Table，也常需要打開「網路」設定裡各服務的優先順序（拖曳列表）：確保不會誤把錯誤的介面擺在頂上而讓預設流量走錯隧道。對於 TUN／VPN 類介面與 Tailscale 同開時，若系統層對「預設路徑」的選擇反覆變動，症狀會像「一會兒能連、一會兒斷」。
DNS 建議用 scutil --dns 檢視多個 resolver 區塊：哪些搜尋網域走哪組 nameserver，往往一眼可看出 MagicDNS／本機／DHCP 的先後順序是否與 Clash 預期不同。若 Clash 使用本機監聽，但最上層 resolver 仍指向外部 DoH／公司內 DNS，就會落入「DNS 劫持排查」要處理的範疇。
7 第二步：MagicDNS 與覆寫本機 DNS
MagicDNS 讓您用簡短主機名存取帳戶內裝置，本質是一套與 Tailscale 控制平面協作的解析邏輯。若在管理後台啟用了覆寫本機 DNS（不同版本文案可能寫作 Override local DNS），客戶端會試圖讓系統優先採用與 MagicDNS 相容的設定；此時若 Clash 也在改寫系統 DNS 或自行指定上游，兩邊可能出現重覆改寫，結果是解析忽快忽慢、或特定網域永遠拿不到預期答案。
建議依序嘗試：① 在控制台暫停覆寫本機 DNS，僅保留 MagicDNS 名稱解析；② 若仍打架，暫時關閉 MagicDNS 做二分法；③ 確認是否需要分割 DNS（split DNS）——讓 ts.net 一類後綴走 TS，其餘仍交給 Clash 上游。具體可用選項以 Tailscale 當版管理後台為準；本文重點是把「誰覆寫了系統解析」列為獨立檢查項，而不是直接假設 Clash 設定有誤。
8 第三步：Clash 的 DNS 劫持、FakeIP 與解析鏈
在核心 YAML 中，dns.enable、listen、是否啟用 enhanced-mode（或等同選項）與fake-ip 範圍，會決定「應用程式眼中的 IP」與「核心實際連線」是否一致。當 FakeIP 開著時，若仍有程式繞過劫持、直接向公共 DNS 查真實 IP，規則可能以域名命中、連線卻以 IP 命中另一條，外觀就像分流錯亂。
建議與站內Meta 核心 DNS 防洩漏對照，確認 nameserver、fallback、nameserver-policy 是否把 MagicDNS 需要可達的上游留在正確順序；並在 TUN 模式下檢查客戶端是否提供「自行處理 DNS」選項與系統設定一致。TUN 模式指南則有助理解堆疊（system／gvisor 等）與實際抓取封包差異——有時問題不在規則，而在堆疊與本機路由互動。
9 在 Clash 規則裡繞過 Tailscale 流量
常見稳妥作法是：在規則集前段為 Tailscale 相關位址保留直連（DIRECT），再讓其餘流量依 GEOIP、網域清單等進入代理。片段上（概念示例，實際語法依您核心與設定版本為準）可思考「先MATCH TS CGNAT，再MATCH LAN，最後才代理」的順序；若客戶端支援 bypass 或 route-exclude 類設定，也可把 100.64.0.0/10、本機 子網路由（subnet router） 前綴一併列入，避免它們被 TUN 一起劫走。
若您使用 Exit Node，Tailscale 可能改寫預設路由；此時與 Clash 的「全局代理」目標更容易衝突。實務上可先關閉 Exit Node 確認症狀是否消失，再決定要保留哪一種預設路徑；兩邊都要「預設出網」時，通常需要非常小心地劃分前綴與例外，本文不宣稱單一配方適用所有帳戶稽核策略與裝置組合。
10 流量環路與「整條斷線」時的收斂策略
流量環路的典型成因，是封包從 TUN 出來後又被系統送回同一條路徑，或 DNS 查詢在兩個本地監聽之間互相轉送。若您觀察到 CPU 佔用升高、介面計數器狂漲但使用者體感無流量，可優先關閉其一客戶端確認是否立即停止；再逐一打開並只在一側保留「預設出網」與「DNS 覆寫」權限。
另一類「像斷線」其實是 DNS 卡死：能否 ping 8.8.8.8 成功但瀏覽器無法解析？若能，瓶頸在解析鏈；若不能，回到路由與防火牆。建議隨身準備一組離線速查表：Tailscale 狀態頁、Clash 日誌開關、以及本機 ipconfig／scutil 輸出，遇到問題時能比對「上次正常」與「現在異常」的差異 diff。
11 總結
Tailscale 與 Clash 同開時，多數「斷網感」來自路由優先順序與DNS 覆寫疊加，而不是單一程式壞掉。請習慣用「先核對路由表與介面 metric → 再核對系統 DNS 與 MagicDNS → 最後才調 Clash 規則與 fake-ip」的順序收斂問題；桌面 TUN 細節可持續參考TUN 模式指南與Meta 核心 DNS。在規則面，記得用直連保護 100.64.0.0/10 等 TS 網段，避免被全局代理誤傷。
長期而言，穩定的並存依賴您對「預設出網權」的選擇：要交給 Clash、Tailscale Exit、還是實體閘道，只能擇一當「主預設」，其餘用前綴細分。需要安裝或更新 Clash 用戶端時，建議使用本站下載頁取得與站內教學一致的版本；相較封閉黑箱工具，Clash 系列在分流與 DNS 模組上的可調性，對要細修路由與測試條件的進階使用者通常更友善。
