Fix IPv6 Leaks in Clash Dual-Stack: DNS, Direct Rules, and Verification Steps

Dual-Stack Symptoms That Look Like “Leaks”

The word leak is overloaded. Sometimes people mean DNS leak—queries that bypass your resolver policy and disclose domain intent to an ISP. Sometimes they mean IP leak—egress that does not traverse the proxy path you expect. On dual-stack networks the second meaning shows up constantly: applications happily open IPv6 sockets when AAAA records exist, and if your Clash policy only “felt complete” for IPv4, those flows can still march out the raw interface. Before you chase node quality, confirm whether the unhappy traffic is even matching your TUN capture and rule chain. For how kernel-level interception interacts with routing precedence, start with the TUN mode deep dive—without that mental model, IPv6 issues look like random proxy failures.

Another common mirage is “speed test shows my carrier IPv6.” That result is not automatically proof that your proxy failed; it may simply mean the test used IPv6 by preference, or that your tunnel does not rewrite that family the way you assumed. Your job is to make behavior predictable: either IPv6 is fully inside policy, fully direct for domestic sites, or turned off deliberately. Guessing breaks troubleshooting. Pair tunnel understanding with resolver hygiene from the Clash Meta DNS guide, because DNS decides whether applications even attempt IPv6 endpoints.

Finally, remember that Clash evaluates rules on what it can see. If your profile leans on IPv4 GEOIP matches but the flow is IPv6, you may miss the DIRECT branch you thought you wrote. Sequencing and address families matter; for the broader discipline of ordering, catch-alls, and split traffic, keep rules and routing best practices open while you read the sections below.

Why IPv6 Is a Second Default Path

In dual-stack, operating systems typically implement Happy Eyeballs-style racing: IPv6 and IPv4 attempts may run in parallel or with a slight preference for IPv6 when connectivity looks viable. Your proxy stack must therefore participate in both families or explicitly remove one from consideration. A profile that only redirects IPv4 through a tunnel interface can still leave IPv6 on the physical NIC’s default route—exactly the “partial leak” users describe when chat apps work through the tunnel but a browser test prints an ISP address.

Router advertisements and DHCPv6 also push prefixes without asking your permission at the application layer. Even meticulous YAML cannot compensate for an OS that prefers a global IPv6 source address you never routed through Clash. That is why the fix is almost always a bundle: resolver policy + tunnel coverage + rule coverage for both families + sometimes disabling IPv6 at the interface when you need a hard guarantee.

DNS, AAAA Records, and the dns: Block

DNS is not “later tuning”—it is how your machine learns whether to dial IPv6 at all. When a resolver returns a juicy AAAA record, many stacks will try it. Your dns: stanza should therefore make a deliberate statement about IPv6 resolution: Meta-class cores often expose an ipv6: boolean under dns:. Setting ipv6: false asks the core not to synthesize or prioritize IPv6 answers in ways that fight your intent; combine that with OS-level IPv6 toggles if you need a stronger guarantee.

Hijack behavior matters just as much as the YAML. If applications still talk to a remote DoH server or to your router’s forwarder, you can get “correct” browsing with inconsistent policy application. Follow the resolver pipeline in the Meta DNS walkthrough: nameserver, fallback, fake-ip-filter, and how TUN DNS hijack actually pulls queries into Clash. Misaligned hijack looks exactly like a leak—even when your proxies: section is perfect.

If you run enhanced-mode: fake-ip, remember that fake addresses interact with domain rules. LAN and portal names that must stay real belong in fake-ip-filter; see the Fake-IP LAN and router guide when IPv4 worked but IPv6 or router checks behave oddly.

dns:
  enable: true
  listen: 0.0.0.0:53
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

Treat the snippet as a starting point, not dogma. Some networks require IPv6 DNS for correctness; others fall apart unless you stop returning AAAA answers to clients that will then attempt unrouted IPv6. Your logs—not superstition—should decide.

TUN, Hijack, and Making One Resolver Story True

TUN mode is the usual answer to “this app ignores system proxy,” but TUN does not automatically fix DNS unless you enable the hijack features your GUI exposes and your OS allows. On some platforms, local privilege, firewall rules, or competing VPN kernels still intercept pieces of the stack. Work through the capture story in order: confirm the tunnel interface is up, confirm DNS queries hit Clash’s listener, then confirm outbound flows attach to the intended policy group.

