Connectivity Troubleshooting · Clash Technical Blog

What to Do When OpenClash Cannot Resolve an IPv6 Node Domain

If node resolution fails in OpenClash and public IPv6 DNS returns 198.18.x, check the OUTPUT counters and the v0.47.156 fix. After upgrading, verify resolution, proxying, and direct access; restore the original settings if problems occur.

Read the articleBack to blog
  • OpenClash
  • IPv6
  • DNS hijacking
  • SmartDNS
  • Node resolution
On this page
Published
Updated
Estimated reading time
About 9 minutes

A failed domain query from the router itself requires different evidence from a home device simply losing connectivity. Check whether a query intended for a public resolver returns the proxy’s virtual addresses instead. The response and firewall counter must match this pattern before proceeding with a plugin upgrade or temporary workaround, rather than turning off every related feature.

A query to public IPv6 DNS returns 198.18.x

Check the state of OpenClash IPv6, router-local proxying, local DNS hijacking, and Fake-IP. With those features enabled, check whether SmartDNS or another resolver on the router receives 198.18.x when querying public IPv6 DNS, and whether proxy nodes with domain-based server addresses fail to connect at the same time.

An ordinary endpoint that cannot load webpages, a LAN device without IPv6, a failed subscription download, or a DNS port occupied by AdGuard Home does not prove the same issue. First confirm that the failure occurs in a query from the router itself to public IPv6 DNS; do not disable IPv6 across the network at the first sign of trouble.

Continue only when all these conditions are met

  • The OpenClash version is older than v0.47.156, which contains the fix, or the service has not been restarted after upgrading
  • The system uses fw4/nftables or legacy ip6tables, and proxying of router-originated traffic is enabled
  • Local DNS hijacking and Fake-IP are enabled, and the router runs a resolver such as SmartDNS
  • The resolver uses a public IPv6 DNS upstream, and the node server address is a domain

Save the plugin package and DNS settings, and keep router management access available

Record the plugin and core versions, operating mode, and SmartDNS upstream servers. Follow the steps below to save the settings, configuration, and installation package so you can restore them if the upgrade fails.

During testing, do not change the subscription, rules, DNS upstream, and runtime mode together. Change only one item at a time and retain query results from before and after the change; otherwise, even if nodes recover, you will not know which step worked.

Prepare rollback materials

  1. Export the plugin settings

    Back up the settings and current configuration in Configuration File Management, then download them to a device outside the router.

  2. Keep the original package

    Save the official IPK or APK for the current release, and note whether the system uses opkg or apk.

  3. Record the triggering settings

    Write down the state of IPv6, proxying of router-originated traffic, local DNS hijacking, Fake-IP, and the SmartDNS IPv6 upstream.

  4. Prepare a direct management path

    Confirm that you can manage the router over the LAN. During remote maintenance, do not change DNS or firewall settings without a backup connection.

Compare DNS answers and rule counters on the router

From the router terminal, query a real domain through a currently reachable public IPv6 DNS server. A normal result is the domain's public A or AAAA record. If it returns 198.18.0.0/16 and the corresponding IPv6 OUTPUT DNS Hijack rule counter increases between checks, the query is being incorrectly sent back to local Clash DNS.

The reproduction in OpenClash issue #5251 used 2400:3200::1. First confirm whether that address is appropriate for your network. If the IPv6 route itself is unreachable, a timeout proves only that the upstream is unavailable, not that hijacking occurred. You may also use any ordinary domain that you know has a public record.

Read the counters in the router’s SSH terminal. Choose one command for the firewall backend actually in use: the first for fw4/nftables, or the second for legacy ip6tables. Having both commands installed is no reason to mix them. Run the chosen command before and after the query without resetting counters or deleting rules.

fw4/nftables: list only the router’s own DNS rules
nft list chain inet fw4 nat_output
legacy ip6tables: read exact OUTPUT counters only
ip6tables -t nat -nvxL OUTPUT --line-numbers

In the fw4 output, find the rule that combines IPv6, UDP port 53, redirect and the OpenClash DNS Hijack marker. Compare packets and bytes in that rule’s counter line. The rule may combine TCP/UDP; totals for all OUTPUT traffic are not evidence about this query.

In the legacy output, find the IPv6 UDP/53 REDIRECT rule marked OpenClash DNS Hijack and read pkts and bytes on that same line. The old destination range is ::/0; the fixed rule matches only ::1, so a query to a public server should not increase its counters.

If you cannot find the matching rule or read its counters, save the version and query result and stop treating this fault as the reason to upgrade. A 198.18.x answer alone does not establish the same problem. Rule output may contain network information; redact it before asking for help publicly.

Specify an actually reachable public IPv6 DNS server on the router
nslookup www.nic.ad.jp 2400:3200::1

Choose the next step from the result

Query resultRule counterConclusion
Returns 198.18.xThe IPv6 OUTPUT counter increasesMatches the confirmed hijacking of router-originated IPv6 DNS
Returns a real A or AAAA recordThe counter does not increaseThis path works; investigate the DNS used to resolve nodes in the subscription
The query times outThe counter does not increaseCheck the IPv6 route and reachability of the selected DNS server first
LAN devices fail, but the router query worksNo corresponding changeInvestigate RA, DHCPv6, RDNSS, or secure browser DNS

