DNS leak troubleshooting fails when teams trust one screenshot and stop there. The reliable method is layered verification: ClashX runtime settings, macOS resolver state, browser DNS behavior, and independent leak tests.
This guide gives a reproducible checklist with concrete commands, interpretation patterns, and a worksheet you can reuse after every profile change.
What Counts as a DNS Leak
A DNS leak means domain lookups are resolved through an unintended resolver path, usually local ISP DNS, instead of the resolver route expected by your ClashX policy and outbound path.
If traffic egress appears proxied but DNS metadata still exposes local resolver identity, privacy and geolocation consistency are incomplete.
| Detection Result | Meaning |
|---|---|
| Resolver ASN = local ISP | Likely leak at system or browser layer |
| Resolver country != proxy exit country | Potential split path or browser DoH override |
| Resolver rotates between local and remote | Multiple interfaces or unstable resolver policy |
| One test site mismatches, others pass | Possible cache artifact or provider false positive |
| Browser shows private DoH provider hostname | Browser may bypass baseline system DNS path |
- Exit IP is remote, but DNS resolver belongs to local ISP.
- Resolver output changes every refresh without profile edits.
- Terminal DNS state and leak dashboards disagree repeatedly.
- Only one browser fails while another passes.
Critical ClashX DNS Settings
Most leak incidents start with incomplete DNS profile blocks. Build from a deterministic baseline before optimization.
Recommended baseline configuration
dns:
enable: true
listen: 0.0.0.0:53
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
use-hosts: true
nameserver:
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
fallback:
- tls://8.8.8.8:853
- tls://1.0.0.1:853
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4
domain:
- +.google.com
- +.facebook.comRule baseline to avoid accidental bypass
rules:
- DOMAIN-SUFFIX,local,DIRECT
- DOMAIN-SUFFIX,lan,DIRECT
- DOMAIN-KEYWORD,intranet,DIRECT
- GEOIP,LAN,DIRECT
- MATCH,PROXYdns.enable: falsewhile expecting ClashX-managed DNS behavior.- Dead DoH endpoints causing silent fallback to system resolver.
- Broad
fake-ip-filterentries that force bypass paths. - Mixed snippets from different profile generations.
Use fake-ip for stronger routing performance and scalability. Use redir-host where compatibility demands real DNS mapping. For leak analysis, test both modes once and document differences.
System Network Layer Checks
Correct YAML can still fail if macOS resolver priority is stale or duplicated. Validate system state before trusting web dashboards.
Terminal commands
scutil --dns
networksetup -getdnsservers Wi-Fi
networksetup -getdnsservers Ethernet
route -n get default
lsof -nP -iUDP:53
lsof -nP -iTCP:53 -sTCP:LISTENStep-by-step checks
- Disable non-essential interfaces and virtual adapters.
- Apply profile and confirm mode (Rule or Global).
- Capture
scutil --dnsoutput as baseline evidence. - Verify interface DNS with
networksetup -getdnsservers. - Run two leak sites and compare against command output.
- Re-enable interfaces one by one to isolate divergence.
Wi-Fi, Ethernet, VPN adapters, and endpoint filters may all register resolver data. Without isolation, results can alternate and look random.
Browser DoH Impact
Browser DNS over HTTPS can route lookups directly to browser-selected providers. That can hide whether ClashX + system DNS routing is truly correct.
DoH improves browser privacy but changes test semantics. For baseline validation, normalize DoH state first, then re-enable intentionally.
Chrome
- Open
chrome://settings/security. - Find Use secure DNS.
- Set to With your current service provider or disable for baseline.
- Clear cache and rerun leak tests.
Firefox
- Open
about:preferences#privacy. - Locate DNS over HTTPS.
- Set to Off for baseline, then retest with policy mode.
- Use
about:networking#dnsto inspect and clear DNS cache.
Edge
- Open
edge://settings/privacy. - Find secure DNS settings under security.
- Match the mode to your testing matrix.
- Run tests in a fresh session.
If terminal output looks expected but browser leak tests show different resolvers, browser DoH is probably overriding baseline DNS routing.
Validation Worksheet
Consistent records turn DNS troubleshooting into an operational process. Use this worksheet after profile updates, app updates, and network switches.
Verification template
Validation Session ID: ______________________
Date / Time: ________________________________
Network: Home / Office / Mobile Hotspot
Proxy Mode: Rule / Global / Direct
Profile Version: ____________________________
Expected DNS Resolver Region: _______________
Expected Exit IP Region: ____________________
Browser DoH State: On / Off / Provider: _____
Test #1 (dnsleaktest.com)
- Resolver ASN: _____________________________
- Resolver Country: _________________________
Test #2 (ipleak.net)
- DNS Entries: ______________________________
- IP Region: ________________________________
Test #3 (browserleaks.com)
- DNS Result: _______________________________
- WebRTC Exposure: Yes / No
Terminal Evidence
- scutil --dns snapshot saved: Yes / No
- networksetup output saved: Yes / No
Decision
- Leak confirmed: Yes / No
- Root cause hypothesis: _____________________
- Next action: _______________________________- Keep one interface active and use one browser profile.
- Capture terminal DNS state before visiting test sites.
- Run all three leak tools and log each resolver result.
- Toggle browser DoH and repeat to quantify impact.
- Change one ClashX variable at a time and retest.
Common False Positives
Not every mismatch is a leak. Control variables and correlate evidence across layers before changing production policy.
Cached records can survive profile switches. Clear browser DNS cache and retest with unique subdomains.
Some providers return region-adjacent resolvers by design. Validate ASN ownership before calling it a leak.
Security software may inject local DNS proxy behavior. Inspect listeners and resolver chain before concluding.
IPv6 DNS paths can diverge from IPv4 policy. Compare both families independently.
Confirm three signals together: resolver ASN, terminal output, and browser DoH state. If only one fails, classify as suspicious and rerun under controlled conditions.
FAQ
1. Can exit IP look correct while DNS still leaks?
Yes. Exit IP and DNS path are separate control planes. You can have a correct egress IP and still expose local resolver metadata.
2. Should browser DoH stay disabled permanently?
No. Disable only during baseline diagnostics, then re-enable according to your security policy.
3. Is fake-ip always superior to redir-host?
Not always. fake-ip is usually faster; redir-host can improve compatibility for sensitive applications.
4. Why do leak websites show different resolver results?
They use different infrastructure and datasets. Compare multiple sources and correlate with terminal evidence.
5. How often should this checklist be repeated?
After profile updates, app updates, browser DNS policy changes, and major network transitions.
6. Fastest path to root cause isolation?
Freeze variables: one interface, one browser profile, one ClashX profile. Capture command evidence first, then run leak dashboards.
Summary
DNS leak prevention is a repeatable workflow: build a stable ClashX DNS baseline, verify system resolver order, control browser DoH behavior, and keep written validation records.
With layered checks, leak diagnosis stays objective and fast even across profile upgrades and changing network environments.