Connectivity Troubleshooting · Clash Technical Blog

OpenClash: fix Tailscale DNS conflicts

OpenClash proxying the router's own traffic conflicts with Tailscale DNS: a device works by IP but not its full ts.net name? Compare two resolvers, check the v0.48.002 module, restart and verify, then restore the original settings if needed.

Read the articleBack to blog
  • OpenClash
  • Tailscale
  • MagicDNS
  • Overwrite Module
  • v0.48.002
On this page
Published
Updated
Estimated reading time
About 10 minutes

If the same device is reachable by IP but not by its full domain name, name resolution needs further checking. The router and devices on the local network may use different resolvers, so test them separately. Keep the original settings and management access available before comparing which change restores the service you need.

Tailscale is online, so why can't the router resolve names?

Confirm that OpenClash and Tailscale both run on the same OpenWrt router, then record access by device IP and by its full ts.net name. If accepting Tailscale DNS causes domain requests from the router itself to behave abnormally, also record results from the router’s own DNS and from devices on the local network.

OpenClash released v0.48.002 on 2026-10-12. Its release notes introduce a default Tailscale module for problems that can occur when accept-dns is enabled while proxying the router's own traffic. The module only assigns Tailscale DNS to ts.net domains; it is not a general fix for every DNS, routing, or firewall problem.

The router's tailscaled must be running and Tailscale connected. Do not copy the router module setup when desktop Clash runs only on a computer, or Tailscale runs on another LAN device. Resolve login, disabled MagicDNS, offline devices or access-policy rejection first.

Compare the device IP, full name, and two DNS answers

Open LuCI through the router's LAN address first. Keep backups of the OpenWrt and OpenClash settings, the current subscription, and custom modules. Record the plugin and Tailscale versions, the setting for proxying the router's own traffic, the original accept-dns value, and the module's enabled state. If Tailscale is your only remote management path, postpone restarts and DNS changes until you have a local way to manage the router.

Read the Tailscale status on the router. In your own admin console, find the full MagicDNS name and IP of an online device. Compare access to the same service by IP and by name. If access by IP also fails, check the device, service, routes, and access permissions; a DNS module alone cannot diagnose or fix that failure.

Replace the name in both nslookup commands below with your own full name. Use the router's actual local DNS address as the second server. 127.0.0.1 is only a common example: first confirm that it really provides DNS on your router. Run both tests on the router, and do not distribute the Tailscale DNS address to every device as if it were a normal public DNS server.

DNS hijacking on the router can redirect requests addressed to a specific server. Specifying 100.100.100.100 does not prove that you have bypassed the plugin. If needed, while managing the router locally, record the original state, briefly disable OpenClash while leaving Tailscale running, repeat the test, and then restore it. This temporarily affects LAN proxying, so choose a time when an interruption is acceptable.

In Fake-IP mode, a local DNS answer in 198.18.x does not automatically mean resolution is broken. Also access the same service using its full name and inspect the core logs for the actual destination. A timeout, SERVFAIL, NXDOMAIN, or successful access by IP but failed access by name gives you a reason to keep checking the lookup path.

Compare lookups on the router; replace the example name and local DNS address first
tailscale version
tailscale status
nslookup device.your-tailnet.ts.net 100.100.100.100
nslookup device.your-tailnet.ts.net 127.0.0.1

Choose the next step from the comparison

Observed resultNext step
The device is reachable by IP and Tailscale DNS is confirmed to resolve its name, but local access by name failsCheck whether the request reaches OpenClash DNS and whether the running configuration is missing a ts.net lookup policy or another setting overrides it. Then try the built-in module.
Tailscale DNS still cannot resolve the full name after DNS hijacking has been ruled outCheck tailscaled, the sign-in state, MagicDNS, and the name's spelling first. The module cannot replace the Tailscale DNS service.
The name resolves correctly, but the service connection failsCheck the target service, Tailscale routes, and access policies. Do not keep changing DNS in the hope that one setting will work.
Only the router has trouble with ordinary public domains; LAN devices work normallyKeep a record of the difference and inspect the router's local DNS and accept-dns. Do not immediately attribute this symptom to a missing ts.net module.

Enable the built-in Tailscale module on the status page

If an older version lacks this built-in entry, do not substitute an unfamiliar script for an upgrade. This adjustment also does not require upgrading the entire router firmware or resetting all configuration.

