Tailscale and Clash: Split Rules and DNS for Routing Conflicts (2026)

What actually collides

Tailscale installs a userspace or kernel tunnel interface, publishes 100.64.0.0/10-class addresses to peers, can push default routes when you use an exit node, and may advertise subnet routes so your laptop learns paths to LAN segments behind another device. MagicDNS and split DNS features steer certain names toward Tailscale resolvers or peers. Clash, especially in TUN mode, also adds routes, sometimes captures all DNS, and applies split routing through YAML rules. Neither tool is “wrong”; they simply both believe they should own pieces of the same packet path.

Symptoms cluster into three buckets. First, total or partial loss of connectivity—often a competing default route, a blackhole after exit-node toggles, or MTU issues amplified by double encapsulation. Second, domestic or LAN traffic rides the overseas proxy because your catch‑all MATCH fires before narrower GEOIP or DOMAIN slices, or because Tailscale-addressed flows never matched your mental model of “Chinese sites.” Third, odd DNS: MagicDNS names resolve on one machine but not when Clash’s dns block uses fake-ip, or systemd/Windows resolvers disagree about who answers first. The checklist below attacks those buckets in a consistent order so you do not thrash random toggles.

Step 0 — Freeze the configuration plane

Before editing YAML for the fifth time, write down four booleans: Tailscale exit node on or off, Tailscale advertise/accept subnet routes, Clash TUN versus system proxy, and Clash DNS enhanced-mode (for example fake-ip versus redir-host). Changing two at once guarantees confusion. Prefer validating with a known-good Windows or macOS Clash install so the only variable is Tailscale.

Step 1 — Read the routing table like a network engineer

On Windows, route print -4 and Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric show which default route wins and which interface owns 100.64.0.0/10 traffic. On macOS, netstat -rn -f inet; on Linux, ip route show table main and ip rule. You are looking for duplicate defaults, unexpected interface indexes, or policy rules that send “everything” through a tunnel with no path back.

When Tailscale uses an exit node, your default route may point at the tailscale0 (or similarly named) interface. If Clash TUN also installs a high-priority default route, the OS may prefer one interface while application sockets still attach elsewhere—behavior varies by client and auto-route settings. The fix is rarely “more rules”; it is almost always “one authority for the default route at a time,” then explicit exceptions.

For subnet routes, confirm the OS actually received the prefixes Tailscale should inject. If the route is missing, Clash cannot magically proxy what never hits the stack correctly; fix Tailscale ACLs and “Use subnet routes” toggles first. If the route exists but traffic still escapes wrong, note the next-hop and metric: Clash TUN may need bypass entries for those prefixes so packets do not get re-captured.

Step 2 — Decide who owns the default route

Practical patterns that survive 2026 updates:

• Clash TUN as primary splitter, Tailscale without exit node — Often the least combative: mesh traffic stays on tailscale0, general Internet follows Clash policy. You still add YAML exceptions (below).
• Tailscale exit node for everything, Clash as application proxy only — Lets Tailscale steer the default route while browsers or specific apps use Clash’s HTTP/SOCKS port. Good when corporate policy mandates a specific exit but you still need granular site rules in a few apps.
• Both fighting for default — Possible for experts who script metrics and interface bindings, but fragile. Demote this to a lab curiosity unless you enjoy rebuilding routes after sleep/resume.

Document the choice. Future you—and anyone reading server logs—needs a single sentence like “Exit node off; Clash Meta TUN auto-route on; Tailscale carries mesh only.”

Step 3 — Add high-priority Clash rules for Tailscale space

Mesh IPv4 in Tailscale lands in the shared Carrier-Grade NAT documentation space 100.64.0.0/10. A blunt but effective pattern is placing an early rule such as IP-CIDR,100.64.0.0/10,DIRECT,no-resolve (exact keyword order follows your core’s schema) ahead of broad proxy matchers. That keeps peer-to-peer pings, SSH to 100.x hosts, and MagicDNS-adjacent flows from being hoovered into an overseas outbound by a lazy MATCH.

If you advertise or consume specific LAN subnet routes—for example 192.168.3.0/24 behind a home router—mirror those prefixes with IP-CIDR DIRECT lines before catch-alls. This is the same discipline as custom split rules, just with source-of-truth copied from Tailscale’s routing table instead of guesswork.

Users juggling mainland content should combine this with GEOIP CN and bypass-China ordering: Tailscale exceptions must still sit above a broad proxy MATCH, otherwise domestic latency returns even though “Tailscale looks fine.”

Step 4 — Untangle DNS: MagicDNS versus Clash

