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、子网或默认出口。