OpenClash IPv6 Node DNS Troubleshooting

Identify whether the proxy hostname or destination hostname fails

When every node turns red after IPv6 is enabled, it does not automatically mean that IPv6 proxy servers are unusable. There are two names to consider. If a proxy server is configured as node.example.com, the core must resolve that hostname before it can build a tunnel. A website hostname is resolved according to the active DNS and routing policy before or through an established tunnel. A failure in the first path makes every service look like a node timeout; a failure in the second can occur while existing proxy connections remain alive.

Read the OpenClash core log for the server hostname, lookup, no such host, timeouts, and the selected DNS path. Never publish a real node hostname or subscription token. Replace them with placeholders while preserving the OpenClash version, router firmware, exact error category, and minimal reproduction sequence.

Configuration boundary: dns.ipv6: false changes how Mihomo answers AAAA queries, but it cannot replace checks of the router's IPv6 route, upstream DNS, and bootstrap resolution for the proxy itself.

Save the configuration and collect comparable evidence

Export the OpenClash profile and overrides, and write down the only setting changed between the working and failing states. Do not switch Fake-IP/Redir-Host, TUN, SmartDNS, and several upstream resolvers at the same time. Save the first startup log after restarting OpenClash; repeated profile reloads can hide the most useful initialization error.

Confirm that WAN and LAN have the intended IPv6 addresses and a usable default route.
Query both A and AAAA for the proxy hostname on the router.
Send the same query to the configured IPv4 and IPv6 resolvers separately.
Compare responses before and after the core starts.
Temporarily disable only the IPv6 DNS-capture layer and observe whether proxy resolution returns.

nslookup node.example.com is a useful basic observation, although BusyBox options differ by firmware. The meaningful evidence is a before-and-after comparison of the same hostname through the same upstream—not a single successful query to an unrelated public resolver.

Check bootstrap and proxy-server resolvers

Mihomo uses default-nameserver for bootstrap tasks such as resolving later DNS service names; the official reference requires IP-form servers in this field. proxy-server-nameserver is specifically for proxy-node hostnames. If the node can only be resolved through a proxy tunnel that has not been created yet, the configuration has a circular dependency.

YAMLdns:
  enable: true
  ipv6: true
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  nameserver:
    - https://dns.google/dns-query

This illustrates field relationships; it does not promise that those services are reachable through your ISP. Choose a bootstrap resolver the router can contact directly without the current proxy. An encrypted DNS hostname must itself be bootstrapped. After changing a LuCI option or override, inspect the final generated Mihomo configuration instead of assuming that the form value won the merge.

Trace the IPv6 upstream and interception path

Once IPv6 is active, the router may learn an IPv6 resolver from the ISP, while LAN clients may learn a different resolver through RA or DHCPv6. SmartDNS, dnsmasq, OpenClash, and client Private DNS can therefore send IPv6 queries through a path unlike IPv4. Map the actual chain from client to router port, local DNS service, and upstream before deciding where to inspect logs or packets.

Layer	Typical fault	Controlled check
IPv6 upstream DNS	No route or firewall block	Query A and AAAA against that exact server
Proxy hostname	Circular dependency on proxy	Use a directly reachable dedicated resolver
LAN client	Bypasses router DNS	Inspect RA, Private DNS, and packets
Fake-IP response	Returned to a host query that should not be captured	Compare responses with the core stopped and started

Disabling one IPv6 DNS proxy layer is a diagnostic test, not a universal permanent fix. If that restores resolution, continue until you can identify an unreachable upstream, an incorrectly intercepted port 53 request, a Fake-IP response entering router-host resolution, or a missing rule. Repair only that layer.

Use the v0.47.133 report within its stated boundary

OpenClash Issue #5251 describes one concrete environment: OpenClash v0.47.133 on a specified ImmortalWrt release. In that report, a router-host request to a public IPv6 DNS server was intercepted and given a Fake-IP response, after which proxy-node hostname resolution failed. The issue is closed. It establishes that this failure path has existed; it does not establish that every OpenClash release, firmware, or IPv6 failure has the same cause.

If your version, log, or packet route differs, do not copy a temporary workaround without analysis. Check the current release notes, generated firewall rules, and maintainer conclusion. If the result is reproducible, report it with a minimal configuration stripped of credentials. “It broke after IPv6” alone cannot distinguish an OpenClash regression from firmware, ISP DNS, or a custom override.

Avoid permanent edits to generated rules: OpenClash may recreate firewall and DNS state on restart or upgrade. Record every temporary change and keep a rollback path.

Restart cleanly and complete acceptance checks

Restart the DNS service first and then the OpenClash core so that stale caches do not make a change appear successful. Confirm in order that the router resolves the proxy through its bootstrap path, the node connects, ordinary A and AAAA results match policy, LAN clients do not bypass the intended resolver, and both direct and proxied destinations behave correctly in rule mode. Reintroduce SmartDNS or another advanced component one layer at a time.

Compare the generated fields with the first-party OpenClash default.yaml and the Mihomo DNS reference. Treat Issue #5251 as a version-bounded case report, not a general diagnosis.

The completion criterion is not merely “IPv6 is off and nodes work.” You should be able to explain which resolver handles each query, show that node resolution no longer depends on an unbuilt tunnel, and reproduce the correct state after a router restart.

Official sources and version scope

Version numbers, filenames, and interface labels can change. Confirm them in the linked project documentation before making changes.