Apply the module to the running configuration

  1. Check the plugin version actually running

    Update the plugin using the official v0.48.002 Release linked at the end and your existing upgrade method, retaining the pre-upgrade backup. Check the actual version in LuCI afterward and confirm the original subscription still starts. If installation fails, recover according to the error and backup.

  2. Open Overwrite Module from the status page

    Go to Services → OpenClash and open its status page. Click Overwrite Module at the top, then select the built-in Tailscale module on the left of the dialog. This is a different entry from the Overwrite Settings page in the menu.

  3. Confirm the scope, then enable the module

    On a new installation, the built-in Tailscale module is disabled by default and applies to all configurations. If an upgrade retains older settings and the module appears unconfigured with no toggle, use its gear control to set the scope to all configurations or the full path of the current configuration, then enable it. Record the original values. You do not need to edit the content, create a copy, or refresh the remote subscription.

  4. Restart and inspect the running configuration

    After closing the editor, restart OpenClash from the status page. In the actual running dns.nameserver-policy, confirm that +.ts.net points to 100.100.100.100#DIRECT. Saving alone or reloading the firewall does not reapply the module.

The official module's content is shown below only for comparison with your existing module. [YAML] and nameserver-policy+ belong to the OpenClash overwrite format; the running Mihomo configuration uses nameserver-policy. Do not paste the whole block directly into the subscription YAML or add a duplicate module.

DNS content of the built-in Tailscale module in v0.48.002
[YAML]
dns:
  nameserver-policy+:
    '+.ts.net':
      - 100.100.100.100#DIRECT

100.100.100.100 is the DNS service address provided locally by Tailscale, and #DIRECT sends the matching DNS requests directly. This module does not start tailscaled or change Tailscale routes, access policies, or accept-dns. If another module already defines a policy for the same domain, check the final running configuration rather than relying on the text in the editor.

Should you disable accept-dns? Use a recorded comparison

Do not disable Tailscale DNS on every device just to enable the module. Only test with it disabled when the original accept-dns value is true and the problem with ordinary domains appears with that setting. Do this through a LAN management connection and record the original value first. Disabling it stops this device from accepting the tailnet DNS settings and may affect system lookups for short MagicDNS names or custom domains.

Where supported, the Tailscale CLI command tailscale get accept-dns shows the current value. On an older version, check the help first. If the command is unavailable, confirm the value from existing settings records; do not assume an unknown value is true. Once you have confirmed the original value, use the command below only for this comparison. It does not mean every device should remain set to false.

Temporarily disable it only after confirming the original value and local management access
tailscale set --accept-dns=false

tailscale set updates only the parameters you explicitly specify. Do not add reset, sign-in, route-acceptance, or exit-node parameters. After disabling it, repeat the same public-domain lookup, full ts.net name lookup, and service-access tests, and save the differences. If nothing improves, restore the original value rather than adding further DNS changes.

If the original value was true, restore it with tailscale set --accept-dns=true. If it was false, keep false. The system resolver accepting Tailscale DNS and OpenClash sending ts.net queries to the local DNS service are separate settings. The module does not automatically make system short names, other private domains, or every LAN device work.

After the full name works, verify both the router and LAN

Using the same real, full ts.net name, repeat the two DNS tests, then access the same service on the same device. The real address returned by Tailscale DNS should match the device record. Check a local Fake-IP answer against the actual request and logs. A successful service request is the evidence that this access path has recovered.

The module matches only the ts.net suffix. If short names, other private domains, or non-Tailscale devices still fail, check their DNS, search domains, and network paths separately. LAN devices can use this policy only when their requests actually reach the configured resolver. Do not infer that every application across the network has automatically recovered.

Verify the changes

  • tailscaled is online, and the test device and service are still reachable at the original IP
  • The running configuration contains the expected ts.net lookup policy, with no override from another module
  • The router resolves the full MagicDNS name and completes a real service request
  • Ordinary public domains still work; separately test domain resolution and service access from the LAN devices you actually use
  • The policy survives a normal OpenClash restart, and the same tests still pass
  • The original module state, accept-dns value, and independent backup are recorded

How do you undo the changes if they fail or affect other devices?

Return to the Overwrite Module dialog and restore the Tailscale module's original enabled state and scope. Restart OpenClash and confirm that the running policy has returned to its previous state. If you also changed accept-dns temporarily, restore its recorded value, then test ordinary internet access and the original Tailscale access. There is no need to delete the entire configuration directory.

If the upgrade itself fails, keep the installation error and current data, and use the pre-upgrade backup to restore the plugin settings, subscription, and custom resources. Restoring settings and downgrading the program are separate operations. Do not assume an older plugin can read every setting written by the new version. Without evidence of compatibility, disable this module first and return to the previously working setup.

If the problem persists, generate an OpenClash debug log. Report the plugin, core, and Tailscale versions; the router's own traffic-proxying and DNS settings; the final domain policy; differences between the router and LAN; and the comparison results for the IP, full name, and two resolvers. Remove subscription tokens, passwords, device identities, and private domains before sharing. Do not publish the complete raw log.

References