本文目錄
Tailscale 和 Clash 單獨都正常、一起開才斷，才是真正的衝突
Tailscale 單獨開啟時應能存取 tailnet 裝置，Clash TUN 單獨開啟時應能完成日常分流。若兩者單獨執行都正常、同時執行才失效，再檢查路由、DNS 或預設出口的競爭。任意一方單獨就壞，應先修它自己的設定。
分別記錄三種狀態：只開 Tailscale、只開 Clash、兩者都開。每種狀態測試一個 tailnet IP、一個 tailnet 裝置名、一個區域網路位址和一個公用網路位址。IP 與裝置名的結果不同，已經能把路由問題和 MagicDNS 問題分開。
三組對照能說明什麼
| 結果 | 更可能的問題 |
|---|---|
| 100.x 位址不通，裝置名也不通 | Tailscale 網段被 TUN 或預設路由接走 |
| 100.x 位址能通，裝置名不通 | MagicDNS 或 Clash DNS 接管順序 |
| tailnet 正常，公用網路斷開 | 兩個工具在競爭預設出口或 exit node |
| 只有某個區域網路段不通 | Tailscale 子網路由與本機網段重疊 |
路由表會告訴你哪張網路介面卡搶走了目標網段
Tailscale 為裝置分配 100.64.0.0/10 範圍內的位址，還可能接收管理員批准的子網路由；選擇 exit node 時又會安裝預設路由。Clash TUN 同樣會寫入路由，因此衝突不能只看兩個開關。
在故障狀態下儲存 route print、ip route 或 netstat -rn 的結果，再與單獨執行階段比較。重點看 100.64.0.0/10、實際發布的子網、家庭 LAN 和預設路由分別指向哪個介面，以及是否出現兩個相同前綴但 metric 不同的項目。
# Windows
route print
# Linux
ip route
ip rule
# macOS
netstat -rn預設網際網路出口只交給一個工具
Tailscale exit node 與 Clash TUN 都可以影響預設網際網路流量。若目標只是透過 Tailscale 存取家中 NAS，同時由 Clash 處理公用網路分流，就不要在這台裝置上選擇 Tailscale exit node。
讓 Tailscale 只負責 tailnet 與發布子網。
反過來，如果公司要求所有公用網路流量經過指定 Tailscale exit node，就應讓 Clash 只處理明確的應用或代理連接埠，並確認這種疊加符合組織策略。兩個工具都宣稱預設出口時，連線偶爾成功通常只是路由 metric 暫時有利，並不是穩定設定。
把 tailnet 和實際子網留給 Tailscale
在 Clash Verge Rev 等支援 TUN 排除自訂網段的用戶端中，可把 100.64.0.0/10、實際使用的家庭 LAN，以及 Tailscale 管理背景批准的 advertised routes 加入排除範圍。
不要照抄別人所有私有網段。排除過寬會讓本該由 Clash 處理的連線直接離開。
Mihomo 規則裡也可把這些網段明確 DIRECT，但路由層排除與規則層 DIRECT 不是完全同一件事：連線必須先進入核心，規則才有機會判斷。若 100.x 請求連 Clash 連線記錄都沒有出現，就直接看系統路由；如果出現並命中代理，則調整規則。
需要按自己網路填寫
- 100.64.0.0/10 tailnet 位址範圍
- 家中或辦公室實際 LAN 網段
- Tailscale 管理主控台已批准的子網路由
- Docker、WSL 或虛擬機中確實與 tailnet 重疊的網段
IP 可達而裝置名失敗，處理 MagicDNS 而不是路由
直接存取 100.x 位址成功，說明到 tailnet 的路由基本存在。此時裝置名解析失敗，多半是 Clash DNS、瀏覽器 DoH 或系統 resolver 沒有把 tailnet 名稱交給 Tailscale 的 DNS 設定。
先用 tailscale status 取得裝置位址，用 nslookup 或系統解析工具比較短名稱與完整 tailnet 名稱。檢查階段關閉瀏覽器獨立 DoH，並檢查 Clash 的 nameserver-policy 或本機網域排除，不要把 tailnet 名稱轉傳送給公共 DNS。
WSL、Docker 和異地 LAN 可能剛好用了同一個網段
Tailscale 子網路由若發布 192.168.1.0/24，而目前咖啡店或家中也使用 192.168.1.0/24，系統無法僅憑位址知道要存取哪一邊。Docker 與 WSL2 還會增加自己的私有網段，衝突表現可能只發生在容器或子系統裡。
遇到重疊網段時，優先修改自己可控制的 LAN、Docker 或虛擬機位址規劃。長期依賴更高優先級路由去搶相同前綴，會讓換網路、喚醒或升級後再次失效。
只在喚醒或換 Wi-Fi 後失效，通常是路由重寫順序變了
筆記本喚醒、從有線換到 Wi-Fi 或連線手機熱點時，兩套用戶端會重新發現預設介面並寫路由。先等待它們完成重連，再比較路由表；固定順序重啟其中一方能夠恢復，是啟動時序的證據。
更新兩邊用戶端後仍反覆出現，可減少自動啟動中的競爭：讓系統網路先就緒，再啟動需要的隧道，並避免同時自動選擇 Tailscale exit node。不要每次都執行完整網路重置，它會清除更多與故障無關的設定。
修復完成要同時證明兩項任務都還成立
同一輪驗證
存取 tailnet IP
證明 100.x 路由仍交給 Tailscale。
存取 tailnet 名稱
證明 MagicDNS 或專用解析仍然可用。
存取發布子網
確認批准的 subnet route 沒被 Clash 接走。
存取公用網路並查看 Clash 記錄
證明普通分流仍由預期策略處理。
四項中哪一項失敗，就只回到對應的路由、DNS、子網或預設出口繼續調整。能夠同時說明 Tailscale 負責什麼、Clash 負責什麼，設定才算擺脫了偶然的 metric 順序。