1. Why “proxy on” is not one pipe
Clash-family cores forward application traffic that reaches their inbound according to your rules and outbounds. That is powerful, but it is not magic mind-reading for every subsystem on your machine. A typical browser uses HTTPS for page loads, yet it may also open UDP sessions for Web Real-Time Communication (WebRTC) used by video calls, some CDNs, and certain “what is my IP” widgets. Those UDP flows often ignore HTTP CONNECT style proxies unless you are in a capture mode that actually sees them—commonly TUN with correct routing, or a browser that disables WebRTC entirely.
DNS is another parallel story. Even when HTTPS tabs ride your proxy, the operating system or the browser may still resolve hostnames through plain UDP to your ISP, through Windows Secure DNS, or through Chrome’s built-in DoH. If queries never pass through Clash’s DNS listener, your split routing rules never get a chance to steer them, and leak-test sites that print “DNS servers” will list resolvers that have nothing to do with your exit node. The symptom feels like “Clash is broken,” but the configuration gap is usually resolver placement, not node quality.
| Channel | What often goes wrong while Clash “works” |
|---|---|
| HTTPS via proxy | Pages load; IP widgets may still use other stacks—do not treat this alone as proof of full egress alignment. |
| WebRTC (often UDP) | Bypasses classic system proxy; may reveal local or ISP paths unless disabled or captured by TUN. |
| DNS / DoH | Browser or OS resolver bypasses Clash DNS; GEOIP and domain rules see different geography than you expect. |
Keep expectations honest: public IP check sites mix techniques. Some only read the remote address of a simple HTTPS request—those usually follow your proxy. Others actively probe WebRTC candidates or DNS resolver identity. Treat contradictory results as diagnostic data, not as a referendum on whether your subscription is “fake.”
2. WebRTC leaks: tests and fixes
WebRTC discovers network paths—NAT types, local LAN addresses, and sometimes public endpoints—through Interactive Connectivity Establishment (ICE). For privacy testing, the painful part is that ICE can reveal an IP that is not the one your HTTPS requests use, even when Clash handles those requests beautifully. That is why two panels on the same page disagree: one reflects the proxied TCP TLS stack; another reflects peer discovery.
Start with a controlled comparison. Open a reputable leak test in a profile with no extensions, then repeat in a clean browser profile. Extensions that promise “privacy” sometimes break or duplicate WebRTC in ways that look like proxy failure. If the leak disappears when WebRTC is off, you have isolated the class of problem; if it persists, return to capture mode and routing later in this guide.
Browser-side mitigations
In Firefox, you can tighten WebRTC behavior through advanced preferences—for example settings that disable non-proxied UDP or force relay-only candidates (exact names vary by version; search Mozilla’s current documentation for WebRTC network settings). In Chromium-based browsers, enterprise policies and flags change over time; some users rely on dedicated extensions or hard toggles that block WebRTC entirely. The trade-off is real: disabling WebRTC can break legitimate video conferencing sites. Many people use a second browser profile for sensitive browsing with WebRTC locked down, and keep another profile default for meetings.
If you need WebRTC to work and you need it to respect your proxy path, you usually move from “HTTP proxy only” to TUN mode so the core can see the relevant packets, then verify with your client’s docs that UDP is handled the way your rules expect. A system proxy alone is often insufficient for ICE when applications insist on host UDP semantics.
3. DNS leaks and DoH vs Clash
A DNS leak, in the everyday sense, means your queries reach resolvers that trace back to your ISP, school, or a public anycast network you did not intend—so observers learn which hostnames you looked up even if HTTPS content is encrypted. DNS-over-HTTPS in the browser encrypts the query to a chosen provider, but it also bypasses a local DNS forwarder unless you deliberately integrate the two stacks.
Clash and Mihomo can run a local DNS stack with dns.enable, enhanced-mode such as fake-ip or redir-host, nameserver lists, nameserver-policy, and fallback chains. That design is ideal for split routing: domestic domains resolve one way, overseas domains another, and domain rules line up with the answers your core sees. The failure mode appears when the browser’s secure DNS feature still sends queries straight to Cloudflare or Google, so Clash never participates—your rules still run, but they operate on different facts than the browser’s resolver layer.
Walk this sequence on paper before editing random YAML: (1) Which resolver does the OS use? (2) Which resolver does the browser override with DoH? (3) Which resolver does Clash expose on its mixed port or tun interface? When those three answers disagree, leak tests that print resolver hostnames will look “wrong” even when your exit IP for HTTPS is correct.
For deep dives on placeholder addresses and resolver order, pair this article with our fake-ip and DNS troubleshooting guide, which covers fake-ip-filter and common sniffer interactions without repeating the entire YAML cookbook here.
4. Verifying resolver and rule alignment
Once WebRTC is either controlled or ruled out, verification becomes systematic. Pick one target domain you care about—say a streaming or AI hostname—and record three things from your Clash GUI or logs: the DNS answer the core used, the rule that matched, and the outbound selected. Then, in the browser, open the developer tools network panel and confirm the request you think is proxied truly uses the proxy profile you enabled. Mismatches here are often simple: the tab was opened before you toggled TUN, or an extension pinned a different proxy.
Log verbosity matters. Temporarily raise DNS logging (wording depends on your build) so you can see whether queries hit Clash’s listener or skip it. If nothing ever arrives, your leak is upstream of rules—fix listener address, firewall, or browser secure DNS first. If queries arrive but answers flicker between upstreams, revisit fallback-filter and geographic filters copied from old templates; aggressive filtering can send international domains to a domestic resolver “for reliability,” which then steers GEOIP rules wrong.
On Windows, mixed setups with WSL or containers add another resolver dimension. If terminals and browsers disagree, read WSL2 and localhost DNS with Clash on Windows so you are not debugging two unrelated networks as one problem.
# Illustrative excerpt — confirm keys against your core and GUI export
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
nameserver:
- https://dns.example/dns-query
nameserver-policy:
"geosite:cn": https://doh.cn.example/queryUse such snippets as documentation of intent, not as drop-in secrets: replace endpoints with ones you trust, align ports with what your GUI actually binds, and restart the core after changes so you are not staring at stale listeners.
5. Split routing without surprise exits
Split routing is the art of sending only some traffic to proxies while leaving the rest DIRECT. It is efficient and often necessary for latency-sensitive domestic services. The configuration cost is cognitive: every exception is a chance for a user to think “the proxy failed” when the rule did exactly what it was told. When leak tests show a domestic IP, check whether the test hostname matched a direct rule by design—some “what is my IP” domains are classified in geodata as regional or CDN nodes that your profile handles locally on purpose.
Ordering still beats cleverness. Place narrow DOMAIN-SUFFIX lines for services you truly want on a specific outbound ahead of broad GEOIP or MATCH catch-alls. When debugging leaks, temporarily force the test domain to your proxy group to see whether the symptom is policy placement rather than WebRTC. Revert after the experiment so you do not carry a permanent footgun.
Compared with opaque one-click “accelerators,” Clash-family clients expose enough logging to learn which rule owned a flow. That transparency is the point: once WebRTC and DNS are honest, rule tuning becomes a fair conversation between you and your YAML instead of a mystery.
For TUN-specific routing and firewall symptoms that masquerade as leaks—everything looks direct because the tunnel never grabbed the flow—see Clash TUN on Windows: routing and firewall troubleshooting. A mis-scoped tunnel can make HTTP tests look “fine” while UDP or DNS still escape, or the opposite, depending on the OS.
6. IPv6 and secondary interfaces
IPv4-only mental models break quietly on dual-stack networks. Some leak tests prefer IPv6 paths, and if your proxy subscription or node setup focuses on IPv4 while your ISP hands you a global IPv6 address, panels can disagree in ways that feel like betrayal. Quick sanity checks: temporarily disable IPv6 at the OS level for a controlled test, or ensure your rules and outbounds account for IPv6 if you intend to route it. Document what you changed; leaving IPv6 off forever is not always acceptable for every network.
Secondary interfaces—VPN adapters, corporate Ethernet, tethered phones—also reorder routing tables. Clash may be “on,” yet specific applications still bind to a different interface by policy. If leaks correlate with plugging in USB tethering or joining a guest Wi-Fi, capture the interface list and metric before you blame the exit node.
Corporate and school networks sometimes deploy transparent proxies or DNS interception that conflict with local forwarders. In those environments, success may require explicit bypass lists or different modes entirely; repeating “just toggle TUN” without reading captive portal behavior wastes time.
7. Summary
If Clash is running but leak tests still show your real IP, work in layers: confirm whether WebRTC exposes a parallel path, then whether DNS or DoH bypasses Clash’s resolver, then whether split routing rules intentionally send the test traffic DIRECT. Each layer has different fixes—browser toggles, TUN capture for UDP, resolver alignment, rule ordering—and mixing them randomly produces the infamous “nothing works” thread where every screenshot contradicts the last.
Compared with chasing subscription updates whenever a page disagrees with you, this structured checklist usually finishes faster and teaches you how your own machine actually behaves. For authoritative configuration fields while you tune profiles, keep our configuration documentation open next to your client, and install builds from the official download page so GUI features match the guides you follow.
Open-source cores move quickly; when a leak only appears on one release channel, compare notes in the upstream Mihomo repository on GitHub for DNS or TUN regressions—while still treating user-facing installers as a separate concern from raw source clones.