Why “My IP” Sites Still Show Your Home Address

You already did the “reasonable” things: imported a subscription, picked a node, maybe flipped TUN because some apps ignore the system proxy. Pages load through the tunnel, streaming CDNs behave, and your latency panel looks alive. Then you open a speed test or a “what is my IP” page and it casually prints your real ISP address—the one you expected Clash to hide for routine browsing. That mismatch is maddening because it feels like proof your proxy is “not working,” even when ordinary HTTPS tabs clearly are.

Before you rip out profiles or accuse nodes, separate what channel the test is measuring. Many checks intentionally exercise browser APIs and peer-discovery paths that classical browser proxy settings never promised to cover. Two frequent categories get conflated: DNS and IPv6 leaks (resolver or dual-stack egress) versus WebRTC ICE behavior (STUN/TURN and candidate gathering inside the page). If you suspect dual-stack issues first, skim Fix IPv6 leaks in Clash dual-stack—it complements this article without repeating WebRTC specifics. This guide focuses on the second category so you can close the hole with small browser-side changes and then validate split routing with Clash logs, not guesswork.

What WebRTC Is—and Why HTTP Proxies Are Blind to It

Web Real-Time Communication (WebRTC) lets web pages build audio, video, and data channels between peers. To punch through NAT, browsers run ICE (Interactive Connectivity Establishment): they gather local and reflexive IP candidates—often including your public address as seen by a STUN server—and may try direct UDP paths that do not resemble “fetch this URL through port 443.” That design predates the mental model most people have of “everything goes through the HTTP proxy I set in the OS.”

Clash excels at steering TCP-heavy application traffic according to rules:, policy groups, and DNS policies you maintain; for background on resolver alignment, see Clash Meta DNS: nameserver, fallback, and fake-ip-filter. None of that automatically tells a random landing page, “Please do not ask WebRTC to disclose interface addresses.” A site that embeds a tiny script can request ICE candidates and display addresses that are truthful from WebRTC’s perspective even while the same tab’s ordinary navigation uses your proxy exit for HTTP. That is not necessarily “malware”—it is how real-time features work—but it is also why leak-test widgets exist.

ℹ Reading tests fairly: A page that prints “local” and “public” candidates is describing WebRTC’s view of paths, not your entire machine. Treat it as a browser capability audit, not a verdict on every protocol Clash handles elsewhere.

Chrome & Edge: Policy, Flags, and Extensions

Chromium-based browsers expose several levers, but vendors move them over time—so prefer stable user-visible settings when you can. Practical layers, from least to most invasive:

Microsoft Edge inherits Chromium behavior; align expectations with Chrome and validate after each major upgrade. If you maintain separate browsing profiles—one “strict” for sensitive tests—choosing a Clash client that mirrors your workflow (TUN vs system proxy) keeps the mental model consistent while you harden the browser separately.

Quick Chromium sanity checklist

  1. Close parallel tabs that might spawn workers (video calls, collaborative editors).
  2. Disable experimental “cast” or preview features while testing.
  3. Re-run the same leak page in a fresh profile; extensions differ per profile.

Firefox: about:config and Private Windows

Firefox users historically toggled preferences such as media.peerconnection.ice.default_address_only and related ICE flags to reduce host exposure. Names shift between Extended Support Release and Rapid channels—when you adjust about:config, note exact keys and Firefox version in your notes so upgrades do not silently revert semantics.

Private windows can reduce retained state but are not a cryptographic guarantee against a malicious page; they simply shrink accidental cross-site reuse. Combine preference tuning with the same external verification pass described later, and keep WebRTC tests distinct from DNS work: if resolver path is your pain point, Meta DNS tuning still matters in parallel.

Safari on macOS and iOS (Short Field Notes)

Safari exposes fewer knobs than Chromium or Firefox; mitigations often boil down to per-site permissions for camera/microphone (which gates many real-time surfaces), using a dedicated browser profile for sensitive sessions, and staying current with OS patches. iPhone and iPad browsers built on WebKit inherit platform rules—expect fewer low-level toggles and more reliance on OS-level controls and separate apps for conferencing.

