On this page
Confirm whether this is the IPv6 DNS hijacking issue
This article covers a clearly defined OpenClash failure: with IPv6, proxying of router-originated traffic, local DNS hijacking, and Fake-IP enabled, a resolver such as SmartDNS on the router receives a 198.18.x address when querying public IPv6 DNS. Proxy nodes whose server address is a domain then cannot connect.
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 a rollback-ready version before changing settings
First back up the OpenClash plugin settings and current configuration, then save the currently installable IPK or APK. Record the plugin version, core version, runtime mode, IPv6, proxying of router-originated traffic, local DNS hijacking, and the SmartDNS upstream. This lets you return to the original state if the network becomes worse after an upgrade or change.
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
Export the plugin settings
Back up the settings and current configuration in Configuration File Management, then download them to a device outside the router.
Keep the original package
Save the official IPK or APK for the current release, and note whether the system uses opkg or apk.
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.
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.
Locate the issue with a query to a specific server and rule counters
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.
nslookup www.nic.ad.jp 2400:3200::1Choose the next step from the result
| Query result | Rule counter | Conclusion |
|---|---|---|
| Returns 198.18.x | The IPv6 OUTPUT counter increases | Matches the confirmed hijacking of router-originated IPv6 DNS |
| Returns a real A or AAAA record | The counter does not increase | This path works; investigate the DNS used to resolve nodes in the subscription |
| The query times out | The counter does not increase | Check the IPv6 route and reachability of the selected DNS server first |
| LAN devices fail, but the router query works | No corresponding change | Investigate RA, DHCPv6, RDNSS, or secure browser DNS |
Only SmartDNS queries fail, while the Mihomo upstream works
Verify the process identity and path. Mihomo normally runs with an excluded GID, while other local resolvers may match the OUTPUT rule.
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.
- A local resolver such as SmartDNSSends a port 53 query to a public IPv6 address
- OpenClash OUTPUT ruleOlder releases use ::/0 and incorrectly match every IPv6 DNS destination
- Local Clash DNSThe redirected query returns 198.18.x in Fake-IP mode
- 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
OpenClash v0.47.156 is the current stable release officially confirmed to include #5252. Use the official Release package for your system and upgrade with the actual package manager, opkg or apk. Do not mix development-branch files, IPK, and APK, and do not change the core and configuration during the upgrade.
You must restart OpenClash after installation. The old ::/0 rule may remain active at runtime; only regenerating the firewall rules makes ::1 from the source take effect. If startup fails, immediately restore the saved original package and configuration instead of stacking more changes.
A rollback-ready upgrade
Verify the system package format
On an opkg system, choose the official IPK; on an apk system, choose the official APK. Confirm that the download comes from the v0.47.156 Release.
Pause other changes
Keep the original core, subscription, runtime mode, and DNS settings; upgrade only the OpenClash plugin.
Install and restart the service
After installation, restart OpenClash and wait for the firewall and DNS rules to regenerate.
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.
Run three groups of checks after restarting
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.
After the DNS comparison passes, test the original node that uses a domain. Observe resolution, dialing, and a real webpage request. A latency number alone is not enough; confirm that at least one node appears in connection records and one actual page loads.
Fix acceptance checklist
- OpenClash shows v0.47.156, and the service was 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
- The original node resolves its domain, dials successfully, and completes one real request
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 the issue broadens after upgrading, disable dependencies on the system proxy and TUN, restore the original plugin package and settings backup, restart OpenClash, and repeat the pre-upgrade IPv4/IPv6 query comparison to confirm that the original state has returned.
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
| Action | Suitable situation | Must recheck |
|---|---|---|
| Switch SmartDNS to a reachable IPv4 upstream | Node resolution must be restored before an upgrade is possible | Local domains, cache results, and node domains all resolve correctly |
| Temporarily disable proxying of router-originated traffic | Only the router's own DNS is affected | Egress paths for router updates, subscriptions, and plugin downloads |
| Temporarily disable local DNS hijacking | Endpoints can accept DNS delivered by DHCP | Whether LAN devices bypass the intended routing and DNS policies |
| Restore the original package and configuration | The service will not start or the LAN loses connectivity after upgrading | Version, DNS listeners, firewall rules, and real browsing |