Tailscale 和 Clash 衝突怎麼辦？TUN、區域網路與路由優先級修復

只有 Tailscale 與 Clash TUN 同時執行才失效，才按下表檢查共同的路由、DNS 與預設出口。任一工具單獨執行也失敗時，請轉查該工具本身的設定，不要把這種情況當成同時執行的衝突。

分別記錄三種狀態：只開 Tailscale、只開 Clash、兩者都開。每種狀態測試一個 tailnet IP、一個 tailnet 裝置名、一個區域網路位址和一個公用網路位址。IP 與裝置名的結果不同，已經能把路由問題和 MagicDNS 問題分開。

Tailscale 為裝置分配 100.64.0.0/10 範圍內的位址，還可能接收管理員批准的子網路由；選擇 exit node 時又會安裝預設路由。Clash TUN 同樣會寫入路由，因此衝突不能只看兩個開關。

在故障狀態下，依系統儲存下方命令的結果，再與單獨運作時比較。Linux 要用 ip route show table all 搭配 ip rule 查看策略路由，不能只看主表。

重點確認 100.64.0.0/10、實際發布的子網、家庭 LAN 與預設路由分別指向哪個介面，以及路由表和規則如何選擇它們；同一表內再比較相同前綴的 metric。

Tailscale exit node 與 Clash TUN 都可以影響預設網際網路流量。若目標只是透過 Tailscale 存取家中 NAS，同時由 Clash 處理公用網路分流，就不要在這台裝置上選擇 Tailscale exit node。

如果公司要求所有公網流量經過指定 Tailscale exit node，應讓 Clash 只處理明確的應用程式或代理連接埠，並確認這種疊加符合組織政策。兩個工具都設定預設出口時，偶爾連線成功可能只是路由優先順序（metric）暫時有效，不能說明設定穩定。

在 Clash Verge Rev 等支援 TUN 排除自訂網段的用戶端中，可把 100.64.0.0/10、實際使用的家庭 LAN，以及 Tailscale 管理主控台批准的 advertised routes 加入排除範圍。

不要照抄別人所有私有網段。排除過寬會讓本該由 Clash 處理的連線直接離開。

Mihomo 規則裡也可把這些網段明確 DIRECT，但路由層排除與規則層 DIRECT 不是完全同一件事：連線必須先進入核心，規則才有機會判斷。若 100.x 請求連 Clash 連線記錄都沒有出現，就直接看系統路由；如果出現並命中代理，則調整規則。

Tailscale 子網路由若發布 192.168.1.0/24，而目前咖啡店或家中也使用 192.168.1.0/24，系統無法僅憑位址知道要存取哪一邊。Docker 與 WSL2 還會增加自己的私有網段，衝突表現可能只發生在容器或子系統裡。

遇到重疊網段時，優先修改自己可控制的 LAN、Docker 或虛擬機位址規劃。長期為同一網段反覆提高路由優先順序，換網路、喚醒或升級後仍可能再次失效。

直接存取 100.x 位址成功，說明到 tailnet 的路由基本存在。此時裝置名解析失敗，多半是 Clash DNS、瀏覽器 DoH 或系統 resolver 沒有把 tailnet 名稱交給 Tailscale 的 DNS 設定。

用 tailscale status 取得目標裝置位址，再用系統原生解析工具比較短名稱與完整 tailnet 名稱。某些平台的 nslookup 不讀取系統 DNS 設定，結果不能單獨用來否定 MagicDNS。

macOS 可執行 dscacheutil -q host -a name DEVICE_NAME，把 DEVICE_NAME 換成短名稱，查看 name 與 ip_address；再用傳回的完整 tailnet 名稱重複查詢，將位址與目標裝置比對。

檢查期間關閉瀏覽器獨立 DoH，並檢查 Clash 的 nameserver-policy 或本機網域排除，不要把 tailnet 名稱轉送給公共 DNS。

筆記型電腦喚醒、從有線切換到 Wi-Fi 或連線手機熱點後，等待兩個用戶端完成重新連線，再比較路由表與名稱解析結果。以固定順序重新啟動其中一方後恢復，是檢查啟動或重新連線過程的線索；還要依前後的路由與解析記錄判斷發生了什麼變化，不能只因恢復就確定原因。

更新兩邊用戶端後仍反覆出現，可減少自動啟動中的競爭：讓系統網路先就緒，再啟動需要的隧道，並避免同時自動選擇 Tailscale exit node。不要每次都執行完整網路重置，它會清除更多與故障無關的設定。

tailnet IP、裝置名、發布子網或公用網路請求中的哪項失敗，就檢查對應的路由、DNS、子網或預設出口。