Tailscale 与 Clash 同开断网？路由优先级与 DNS 修复

1 典型现象：谁在和你抢默认路径

Tailscale 会为节点分配 CGNAT 段内的地址（常见为 100.x.x.x），并在系统路由表中加入指向 Tailscale 接口的主机路由与聚合路由，以便你通过 mesh 访问其它节点。若你在管理层里开启了 MagicDNS，解析链里还会多出一层「把 *.ts.net 等名字交给 Tailscale」的逻辑。与此同时，Clash 开启 TUN 时往往会接管默认路由或拦截 DNS 查询，把流量拉进 Mihomo 内核做规则匹配。两套栈假如对同一条默认路径有不同期望，操作系统只能按最长前缀匹配、度量（metric）、接口存活状态等规则二选一——表现上就是「时好时坏」或「一开了 Clash，Tailscale 网页管理台打不开」。

另一种高频情况是：只影响部分域名。例如内网设备名用 MagicDNS 能解析，公网站却偶发超时；这通常不是「节点挂了」，而是查询没有走到你设想的解析器，或被 Clash 的 FakeIP、DNS 劫持策略提前截断。浏览器侧若再叠一层「安全 DNS」（Chrome / Edge），还会多一条支路，细节可对照《Chrome 和 Edge 安全 DNS 与 Clash 抢解析》，但Tailscale 场景下请先确认系统路由没有把整个 100.64/10 送进错误的下一跳。

2 推荐排查顺序（先路由后 DNS）

为避免在「换节点、重装客户端」上浪费时间，可按下面顺序逐项收敛。核心原则是：包先找到正确的网卡出口，再谈域名解析走谁。

只开 Tailscale，确认 mesh 内互 ping、MagicDNS 可用；记录此时默认路由与 Tailscale 相关路由。
再开 Clash（建议先系统代理试一遍，再试 TUN），对比路由表变化：哪张接口的 0.0.0.0/0 度量变小了、是否出现第二条默认路由。
在 Clash 规则最前部加入对 100.64.0.0/10（及你确认的 Tailscale 接口子网）的 DIRECT，避免 mesh 流量误进海外节点。
最后处理 DNS：区分「系统解析器」「Tailscale MagicDNS」「Clash hijack-dns / redir-host」三层，用 dig / nslookup 对照关 Clash与开 Clash的差异。

与企业全隧道 VPN 抢路由的故事类似，可参考《Windows 企业 VPN 与 Clash 同开》里的「谁在抢默认路由」一节；差别在于 Tailscale 通常不会把你的办公合规策略写成同一套网关合同，但技术层面的 metric 竞争几乎同样适用。

3 Windows：路由表与接口度量

在管理员 PowerShell 中，用下面命令查看 IPv4 默认路由及度量排序（输出因机器而异）：

PowerShell

Get-NetRoute -DestinationPrefix "0.0.0.0/0" -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Format-Table DestinationPrefix, NextHop, InterfaceAlias, RouteMetric -AutoSize

route print -4

若你看到两条 0.0.0.0/0，请记住：在相同前缀长度下，较小的 RouteMetric 通常更优先。Clash TUN 与企业 VPN、Tailscale 的安装顺序会影响谁后写入、谁的 metric 更低。实践上，不少用户发现先登录 Tailscale，再启动 Clash TUN，比反过来更稳定——因为后启动的一方往往掌握「当前默认出口」的最终值，但仍要以你机器上实测路由表为准。

另外请检查是否存在指向 100.64.0.0/10 或其子集的路由仍绑定在正确接口上。若 TUN 驱动错误或 metric 异常，可能出现「Tailscale 状态页显示已连接，但 ping 对端 100.x 全丢」的情况。此时不要盲目调 Clash 规则，先把 TUN 关掉对照，确认是 Layer 3 路由问题还是 DNS / 策略问题。

4 macOS：路由顺序与 DNS 配置缓存

在终端执行 netstat -rn -f inet，关注 default 行对应的 Iface 与 gateway。Clash TUN 与 Tailscale 都会在列表里出现_utun_ 或类 VPN 接口名。macOS 的多默认路由场景下，同样需要理解谁后发、谁的优先级更高；若你发现「开了 Clash 后 default 仍指向 Wi-Fi，但网页全无网」，要同步看DNS是否被框架层改写。

使用 scutil --dns 可列出解析器顺序。Tailscale 可能在搜索域或补充解析器里插入 MagicDNS 相关项；Clash 若启用TUN 栈内置 DNS，也会改变应用实际用到的上游。记得在改配置后重连一次 Tailscale或切换 Clash 模式让路由/DNS 缓存刷新，否则你会看到「配置明明对了，旧行为却残留」的假象。

5 Tailscale：网段、MagicDNS、Exit Node

若你使用了 Subnet Router 或 Exit Node，Tailscale 会额外下发更具体的前缀路由。这不是错误，但会改变「哪些流量先进 Tailscale」。当 Clash 也想截获所有 TCP/UDP 时，两者可能把同一终点先后处理两次，造成环路或黑洞。

