On this page
When combining remote access with an everyday proxy, it can be hard to tell whether the failure affects a device address, a device name, or internet access. Record each result separately to identify whether routing, name resolution, or the default outbound connection needs attention. Even when both tools work alone, their interaction still needs testing on the same device.
Connection Fails Only When Both Run: Compare Routes and Name Resolution
Use the table below to check shared routes, DNS, and the default outbound connection only when the failure occurs with Tailscale and Clash TUN running together. If either tool also fails alone, troubleshoot that tool’s own configuration instead of treating it as a conflict between them.
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.
What the three comparisons reveal
| Result | More likely issue |
|---|---|
| Neither the 100.x address nor the device name works | The Tailscale subnet is captured by TUN or a default route |
| The 100.x address works, but the device name does not | MagicDNS or the capture order of Clash DNS |
| The tailnet works, but public internet access fails | Both tools are competing for the default egress or exit node |
| Only one LAN subnet is unreachable | A Tailscale subnet route overlaps the local subnet |
The routing table reveals which adapter captured the target subnet
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 problem is present, save the output of the commands below for your OS and compare it with each tool running alone. On Linux, use ip route show table all with ip rule to inspect policy routing rather than only the main table.
Check the interfaces for 100.64.0.0/10, advertised subnets, the home LAN, and the default route, and how the tables and rules select them. Compare metric values for identical prefixes within the same table.
# Windows
route print
# Linux
ip route show table all
ip rule
# macOS
netstat -rnAssign the default internet route to only one tool
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.
If your company requires all internet traffic to use a specified Tailscale exit node, limit Clash to specific apps or proxy ports and confirm that combining them complies with organizational policy. When both tools set a default exit, occasional success may only reflect route priority (metric) working temporarily; it does not show that the configuration is stable.
tailnet Exclusions and Overlapping Subnets
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.
Fill in values for your own network
- 100.64.0.0/10 tailnet address range
- The actual LAN subnet at home or in the office
- Subnet routes approved in the Tailscale console
- Subnets in Docker, WSL, or virtual machines that actually overlap the tailnet
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.
For overlapping subnets, first change the address plan of a LAN, Docker network, or virtual machine you control. Repeatedly raising route priority for the same subnet is not a lasting solution; it may fail again after switching networks, waking, or upgrading.
If the IP works but the device name fails, address MagicDNS rather than routing
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.
Use tailscale status to obtain the target device’s address, then compare its short and full tailnet names with the operating system’s native resolver. On some platforms, nslookup does not read system DNS settings, so its result alone does not show that MagicDNS has failed.
On macOS, run dscacheutil -q host -a name DEVICE_NAME, replacing DEVICE_NAME with the short name. Read name and ip_address, then repeat the query with the returned full tailnet name and compare the addresses with the target device.
During troubleshooting, disable the browser’s independent DoH and check Clash nameserver-policy or local-domain exclusions. Do not forward tailnet names to public DNS.
If Access Fails After Wake or a Wi-Fi Change, Compare Routes and Resolution After Reconnection
After the laptop wakes, switches from Ethernet to Wi-Fi, or connects to a phone hotspot, wait for both clients to reconnect, then compare routes and name-resolution results. Recovery after restarting one tool in a fixed sequence is a clue to investigate startup or reconnection. Compare the before-and-after records to identify what changed; recovery alone does not establish the cause.
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.
Do Tailscale Private-Network Access and Clash Internet Routing Both Work?
Verify everything in the same test cycle
Access a tailnet IP
Proves that the 100.x route still belongs to Tailscale.
Access a tailnet name
Proves that MagicDNS or the dedicated resolver still works.
Access an advertised subnet
Confirms that the approved subnet route was not captured by Clash.
Access the public internet and inspect Clash records
Proves that ordinary routing still uses the intended policy.
If a tailnet IP, device name, advertised subnet, or public internet request fails, check the corresponding route, DNS, subnet, or default exit.