On this page
Seeing a private home-network address or a location that differs from the node’s name on a test page can look like a leak. Identify whether the result represents the outward-facing address seen by the website, a resolver, or a communication address discovered by the browser, then compare it with direct access. Change only confirmed proxy bypasses and check that meetings and normal connectivity still work.
What do public IPv4, IPv6, DNS and WebRTC each tell you?
Using the same browser and network, record IPv4, IPv6, DNS and WebRTC results separately and mark any public addresses belonging to your local ISP. WebRTC supports voice and video communication in the browser; the addresses it discovers are not necessarily the exit address seen by websites. Clash does not automatically route these requests through the same exit either.
Do not conflate these results
| Test item | Question it answers | Results to investigate | Test page |
|---|---|---|---|
| Public IPv4 | Which outbound address the website sees | A request that should use the proxy still shows the local ISP’s public address | BrowserLeaks IPv4 / IPv6 |
| Public IPv6 | Whether IPv6 uses the same traffic-capture method | IPv4 uses the node, while IPv6 still connects directly through the local network | BrowserLeaks IPv4 / IPv6 |
| DNS servers | Who may be resolving queries | They differ from the configuration and cause domains to bypass the expected rules | BrowserLeaks DNS |
| WebRTC candidate addresses | Which addresses the browser discovered for real-time communication | An unexpected real public outbound address appears; 192.168/10.x alone does not indicate a public leak | BrowserLeaks WebRTC |
Open the IPv4 / IPv6 or WebRTC link in the table. Under Your Remote IP, read IPv4 Address and IPv6 Address; under Your WebRTC IP, read Local IP Address and Public IP Address. Compare the public addresses with your direct-connection record and interpret private addresses as explained in the table.
Open the DNS link, select Run DNS Leak Test and record the Your DNS Servers list. Compare it with your configuration and direct-connection results. JavaScript Disabled, an empty result or an unfinished test does not establish that there is no leak.
Test direct access, the system proxy, and TUN separately
The test page itself is not the conclusion; only before-and-after results are meaningful. Use the same browser, network, and test page, change only Clash's traffic-capture method, and save all four results side by side.
A comparable test
Quit the proxy completely and record the direct connection
Save all four results—IPv4, IPv6, DNS, and WebRTC—instead of capturing only one green status.
Enable the system proxy
Open a new private window and test again to confirm that the browser request's outbound route changes.
Enable TUN if needed
Test on the same network and node, and observe IPv6 plus apps that do not honor the system proxy.
Inspect the connections screen every time
The result reflects the current Clash configuration only if the test domain appears and both its rule and outbound route match.
If only Chrome shows different DNS results, check Secure DNS
Chrome can enable Secure DNS separately under “Settings → Privacy and security → Security.” Firefox places DNS over HTTPS in its privacy settings. When the browser uses independent DoH, queries may bypass system DNS, and Clash's system proxy may not capture those resolution requests.
Temporarily disable browser DoH, fully quit the browser, and reopen it. If DNS results return to the resolver expected by Clash, the browser’s resolution settings affected this result. You can then keep resolution in the browser or let Mihomo handle it, avoiding simultaneous changes to resolution settings in the browser, system, and core.
How is a private address in WebRTC different from an exposed public address?
WebRTC gathers candidate addresses for voice, video, and peer-to-peer communication. Modern browsers may hide local addresses behind mDNS names or display private address ranges. That reveals information about the local network, but those addresses cannot be routed directly to your computer from the internet.
Take action when a request that should use the proxy still exposes your ISP’s public IPv4 or IPv6 to the other party. Disabling WebRTC entirely breaks browser meetings and screen sharing. Prefer the browser’s address restrictions, then retest functionality in Zoom, Meet, or Slack Huddle.
IPv4 uses the node but IPv6 exits directly: check traffic capture settings
A system proxy usually handles requests that an app explicitly sends to it; it does not guarantee capture of every IPv6 connection. Whether TUN handles IPv6 depends on the client version, routing, and configuration. First decide whether your workload needs IPv6. If it cannot be captured, temporarily disabling IPv6 for comparison reveals more than blindly adding REJECT at the end of the rules.
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
# 若明确需要 IPv6，应改为让当前 TUN 与规则完整接管，
# 而不是长期依赖 ipv6: false。How do you assess and handle public IP, DNS results, and private addresses?
Public IPv4 still uses the local outbound route
The browser request did not use the expected proxy node. Check the system proxy, extensions, and matched rule.
IPv4 uses the node, but IPv6 uses the local outbound route
Inspect the TUN IPv6 route; if IPv6 is unnecessary, disable it using the system's method for comparison.
Only DNS differs from expectations
Determine whether browser DoH, system DNS, or Mihomo DNS is actually handling the query.
Only a private local-network address appears
First confirm whether any real public candidate remains; do not classify a private address as a leak.