Only SmartDNS queries fail, while the Mihomo upstream works

Check the process’s user group and where its queries go. Mihomo usually uses a GID (user group ID) excluded by the rules, while queries from other local resolvers may match OUTPUT rules.

Every DNS server returns connection refused

Check local listening ports and upstream configuration; do not apply this article's IPv6 rule fix.

A specified IPv4 DNS server works, but a specified IPv6 DNS server returns 198.18.x

Keep this comparison and the counter change, then proceed to the version upgrade.

Incorrect path from the router itself to public IPv6 DNS
  1. A local resolver such as SmartDNSSends a port 53 query to a public IPv6 address
  2. OpenClash OUTPUT ruleOlder releases use ::/0 and incorrectly match every IPv6 DNS destination
  3. Local Clash DNSThe redirected query returns 198.18.x in Fake-IP mode
  4. Proxy node domainThe incorrect result prevents a node using a domain from completing its dial

The fix narrows hijacking of router-originated IPv6 DNS from all addresses to the loopback address ::1. This change does not remove DNS interception rules for LAN devices.

Why public IPv6 DNS is treated as a local query

The old rule was intended to intercept only DNS that the router itself sent to the loopback address, but it defined the IPv6 destination range as ::/0. That range includes every IPv6 address, so TCP or UDP queries from SmartDNS to port 53 on a public IPv6 DNS server were also redirected to local DNS.

The problem is not that PR #5209 added ::/0. After that commit separated IPv4 and IPv6 rule detection, an old branch that had previously been skipped began running reliably, making the defect easier to expose starting with v0.47.117. PR #5252 changes two nftables locations and four legacy ip6tables locations to ::1 while preserving LAN-side DNS interception.

Upgrade to v0.47.156, which includes the fix

Official release records confirm that OpenClash v0.47.156 includes #5252. The upgrade steps below use this fixed version. If you already run a newer version, first check whether the same query results and counter changes occur; do not downgrade simply to follow these steps.

The old ::/0 rule may still be active in the firewall. The ::1 setting in the source code takes effect only after the rules are regenerated.

A rollback-ready upgrade

  1. Verify the system package format

    Use the official IPK for an opkg system and the official APK for an apk system, and confirm that the download comes from the v0.47.156 Release. Do not mix development-branch files or different package formats.

  2. Pause other changes

    Keep the original core, subscription, runtime mode, and DNS settings; upgrade only the OpenClash plugin.

  3. Install and restart the service

    After installation, restart OpenClash and wait for the firewall and DNS rules to regenerate.

  4. Check the logs before connecting

    Confirm that configuration testing, core startup, and DNS listening succeed. Restore the original package and backup if any step fails.

Recheck queries to public resolvers, local loopback queries, and node connections

Repeat the query on the same router with the same domain and public IPv6 DNS used before the upgrade. After the fix, it should return a real A or AAAA record, and the public query should no longer increase the IPv6 OUTPUT DNS Hijack counter. Queries to the local loopback ::1 can still be intercepted by OpenClash.

Fix acceptance checklist

  • The OpenClash version includes the v0.47.156 fix, and the service has been restarted after installation
  • A specified public IPv6 DNS server returns a real A or AAAA record instead of 198.18.x
  • Queries to public IPv6 DNS no longer increase the router-originated IPv6 hijacking rule counter
  • Local DNS interception still works for queries to ::1, and LAN device resolution is not broken
  • At least one original node completes domain resolution, connection establishment, and an actual page request, with a matching connection record

How to mitigate and roll back when an upgrade is not immediately possible

If you cannot upgrade yet, remove the public IPv6 DNS upstream from SmartDNS and use a verified reachable IPv4 upstream instead. You can also temporarily disable either proxying of router-originated traffic or local DNS hijacking. Each option changes the router's own traffic or DNS interception and must be tested separately; none is a long-term fix.

If problems worsen after the upgrade, disable OpenClash from the management page. If DNS still points to a stopped service, restore a reachable upstream. Once LAN management access works, restore the original plugin package and settings backup and restart the service. Repeat the pre-upgrade IPv4/IPv6 queries to check that the previous state has been restored.

If public IPv6 DNS now returns a real result but nodes still fail, investigate proxy-server-nameserver, subscription contents, TLS, and the node server; stop changing OUTPUT rules.

Impact of temporary workarounds

ActionSuitable situationMust recheck
Switch SmartDNS to a reachable IPv4 upstreamNode resolution must be restored before an upgrade is possibleLocal domains, cache results, and node domains all resolve correctly
Temporarily disable proxying of router-originated trafficOnly the router's own DNS is affectedEgress paths for router updates, subscriptions, and plugin downloads
Temporarily disable local DNS hijackingEndpoints can accept DNS delivered by DHCPWhether LAN devices bypass the intended routing and DNS policies
Restore the original package and configurationThe service will not start or the LAN loses connectivity after upgradingVersion, DNS listeners, firewall rules, and real browsing

References