MagicDNS gives short names and magic domains under your tailnet. Clash may send all queries through its internal dns forwarder, apply fake-ip mapping, or mix DoH upstreams. When both are aggressive, you can get “resolved in dig but wrong in browser” symptoms because the browser, the OS stub, and Clash disagree on who is authoritative.

Work through this ladder:

1. Identify the active resolver stack — Windows “adapter DNS,” macOS resolvers, Linux systemd-resolved or NetworkManager. Our Linux DNS article shows how tangled stub listeners become; Tailscale adds another conditioned forwarder on top.
2. Align Clash nameserver with reality — If MagicDNS must answer tailnet names, ensure Clash forwards those domains (via nameserver-policy or equivalent) to a resolver that can see Tailscale, or allow OS resolution for specific suffixes. Blindly pushing everything through a public DoH bypassing the mesh hides peers.
3. Be deliberate with fake-ip — Great for split control of global domains; treacherous when you expect MagicDNS to return real 100.x answers that applications must trust immediately. Sometimes switching the enhanced mode—or scoping fake-ip to specific domain sets—clears inexplicable TLS failures.

When debugging, log DNS and connections together: if Clash shows a weird upstream IP for a tailnet hostname, you have a resolver policy bug, not a “bad node.”

Step 5 — Exit nodes, MTU, and double tunneling

Exit nodes wrap your entire Internet path inside Tailscale. Adding Clash TUN on top can work but often exposes MTU issues, especially on Wi‑Fi: symptoms include “HTTPS hangs after handshake” or intermittent Voice-over-IP drops. Lowering interface MTU conservatively or choosing only one full-tunnel technology for bulk traffic usually beats weeks of tweaking crypto settings.

If you must stack tunnels, measure with ping -M do -s SIZE destination (Linux) or path MTU discovery tools on Windows. Record the largest size that succeeds without fragmentation, then apply sane interface MTU values or MSS clamping at the correct layer—not as a cargo-cult 1400 everywhere, but as a reaction to measured loss.

Step 6 — Verification script you can repeat

1. 1

   Mesh sanity

   Ping or SSH to a known 100.x peer with Tailscale alone, Clash off. If this fails, fix Tailscale before touching YAML.

2. 2

   Clash alone

   Disable Tailscale, verify representative domestic and international sites through Clash logs. Establishes baseline policy.

3. 3

   Combined with traces

   Enable both, run the same tests while watching Clash’s connection list for unintended outbounds. Revisit rule order if domestic domains appear on foreign groups.

4. 4

   DNS cross-check

   Query a MagicDNS name with OS tools and through Clash; results should converge. Divergence means nameserver policy still wrong.

Platform notes that still matter in 2026

Windows users should remember that Defender Firewall profiles and interface metrics interact with both products. If mesh TCP succeeds but Clash intercept breaks specific UWP apps, revisit loopback and system proxy behavior—we keep that separate from Tailscale but the symptoms rhyme.

macOS users may see Apple’s network quality API prefer one path while CLI utilities show another; trust interface tables plus Clash logs over a single menu-bar icon.

Linux desktop environments vary wildly in who manages resolv.conf; Tailscale’s and Clash’s DNS guides both assume a coherent stub—if resolvectl status looks like a novel, stabilize systemd-networkd/NetworkManager first.

Security and expectations

Mesh networking increases attack surface: any device admitted to the tailnet can attempt lateral movement. Combining it with Clash does not reduce that risk; it only adds policy flexibility. Keep Tailscale ACLs tight, rotate keys on compromise, and treat unpublished submarine redirect rules as technical debt.

When colleagues share “it works on my laptop” screenshots, ask for the same routing table dump and Clash log excerpt: silent drift in corporate mobile-device management or vendor VPN profiles often reintroduces competing defaults overnight. A short, repeatable checklist beats hero debugging sessions.

Open-source transparency for Clash ecosystems lives on GitHub, but installers belong on vendor-approved pages—see below—so checksums and support boundaries stay clear.

Bottom line

Coexistence is a routing and DNS contract: let the OS table show honest paths for Tailscale’s 100.64.0.0/10 peers and any subnet routes, mirror those prefixes as high-priority split rules in Clash, and separate MagicDNS from blind fake-ip where tailnet names need faithful answers. Compare against sibling guides when your problem is really WSL2, containers, or Hyper‑V—but when the headline issue is Tailscale plus Clash, start with the table, then DNS, then YAML.

For a maintained client build that tracks modern cores, use this site’s download page—Download Clash for free and experience the difference.