Tailscale 与 Clash 同时开总冲突？TUN、局域网绕过与路由优先级逐步修复
很多人会在本机常驻 Tailscale（或其它基于 WireGuard 的 mesh VPN）的同时开着 Clash 的系统/TUN 转发。两处都要接管「出站路径」时，症状往往高度相似：突然像断网、打不开家里 NAS 或打印机、或对端 100.x 地址 ping 不稳定。根本原因通常不是某一个 App「坏了」，而是第二条隧道改写默认路由、DNS 劫持点与流量捕获范围重叠——本文按顺序对齐 TUN 栈、局域网绕过（bypass-private-network 等）、Tailscale 使用的 CGNAT 段与路由优先级（metric），让两类工具各司其职；更多局域网代理与端口细节见站内 《局域网 mixed-port 与放行》，WSL2/虚拟机二层网可对照 《WSL2 与宿主代理》、《VMware/Parallels 网卡拓扑》。
两条隧道其实在争三件事
把局域网（RFC1918）、Tailscale 平面（常见为 100.64.0.0/10 内的地址）与互联网默认路由（0.0.0.0/0）想象成三块蛋糕。Tailscale 与 Clash（尤其是开启 tun.auto-route 或等价自动下发系统路由的实现）都希望把其中一块或多块引向自己的虚拟网卡。当两边先后写入路由表、或先后顺序因睡眠唤醒/重新拨号而变化时，你看到的就是「关掉任意一个就立刻好」的假性故障。
- 默认路由：谁 wins 决定了「没被更具体前缀匹配的流量」从哪里出去。
- 更具体的静态路由：局域网子网与 100.x 若被错误地套上 Clash 策略，会像「绕远道」或直接黑洞。
- DNS 解析落点：MagicDNS、系统 DNS 与 Clash 内置 DNS 三套如果不一致，会表现为「能上 IP、不能解析」或只对部分域名失败。
诊断起点
在复现问题时先打开系统路由表与 DNS，不要先看订阅节点：确认发往 NAS 的包是否仍走物理网关，以及发往 100.x 的包是否仍在 Tailscale 接口上。
常见症状与它们各自指向的方向
| 现象 | 更值得先查的点 |
|---|---|
| 外网全无，关了 Clash 恢复 | Clash TUN auto-route、strict-route 与网关/metric |
| 家里 192.168.x.x / 10.x 访问变慢或超时 | bypass-private-network，或等价「私网不进入 TUN」配置 |
| 仅 Tailscale 设备互访异常 | 100.64.0.0/10 是否直连到 tailscale/wg 接口，而不是被 GEOIP/MATCH 拉进代理链 |
| 睡眠唤醒后才出问题 | 双端谁先写路由；必要时固定启动顺序或使用更保守的 tun 选项 |
第一步：弄清「谁在网关上」而不是先堆规则
与「旁路由上跑 Clash」不同，单机双客户端场景下网关通常仍是路由器，Tailscale 与 Clash 各建一层宿主侧覆盖。画一张简略拓扑：物理网卡默认路由、Tailscale utun/wintun/tun0 的更具体前缀、以及 Clash Meta tun 设备的前缀并存时，谁在后启动往往覆盖谁先写进去的默认路由。Windows 可看 route print 里的 metric；macOS 用 netstat -nr；Linux 关注 ip route show table main。
第二步：校准 Clash TUN 的职责边界
在 Clash Meta / Mihomo 系内核中，tun.stack（如 system、gvisor、mixed）影响的是用户态捕获与内核转发的分界，并不自动告诉你「该不该吃私网流量」。更值得一起调整的是：auto-route 是否要向系统表中灌默认路由；strict-route 会不会把本该走物理接口的回程也收紧——这两者在不同 OS 上副作用差一截。WSL、Docker Desktop、虚拟机若同时存在，链路会更像站内 《WSL2》 文里强调的「谁先收到 SYN」问题，而不是单靠换节点能解决。
若你只熟悉系统代理、尚未建好 TUN 基线：Windows 请完成 《Clash for Windows 安装与 TUN》；macOS 先按 《Clash Verge Rev macOS》 放行内核扩展／网络权限；Linux 可参考 《Linux 无图形 + systemd》。
第三步：局域网绕过 —— bypass-private-network 与等价策略
许多用户并非缺规则，而是把不该进隧道管理面的流量误带进 tun。在支持该选项的版本里启用 bypass-private-network（语义即：RFC1918 等私有网段尽量绕过 TUN 自动劫持，仍可按需在 rules 里写死例外）后，局域网打印服务、Chromecast 二层发现、mDNS（部分场景）所受干扰会明显减少。若你的 UI 没有把这项暴露成勾选框，可查对应发行版是否在配置模板的 tun: 段支持同名键或使用文档中的替代写法。
100.64/10 不是「普通私网规则」的简单子集
Tailscale（及若干运营商 CGNAT）常用 100.64.0.0/10。单靠「局域网直连」话术容易漏掉这一条：若它被当成「普通国外流量」去匹配 GEOIP/MATCH，就会表现成 mesh 链路间歇性失败。应显式让 100.64/10 或其子集 DIRECT（直连），并校验顺序在宽泛代理兜底之前。
第四步：YAML 规则里把 Tailscale 与私网写在前面
下面片段为示意：请用你的真实接口名／UI 等价项校对；核心是前缀规则早于最终 MATCH。
# Illustrative — adjust interface names / stack per your distro & Mihomo version
tun:
enable: true
stack: system
auto-route: true
strict-route: true
# When supported: skip hijacking RFC1918 & link-local into tun by default
bypass-private-network: true
rules:
# Tailscale WireGuard overlay (CGNAT)
- IP-CIDR,100.64.0.0/10,DIRECT,no-resolve
# Optional: LAN segments you want never proxied at policy layer
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
# ...your DOMAIN / GEOIP / MATCH fallback...
no-resolve 可避免 fake-ip/DNS 与纯 IP 规则打架；若你已用拆分 DNS，请与服务端下发的域名规则一并复查，避免只对 Clash「看似直连」，系统层仍走错接口。
第五步：系统路由优先级与启动顺序
当 Clash 与 Tailscale都要求成为「全流量出口决策点」的一部分时，单靠 YAML 不足以覆盖系统在握手阶段选中的接口。可操作的习惯包括：Tailscale 先连、Clash TUN 后开（或反向试一次——以你机器上更不抖的那组为准）；在 Tailscale 管理后台避免与本机重复的 subnet route 与奇怪的 exit node；在 Clash 侧暂时关闭激进的 strict-route 做 A/B。
Tailscale 客户端若开启局域网发现、允许本地网访问 peers等选项（具体名称依版本而异），能减少「全盘隧道化」体感；其与 Clash bypass-private-network 方向一致：让「真的在隔壁房间」的流量走物理链路，把 Clash 留给需要策略分流的公网会话。
Tailscale 侧值得你勾一眼的配置
- Subnet routes（子网宣告）：若你与旁路由一起做「家庭网段回填」，注意不要与宿主上重复的覆盖路由叠加出环路或黑洞。
- MagicDNS：与 Clash 的
dns/nameserver-policy并存时，用一次dscacheutil/nslookup/dig确认到底是谁在答。 - Exit node（出口节点）：本质是再套一层远端默认路由——与「Clash TUN 再拉一条默认路由」叠加时最易炸；排障可先两处都关退出节点语义，只验证 mesh 点对点。
按系统的实务备忘（不求全，但求能动手）
Windows：留意 WFP 与其它安全软件的过滤层；Hyper-V/WSL vSwitch 会改变最短路径。若你已按 站内 WSL2 指南 配过 mirrored 模式，可把本文的「私网/100.x 前缀」视作同一方法论在Tailscale utun/wintun 上的延展。
macOS：Network Extension／系统防火墙与睡眠唤醒后的DNS 会话复用偶发错乱；先试「关掉再开 Tailscale」，再观测 Clash 是否重写了网关。
Linux：ip rule 多策略表、NetworkManager 与 systemd-networkd谁先应用都会改变结果；服务端若跑在 headless，可把 tun.auto-route 调成更保守，再手工补你需要走宿主的特定表项。
常见问题
开了 bypass-private-network 仍访问不了局域网
检查链路层是否真的直连（同一 L2 VLAN？）、打印机是否只靠广播发现（Clash TUN 不处理广播）、以及是否在另一条规则链里把局域网 IP 又送进了节点。
关掉 Clash 后 Tailscale 正常，一开就不行
高度怀疑默认路由或 100.x 路由被 Clash 覆盖；先在规则里锁住 100.64.0.0/10 DIRECT，再高优先放 LAN CIDR；最后才动 strict-route 与路由 metric。
不是 Tailscale 而是其它 mesh / 团队 VPN
只要把「虚拟接口地址段」「是否下发默认路由」「DNS 是否与 Clash fake-ip 冲突」三张表列出来，排障等价；零信任客户端若拆分隧道（split tunnel）可用，往往能显著降低与本机「第二条完整隧道」的摩擦。
实操检查清单
- 记录复现前后的三张路由前缀：默认路由、LAN、100.x（或你的产品文档中的 overlay 前缀）。
- 在 Mihomo／Meta 中为 100.64.0.0/10 与本机局域网段写上靠前的 DIRECT（必要时带
no-resolve）。 - 确认
bypass-private-network或等价能力已打开，或与上述 CIDR 规则互不矛盾。 - Tailscale 侧暂时关闭exit node／冲突的子网宣告做一次对照实验。
- 固定客户端启动顺序或用保守 tun 选项，直到睡眠唤醒后也稳定。
- 用「局域网 IP + Tailscale ping + 公网 HTTPS」三组探针同日回归。
让规则引擎留在你看得见的地方
Clash 的价值在于：把公网出口的博弈显式写成策略，而不是与用户态／内核里其它隧道静默打架。厘清 TUN、bypass-private-network 与CIDR 前缀级路由优先级以后，Tailscale 管 mesh，Clash 管分流——这才是长期可维护的方案。