Resolving Tailscale and Clash Conflicts: TUN, LAN, and Route Priority

With Tailscale alone, tailnet devices should be reachable; with Clash TUN alone, everyday routing should work. If each works independently and only the combination fails, investigate competition over routes, DNS, or the default egress. If either one fails alone, fix its own configuration first.

Record three states separately: only Tailscale, only Clash, and both enabled. In each state, test one tailnet IP, one tailnet device name, one LAN address, and one public address. Different results for the IP and device name already separate routing problems from MagicDNS problems.

Tailscale assigns devices addresses in 100.64.0.0/10, may also receive administrator-approved subnet routes, and installs default routes when an exit node is selected. Clash TUN writes routes too, so you cannot diagnose the conflict by looking at two toggles.

While the failure is active, save the output of route print, ip route, or netstat -rn and compare it with the single-tool state. Focus on which interfaces receive 100.64.0.0/10, the actually advertised subnets, the home LAN, and default routes, plus whether duplicate prefixes appear with different metric values.

Both a Tailscale exit node and Clash TUN can affect default internet traffic. If the goal is only to reach a home NAS through Tailscale while Clash handles public routing, do not select a Tailscale exit node on this device.

Let Tailscale handle only the tailnet and advertised subnets.

Conversely, if company policy requires all public traffic to use a designated Tailscale exit node, restrict Clash to explicit applications or proxy ports and confirm that this combination complies with organizational policy. When both tools claim the default egress, intermittent success usually means the route metric happens to favor one at that moment—not that the configuration is stable.

In clients such as Clash Verge Rev that support custom subnet exclusions for TUN, add 100.64.0.0/10, the home LAN actually in use, and the advertised routes approved in the Tailscale admin console to the exclusion list.

Do not copy every private subnet from someone else. An overly broad exclusion sends connections that should be handled by Clash directly out of the tunnel.

Mihomo rules can also mark these subnets as DIRECT, but a routing-layer exclusion and rule-layer DIRECT are not identical: a connection must first reach the core before a rule can evaluate it. If the 100.x request never appears in Clash connection records, inspect system routing directly; if it appears and matches a proxy, adjust the rule.

Successful direct access to a 100.x address means the route to the tailnet largely exists. If device-name resolution still fails, Clash DNS, browser DoH, or the system resolver probably is not handing the tailnet name to Tailscale's DNS configuration.

First use tailscale status to obtain the device address, then compare the short name and full tailnet name with nslookup or the system resolver. During troubleshooting, disable the browser's independent DoH and check Clash's nameserver-policy or local-domain exclusions. Do not forward tailnet names to public DNS.

If a Tailscale subnet route advertises 192.168.1.0/24 while the current coffee shop or home also uses 192.168.1.0/24, the system cannot determine which side you mean from the address alone. Docker and WSL2 add private subnets of their own, so the conflict may occur only inside a container or subsystem.

When subnets overlap, change the address plan on the LAN, Docker network, or virtual machine you control. Depending long-term on a higher-priority route to win the same prefix makes the problem return after a network change, wake, or upgrade.

When a laptop wakes, moves from Ethernet to Wi-Fi, or connects to a phone hotspot, both clients rediscover the default interface and write routes. Wait for them to reconnect before comparing routing tables. If restarting one in a consistent order restores access, that is evidence of a startup-order issue.

If the problem keeps recurring after both clients are updated, reduce competition during automatic startup: let the system network become ready before starting the required tunnels, and avoid automatically selecting a Tailscale exit node at the same time. Do not run a full network reset each time, because it clears settings unrelated to the failure.

If any of the four checks fails, return only to the corresponding route, DNS, subnet, or default egress. A stable configuration clearly explains what Tailscale handles and what Clash handles instead of depending on accidental metric order.