When multiple tunnel products stack, IPv6 is often the first family to slip past a half-installed filter. If you recently switched clients, verify you are not mixing an old Wintun adapter with a new userspace binary. The cleanup patterns in no internet after exiting Clash are not only for offline recovery—they are a template for spotting orphaned interfaces that still attract routes.

DIRECT Rules, GEOIP, and IPv6 Literals

Domestic bypass rules—commonly GEOIP,CN,DIRECT or provider-maintained rule-set files—need to match the address family you actually see. If your logs show IPv6 literals that never hit the China geo branch you expected, widen coverage deliberately: some databases split entries; some flows arrive as raw IPs that demand explicit IP-CIDR6 handling. Avoid the trap of a gigantic catch-all proxy rule above careful DIRECT exceptions; ordering is policy, as emphasized in routing best practices.

When you must pin certain subnets to direct transport, express them explicitly rather than hoping a broad geo tag does double duty. Document why each IP-CIDR6 line exists—future you will not remember which forum post justified it.

rules:
  - IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Replace the placeholder prefix with addresses relevant to your region and threat model. The no-resolve hint prevents expensive DNS round-trips when you already have an IP literal in hand.

When to Disable or Constrain IPv6 (OS and Router)

If your goal is a single, auditable path—everything through Clash or everything direct—disabling IPv6 on the active interface is blunt but effective. On Windows, adapter properties expose IPv6 toggles; on macOS, system network settings or interface-scoped commands can prefer IPv4; on Linux, sysctl and NetworkManager profiles offer per-interface control. Disabling at the router stops advertisements to the whole LAN, which helps household devices you cannot profile individually.

The trade-off is real: some ISPs and mobile networks now assume IPv6 for latency or reachability. If you disable blindly, you may swap a routing mystery for legitimate connectivity loss. Treat disable as a test knob: turn it off, rerun your verification suite, then decide whether to keep it or invest in proper IPv6 policy inside Clash instead.

Pick a client that surfaces per-stack state clearly; opaque one-click modes hide exactly the dual-stack gaps discussed here. Choosing a Clash client with readable YAML and honest TUN diagnostics pays off faster than chasing leaks you cannot see.

Verification: Leak Tests You Can Repeat

Build a short checklist and run it after every profile change—especially after remote rule-provider updates that might reorder catches.

1. DNS path: With Clash running, trigger lookups for a test domain and confirm the core’s DNS log shows the query—not your ISP’s resolver landing page unless you intended it.
2. IPv6 surface: Use public “what is my IP” tools that report both families; compare against expectations for proxied versus direct egress. Repeat on Wi-Fi and tethering if you roam.
3. Transport reality: For command-line users, curl-style probes to IPv4 and IPv6 endpoints (where permitted) expose which family actually succeeded.
4. Consistency: Run the same trio twice: before enabling TUN, after enabling TUN, and after toggling your IPv6 disable test—delta beats anecdote.

Keep notes with timestamps. Dual-stack issues love to correlate with router firmware updates, OS upgrades, or a GUI that silently turned secure DNS back on.

Fake-IP, LAN, and Split-Horizon Edge Cases

Corporate split DNS and home NAS names are fragile under fake-ip. If IPv4 magically works while IPv6 clients stall, you may be staring at a synthesis filter omission rather than a “bad node.” Revisit fake-ip filter lists whenever you add hardware that introduces new .local or vendor portal hostnames.

Gateways and OpenWrt-Style Setups

When Clash runs on a gateway instead of a laptop, DHCP may hand clients DNS that bypasses the core unless you redirect DNS transparently and think about IPv6 RA lifetimes. Router guides differ from desktop guides; for bridge versus gateway placement and DNS redirection discipline, read OpenClash on OpenWrt: gateway, DNS, and bypass patterns alongside this article. The failure mode is the same—two resolver stories—only the scale is larger because every phone on Wi-Fi inherits whatever DHCP pushed.

Wrap-Up

Clash IPv6 confusion rarely comes from a single missing checkbox; it is the combination of dual-stack precedence, resolver behavior, tunnel capture, and rule coverage across families. Align DNS with your tunnel, make DIRECT rules truthful for both IPv4 and IPv6, and validate with disciplined leak tests instead of one-off speed runs. When you need a hard stop, disabling IPv6 is a legitimate experiment—just measure before and after so you trade mystery for data.

Compared with opaque “VPN” apps that hide routing families, explicit Clash profiles reward you with inspectable policy—if you meet them halfway and read what the OS is actually doing.

→ Download Clash for free and experience the difference—pick a client that shows TUN, DNS, and YAML clearly, then prove dual-stack behavior with tests you can repeat any week.