本文目录
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 顺序。