1 Why Tailscale and Clash step on each other
Tailscale is not “just DNS.” Its client installs tunnel interfaces, publishes routes to the tailnet, and may register more-specific entries for other nodes’ subnets. Clash in TUN mode does something structurally similar: it creates a virtual adapter, manipulates policy routing, and often becomes the default resolver path for applications that would otherwise ask the OS. When both are active, the kernel still has a single decision procedure: for each packet, pick the longest-prefix match from the routing table, then break ties with interface metrics (Windows) or service order (macOS). If Tailscale believes 100.64.0.0/10 belongs on its utun and Clash believes a broad catch-all should exit through the proxy adapter, you see classic symptoms: ping to a tailnet name works sporadically, browsers stall on TLS, or only some SaaS domains fail.
The second battlefield is name resolution. MagicDNS synthesizes convenient names for peers and may push split-DNS behavior so *.ts.net queries go to Tailscale’s resolver path. Mihomo can simultaneously run enhanced-mode DNS, FakeIP, or DoH upstreams. If a hostname resolves differently depending on whether the query hit Tailscale first or Clash first, routing looks “random” even when the YAML is stable. Your goal is not to disable either product on principle—it is to make exactly one authority responsible for each query class, and to guarantee tailnet and LAN prefixes never get pulled through an offshore proxy chain by accident.
If you are still selecting a desktop client, complete a clean install first—Windows users can follow Clash Verge Rev on Windows and Mac readers Clash Verge Rev on macOS—then return here before enabling TUN, because TUN multiplies the number of overlapping routes.
2 A triage order you can repeat on every incident
Skip the forums that jump straight to “delete your profile.” Instead, freeze configuration for ten minutes and collect four facts: (1) Does the failure happen only for tailnet hostnames, only for public sites, or both? (2) With Tailscale paused and Clash still on, does the symptom vanish? (3) With Clash stopped and Tailscale on, does it return? (4) Does the failure track DNS (nslookup anomalies) or only TCP flows? Those booleans tell you whether to spend the next hour in route print, the Tailscale admin console, or Mihomo’s DNS log.
After the binary split, work top-down. First stabilize the routing table so tailnet CGNAT space and advertised subnet routes are obviously owned by Tailscale. Second, configure Clash split routing so those prefixes are pinned to DIRECT ahead of any GEOIP or catch-all rule. Third, align DNS: decide whether MagicDNS-heavy names should bypass Mihomo’s DNS pipeline or be answered only after Clash sees them—never both inconsistently. Fourth, reintroduce TUN only after system proxy mode proves sane, because TUN is where asymmetric metrics hurt most. This ordering mirrors how network engineers isolate layer-three before blaming application layer quirks.
route print -4 (Windows) or netstat -rn -f inet (macOS) plus a screenshot of Mihomo’s connection list. Diffing against a broken state is faster than re-deriving routes from memory.
3 Windows: metrics, default routes, and Tailscale interfaces
On Windows, open an elevated shell and run route print -4. Identify three groups: the physical Wi-Fi or Ethernet interface with your ISP gateway, the Tailscale tunnel interface (often labeled with the Wintun driver family), and Clash’s TAP or Wintun helper when TUN is enabled. Corporate readers already comfortable with VPN coexistence will recognize the pattern—it is the same arithmetic we outline for GlobalProtect stacks in Windows corporate VPN with Clash, except Tailscale’s routes are usually friendlier because they summarize tailnet CGNAT space instead of hijacking the entire default route.
Pay attention to overlapping destinations. Tailscale commonly installs routes for 100.64.0.0/10 and for each subnet router advertisement your admin enabled. Clash should not attract those prefixes. If you see two rows with the same prefix length, the lower metric wins. PowerShell’s Find-NetRoute -RemoteIPAddress <target> is a fast sanity check: run it against a known tailnet IP and confirm the outgoing interface is Tailscale, then run it against a public resolver such as 1.1.1.1 and confirm it exits the interface you intend (LAN NIC for split setups, or the Clash tunnel when you deliberately full-tunnel consumer traffic).
When Clash is in system proxy mode only, it rarely needs to fight Tailscale at the route level for TCP to browsers and many Win32 apps—only DNS or misbehaving binaries force you toward TUN. If you must enable TUN, set Clash’s bypass or DIRECT semantics so tailnet CIDRs never traverse remote nodes. The Mihomo stack honors explicit IP-CIDR lines placed above blunt GEOIP rules; treat that ordering as part of Windows route stability, not a cosmetic YAML sort.
4 macOS: interface order, services, and overlapping utun adapters
macOS aggregates IPv4 routes in netstat -rn -f inet output and orders interfaces in the Network settings hierarchy. Tailscale’s utun sits beside Clash’s utun when both are loaded, which means tie-break quirks surface as “Safari works but curl doesn’t” because different frameworks query routing snapshots at different times. Start in System Settings → Network: drag services so your primary ISP interface stays truthful, and inspect whether Tailscale appears as a VPN interface with on-demand rules.
For debugging, scutil --dns is mandatory. It prints resolver configurations per domain, revealing whether MagicDNS suffixes point to Tailscale’s resolver while the catch-all resolver aims at 127.0.0.1 where Mihomo listens. Misordered entries here produce the classic partial outage: corporate SaaS on split DNS works, random public sites fail, or the inverse. Do not assume Clash’s YAML dns: block is authoritative until this OS view agrees—macOS can reorder or cache longer than you expect after sleep/wake.
If you enable TUN on macOS, read the Clash Verge Rev TUN mode guide first; it explains how terminals, GUI apps, and Docker-for-Mac bridges differ. Tailscale’s daemon may restart its routes after Clash starts, so the stable fix is still declarative: keep tailnet routes out of proxy chains and restart Clash after Tailscale reconnects if your GUI offers a one-click cycle.
5 Clash split routing: keep the tailnet on DIRECT
Once OS routes look sane, lock the policy layer. Tailscale uses 100.64.0.0/10 for carrier-grade NAT compatibility; your tailnet may be a subset, but pinning the broader prefix to DIRECT is a blunt instrument that prevents most accidental proxying. Add LAN and RFC1918 ranges if your MagicDNS records or admin docs reference them. Place these IP-CIDR lines at the top of rules: before any continent-level shortcuts.
rules:
- IP-CIDR,127.0.0.0/8,DIRECT
- IP-CIDR,100.64.0.0/10,DIRECT
- IP-CIDR,10.0.0.0/8,DIRECT
- IP-CIDR,172.16.0.0/12,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT
- DOMAIN-SUFFIX,ts.net,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY
Replace RFC1918 coverage with the exact LANs you actually use—some households run CGNAT ISP space that collides visually with tailnet documentation, and you do not want to mask a real remote subnet your subscription expects to proxy. If your admin advertises corporate CIDRs through a subnet router, mirror those ranges explicitly. For hostname-driven cases (devices that only have MagicDNS names), maintain DOMAIN-SUFFIX,ts.net,DIRECT and any private connector domains your org documents.
Subscription-based rule providers are convenient but may reorder quietly; after every provider refresh, confirm your tailnet guardrails remain above generic RULE-SET imports. A nightly automation that fails open to “proxy everything” is how tailnet SSH sessions suddenly traverse Tokyo.
6 MagicDNS: split horizon without split brains
MagicDNS makes tailnet machines human-friendly, but it is still split-horizon DNS. When Clash runs DNS hijacking or FakeIP pools, Mihomo may answer before Tailscale’s resolver sees the question, synthesizing an address that routes incorrectly. The operational pattern is deterministic: either allow Tailscale to own *.ts.net queries end-to-end (Clash passes them through untouched) or configure Mihomo with explicit nameserver/nameserver-policy entries that forward those suffixes to the resolver Tailscale expects—never mix “sometimes DoH, sometimes OS default” without logging it.
In the Tailscale admin console, note whether Override local DNS is enabled. Paired with aggressive DoH from the browser, you can accidentally bypass OS split DNS entirely. Align browser experiments with your Clash plan: Chrome and Edge Secure DNS with Clash walks through the failure mode where DoH and FakeIP produce addresses that bypass your split rules.
7 DNS hijacking, FakeIP, and evidence-based debugging
When users say “DNS feels hijacked,” translate that into measurements. Compare three resolvers: Tailscale’s path for *.ts.net, the OS default, and whatever Mihomo logs for dns: queries. If dig or nslookup shows conflicting A records between LAN and Clash, you still have dual authority. Our Meta core DNS leak prevention guide enumerates Mihomo knobs—fake-ip-filter, DoH upstreams, and IPv6 pitfalls—that matter here because FakeIP amplifies tiny mistakes into “nothing loads.”
Tailscale peers sometimes advertise exit nodes; if you use an exit, all non-tailnet traffic—including DNS—may hairpin through another household. Layering Clash on top means you might accidentally proxy twice: Tailscale exit to region A, then Clash to region B. That is legal but slow, and some captive portals break. Prefer “subnet routing only” on the workstation where you run Clash unless you explicitly want a double-hop; if you must combine, set Clash rules to treat the exit’s outer resolver as a first-class hop and disable redundant DoH in the browser.
IPv6 Happy Eyeballs can masquerade as DNS failure. If AAAA records exist but your Clash node speaks IPv4 only, apps may try IPv6 first, time out, and retry—users blame DNS. Log whether disabling IPv6 on the tunnel interface (per client docs) restores perceived responsiveness before you rip apart YAML.
8 Traffic loops and asymmetric paths
A loop forms when packets leave through Clash, return through Tailscale (or vice versa) and hit the same policy twice. Symptoms include instantaneous bufferbloat, MTU blackholes, or TLS handshakes that reset every few seconds. The recipe for containment matches enterprise VPN debugging: draw a two-column table listing each interface, its default route, and which daemons own it; then verify no row sends tailnet traffic toward a remote Clash outbound. Loops often appear after enabling “Allow LAN” in one client while the other rewrites default gateways.
Reduce complexity before chasing MTU math: run Clash in system proxy mode, confirm Tailscale path stability, then enable TUN. If loops only appear with TUN, inspect whether Clash bypass lists omit the Tailscale interface or whether the Mihomo routing mark table needs an explicit exempt UID (Linux readers see similar patterns in our hypervisor guides). Windows and macOS users should prioritize interface metrics over exotic sysctl tweaks unless packet captures prove fragmentation.
9 Startup order and maintenance hygiene
Practical sequence: bring Tailscale to “connected,” confirm tailscale status shows the right exit and subnet routes, then launch Clash and load the profile with tailnet guardrails. If updates reorder services, restart Clash once—most GUIs expose a one-click core restart without rebooting. Automate cautiously: racing Windows services can recreate the bug you solved manually. Document the order for family members; “reboot stack” scripts that kill both daemons often skip the step where Tailscale must relearn subnet routes before Clash opens TUN.
After major OS upgrades, revalidate. Apple and Microsoft both ship VPN-related networking changes that alter interface metrics silently. Treat Tailscale and Clash upgrades independently: upgrade Tailscale first in lab hours, snapshot routes, then bump Mihomo when logs stay clean.
10 FAQ
- Only MagicDNS names fail: Almost always DNS authority—verify
nameserver-policyforts.netand pause browser DoH. - Tailscale OK, public sites fail when Clash enables TUN: Inspect default route metrics; your tunnel may have won the default path unexpectedly.
- Intermittent stalls on HTTPS: Compare IPv4 vs IPv6 answers; check FakeIP filters for the affected domains.
- Do I need an exit node? Only if you want all Internet traffic to egress elsewhere; otherwise subnet routing plus Clash is simpler to reason about.
11 Wrap-up
Coexisting Tailscale and Clash is a routing and DNS coordination problem. Nail route priority on Windows and macOS so tailnet CGNAT space stays on Tailscale interfaces, then codify the same intent in Clash split routing with early IP-CIDR and DOMAIN-SUFFIX,ts.net,DIRECT rows. Separate MagicDNS from Mihomo DNS pipelines with explicit policies instead of toggling features randomly, and treat browser Secure DNS as part of the stack. Compared with all-in-one VPNs, a maintained Clash client gives you logs and reproducible YAML—exactly the observability you need when two tunnel adapters both think they know the best path to the Internet.
When you are ready to standardize installs across teammates, route them through the hub’s download page for curated builds and release notes instead of scattering everyone to different GitHub threads.