The Minimal-Change Ladder: One Browser, One Profile

Users ask for “the smallest blast radius.” A sensible ladder is: (1) try built-in site permissions; (2) test a hardened secondary profile without unrelated extensions; (3) add a narrowly scoped extension proven on your channel; (4) only then consider OS-wide policy tooling. Pair this with Clash-side clarity: complicated LAN and fake-ip interactions belong in the Fake-IP LAN and router bypass guide, which is orthogonal yet frequently confused with “IP still showing” symptoms in browsers.

Repeatably Verify WebRTC Leaks (and Avoid False Alarms)

Ad-hoc checks invite ad-hoc conclusions. Use one or two established leak pages, the same browser build, and the same Clash mode each time. Record: Clash operating mode (TUN on/off), whether system proxy is set, and whether the test tab is incognito. Refresh twice; ICE results can race the first time after cold start.

Interpret results humbly: showing a reflexive candidate that matches your ISP does not prove every other application leaks—it proves WebRTC saw that path in this browser context. Your goal is narrower: decide whether candidate exposure is acceptable for how you use this browser alongside Clash.

If ordinary HTTPS IP checks show your proxy exit while WebRTC widgets still list your home WAN, you have likely isolated WebRTC as the noisy layer—treat that as progress, not contradiction.

Pair Leak Checks With Clash: TUN, Rules, and DNS

After browser mitigation, loop back to Clash so the story hangs together. TUN typically widens capture versus pure application proxy modes, but it is not a substitute for thoughtful split routing and rule order—see the TUN mode deep dive for stack-level behavior, and rules and routing best practices so DOMAIN-SUFFIX hygiene does not fight your leak-test domains unexpectedly.

Verification workflow: (1) reproduce the leak with one known page; (2) change exactly one variable—browser WebRTC setting or Clash mode—not both at once; (3) tail connection logs for the test hostname; (4) confirm DNS for that hostname traverses the resolver chain you intend. This isolates whether the unexpected address arrives from ICE rather than from a DIRECT rule you forgot. Advanced profiles mixing fake-ip with selective bypass entries should cross-check snippets against Fake-IP edge cases when LAN services are in play.

example — disciplined test matrix (notebook) 
Clash mode: TUN on | system proxy on | both
Browser: main profile | test profile | incognito
WebRTC setting: default | hardened | extension on
Leak page: same URL each run
Expected: WebRTC candidates shrink or proxy-aligned after hardening

When the Culprit Is Not WebRTC: IPv6, DNS, Fake-IP

Symptom overlap is real. If every IP widget—HTTP and WebRTC—shows your ISP, broaden the investigation: IPv6 egress, resolver bypass, or a mistaken DIRECT match can all imitate “proxy off.” The IPv6 article linked earlier walks dual-stack tightening; DNS articles cover encrypted resolver bypass; Fake-IP guides cover synthetic addresses for domains that must not be synthesized. Use the right tool for each layer instead of stacking contradictory mitigations.

Limits, Compliance, and Everyday Trade-offs

WebRTC exists because real-time collaboration needs nimble paths. Aggressive blocking can break legitimate conferencing sites—schedule mitigations around calls you care about. Corporate managed devices may forbid extensions or config edits; honor policy. This article addresses privacy hygiene for typical personal setups, not circumventing lawful controls.

⚠ Compliance: Respect local law and network policies. Use browser controls for legitimate privacy and reliability—not to defeat monitoring you are contractually or legally required to accept.

Wrap-Up

Seeing your real IP while Clash runs is not always a broken tunnel; often it is WebRTC doing its job too loudly inside the browser. Close or confine WebRTC with the smallest browser-side change you can sustain, then re-verify with stable tests while you align TUN, DNS, and rules in the core. That pairing—browser discipline plus coherent Clash configuration—cuts through false alarms and leaves real routing bugs nowhere to hide.

→ Download Clash for free and experience the difference after you confirm which layer leaked: WebRTC in the browser, or something else in the stack.