On this page
To answer “is there a leak,” inspect the public outbound address, not a single green status
Clash does not automatically ensure that every app, DNS query, WebRTC connection, and IPv6 route uses the same outbound path. To identify a leak, separately record the public IPv4, IPv6, DNS servers, and WebRTC candidates before and after enabling the proxy.
Seeing a private address such as 192.168.x.x does not mean your real public IP has been exposed. What matters is whether your local ISP's public address still appears after the proxy is enabled.
Do not conflate these results
| Test item | Question it answers | What actually indicates a problem |
|---|---|---|
| Public IPv4 | Which outbound address the website sees | The proxy is enabled, but the address still clearly belongs to the local ISP |
| Public IPv6 | Whether IPv6 uses the same traffic-capture method | IPv4 uses the node, while IPv6 still connects directly through the local network |
| DNS servers | Who may be resolving queries | They differ from the configuration and cause domains to bypass the expected rules |
| 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 |
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, quit the browser completely, and reopen it. If DNS results return to the endpoint expected by Clash, you have found the cause. You can then keep resolution in the browser or delegate it to Mihomo; the key is not to override it in all three places.
If WebRTC shows 192.168.x.x, first confirm whether it is a private 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.
The real issue is a local ISP's public IPv4 or IPv6 still appearing after the proxy is enabled. Disabling WebRTC entirely breaks web meetings and screen sharing. Prefer the browser's address-limiting options, then retest Zoom, Meet, or Slack Huddle.
If IPv4 is correct but IPv6 connects directly, then decide whether to capture or disable it
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。Fix the item that differs; do not try to make all four columns show the same region
A DNS server and outbound node in different regions are not necessarily a problem, and a private WebRTC address does not by itself indicate a leak. Act only after confirming that a specific item still exposes a public outbound address that should not appear.
Public IPv4 still uses the local outbound route
The browser request did not enter the proxy; inspect the system proxy, extensions, and rule match.
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.