MagicDNS 让 机器名.ts.net 类解析在多数场景更省事；但一旦 Clash 把所有 53 端口的查询劫持到本地，必须在 Mihomo 配置里用 nameserver-policy（或当前内核等价键）把 ts.net 后缀仍指向 Tailscale 期望的解析路径，否则会出现「只有 IP 能访问、名字访问失败」的分裂现象。关于 FakeIP 与防泄漏的通用注意点，可延伸阅读《彻底防止 DNS 泄漏》，但请始终把 Tailscale 后缀策略当作单独一条验收项。

小贴士 Tailscale 管理后台若有自定义 DNS或拆分 DNS 的配置，变更后终端侧可能有数分钟延迟。排障时先以本机 scutil --dns / Windows 网络适配器 DNS 列表为准，而不是只看 Clash 日志。

6 Clash：TUN 绕过与规则前置

无论用 Mihomo 还是其它 Clash 系内核，请确保私有地址与 Tailscale mesh在规则链前部被标记为 DIRECT。最小集合通常包括：100.64.0.0/10、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16（按你家庭/办公室真实拓扑裁剪），以及本机 127.0.0.0/8。

TUN 模式会把「未显式绕行」的流量重定向到虚拟网卡；若你尚未熟悉这一行为，建议先读《Clash Verge Rev TUN 模式完全指南》，再回来把 Tailscale 前缀补进「绕行名单」。图形客户端里常有「绕过中国大陆」或「绕过局域网」类开关，但公共规则集不一定包含 Tailscale CGNAT 段，因此手工前置一条 IP-CIDR 往往是一次性根除误判的关键。

若暂时拿不准路由互相影响，可先用仅系统代理验证 Clash 规则与节点健康，再开 TUN；这能把变量从「操作系统路由竞争」里剥离出去，更快判断问题是内核策略还是纯 DNS。

7 DNS 分层：排除「假劫持」

「DNS 劫持排查」先定义症状：域名 A 在关闭 Clash 时能解析，开启后得到错误地址或超时。此时依次确认：① 系统是否仍指向 Loopback 或 Clash DNS 监听端口；② FakeIP 是否把该域名映射进虚拟地址池；③ MagicDNS 查询有没有在到达公共上游之前被内核拦截。

实操上可以选一条 仅 Tailscale 需要 的名字与一条 纯公网 域名成对测试：若只有 *.ts.net 异常，而公网正常，基本坐实要在 Clash nameserver-policy 上给 Tailscale 单独通道；若全部异常，回头查默认路由与 TUN 是否把 UDP/53 一并拦截错误。

避免反复「全局直连」凑合 长期把 Clash 调成全局直连或关闭 DNS 模块，会掩盖规则与上游的真实问题。更可持续的做法是：写清前缀与后缀策略，让 mesh 与分流各自有稳定边界。

8 流量环路如何识别

环路并不总会立刻断网，有时表现为延迟飙升、CPU 占用增高、握手反复。典型成因是：包从 Clash TUN 进入后又被策略送向本地环路，或 Tailscale 与 Clash 同时对同一虚拟接口做二次封装。若你观察到在只开其中一方时问题消失，而同开必现，应优先回顾本章与上一章：是否缺少 100.64.0.0/10 的直连、是否错误的 Exit Node 与 Clash 全局出口叠加。

一线排查仍可借助 Clash / Mihomo 的连接日志与 Tailscale 的诊断面板：看目标 IP 是否反复落在同一策略、是否在短间隔内对同一 quintuple 大量重试。把日志时间段与「改动 metric / 改规则」操作对齐，往往一次就能锁定触发点。

9 验收清单

仅 Tailscale 运行时，mesh ping、SSH、MagicDNS 域名均可达。
开启 Clash（先代理后 TUN）后，100.x 互访仍成功，延迟无明显异常。
系统路由中默认路径与 Tailscale 细分路由关系符合预期，VPN/Exit Node 场景下无黑洞。
*.ts.net 与其它内网后缀在 Clash 开/关两种状态下解析一致且正确。
公网分流仍按规则命中，可通过已知测试域名或 IP 检查 ASN。
长时间运行无 CPU 异常冲高、无间歇性全站超时。

10 总结

Tailscale 与 Clash 同开的症结，多半不在「某个节点慢了」，而在路由优先级与 DNS 链没有划分边界：Tailscale 依赖对 100.64.0.0/10 及 MagicDNS 的稳定路径，Clash TUN 则倾向接管广域默认出口与 53 端口解析。把 mesh 流量前置直连、为 ts.net 设好解析策略，再按 Windows / macOS 的工具核对 metric，就能把「像断网」式的症状收敛到可复现、可修复的几条表项上。

与只折腾订阅列表相比，先在路由层看清楚 default 与 Tailscale 前缀，再在 DNS 层对照三条解析路径，通常比盲换节点省十倍时间。基于 Mihomo 的 Clash 客户端在规则可视化、日志与 TUN 开关上的一体化体验，在复杂叠网场景里依然很省心；若你希望从可信渠道安装与升级，请优先使用本站下载页获取 Windows 与 macOS 安装包。

需要兼顾终端、Docker、Git 等全局流量时，TUN 仍是主流方案；把 Tailscale 前缀写进绕行规则后， mesh 与分流可以长期并存。

→ 立即免费下载 Clash，开启流畅上网新体验

Tailscale 与 Clash 同开时断网？
按路由优先级与 DNS 分步修复