DNS Troubleshooting Guide

Start with the failing layer, not a switch. A page that will not load can reflect a lookup failure, a transport problem, a TLS error or an application response. First establish which one occurred and whether that request actually entered Clash Verge Rev. A working browser does not prove that another application uses the same resolver or route.

This desktop workflow covers Windows, macOS and Linux. It is an editorial diagnostic method informed by the linked documentation, not a claim that every environment has been tested. Interface labels vary by version. Ask your administrator about managed DNS, VPN or security policies rather than overriding them.

1. Capture a baseline before changing anything

Choose one permitted destination that reliably reproduces the problem. Record the client and core versions, operating system, active profile name, System Proxy and TUN states, affected application, timestamp and exact error. Refreshing a subscription, switching nodes and changing DNS together destroys the comparison, even if connectivity returns.

For the same destination, record browser behavior, application behavior and whether a corresponding connection appears in the client. An approved second network can provide another comparison, but hold other variables constant. Do not send private internal hostnames to public resolvers or public diagnostic sites.

2. Separate four kinds of failure

  • Lookup timeout or unknown host: identify the resolver, its reachability and any hosts or cache involvement. One timeout is not proof of poisoned DNS.
  • An address is returned but connection times out: examine the destination, route, node and firewall. Resolution alone does not establish connectivity.
  • Certificate or TLS failure: check the clock, hostname, trust chain and possible intermediaries. Do not conceal the cause by disabling certificate checks.
  • HTTP 403, 404 or 429: the request reached an HTTP responder, which might be the destination, a proxy or an intermediary. Identify the responder before drawing conclusions.

These are working categories, not universal interpretations of every error string. If only one service fails, retain destination-specific evidence before resetting the entire computer network.

3. Check which component resolves and routes the request

Use connection records and logs to establish whether the core sees the traffic. Applications need not honor the system proxy. Likewise, verify TUN routing and DNS interception separately: an enabled switch does not prove that all queries follow the intended path.

nslookup example.com observes the query made by that tool, not every browser cache or application resolver. Firefox DoH settings are a separate variable. Consult the linked Mihomo resolution-flow and TUN documentation when checking the core path and interception limits.

4. A Fake-IP answer is not automatically a bad answer

Fake-IP can return a mapped address rather than a destination's public address. Compare an answer such as 198.18.x.x with the active fake-ip-range; do not label it poisoning or save it in the system hosts file simply because it looks unusual.

Ask whether the subsequent connection still reaches the core responsible for that mapping. An application taking another route, stale state or a reused connection after a profile change can explain a lookup that appears successful but does not connect. Treat these as hypotheses to test in logs, not conclusions drawn from an address alone.

If the issue is limited to one application, preserve the working profile before investigating compatibility. Add only a narrowly justified domain exception when evidence supports it. Replacing the entire DNS block or excluding every domain makes later diagnosis harder.

5. Compare DoH and IPv6 deliberately

A browser using its own DoH settings may produce different results from a command-line tool. Intercepting ordinary port-53 DNS is not the same as decrypting DNS inside HTTPS. Record the browser setting and management policy first. If an authorized temporary comparison is useful, restore the original setting afterward; permanently disabling encrypted DNS is not the default remedy.

For IPv6, distinguish an AAAA answer from a usable IPv6 route. Mihomo's dns.ipv6 governs AAAA responses, not the operating system's global IPv6 state. Investigate routing, node support and application address selection when you actually observe a difference between IPv4 and IPv6 paths.

6. Use one explicit-proxy comparison

This example requires an existing local SOCKS or mixed listener. Replace PORT with its actual displayed port and use a permitted, token-free destination. Do not expose a LAN listener merely to copy the example.

curl --proxy socks5h://127.0.0.1:PORT --noproxy "" --connect-timeout 10 --max-time 20 -I https://example.com

On Windows PowerShell, use curl.exe to invoke the executable. socks5h delegates destination-name resolution to the SOCKS proxy. This is a comparison of that explicit path, not a complete simulation of the application. A server rejecting HEAD does not by itself indicate a network failure.

If this succeeds while the application fails, investigate application routing and cached state. If both fail, use core logs to separate destination lookup, node connectivity and rule selection. If both sometimes work, record timing around sleep, network changes and connection reuse.

7. Make every change reversible

  1. Back up the profile and state one hypothesis.
  2. Change only the relevant setting, apply it through the supported client workflow and check for errors.
  3. Restart the test application. Follow the relevant documentation for its cache rather than deleting the entire profile directory.
  4. Repeat the original request, a known-good control and the affected application's workflow.
  5. Revert if nothing improves. If it does, retest after a client restart or network reconnect.

If a resolver endpoint or proxy-node hostname cannot be resolved, inspect that bootstrap dependency. Do not make the test pass by disabling the firewall, bypassing TLS validation or publishing the controller interface.

8. An example and an escalation checklist

Hypothetical example: a browser works, a desktop application times out and no matching application connection appears in the client. Check whether the application honors System Proxy and whether TUN covers its traffic. A successful explicit-proxy test strengthens the routing hypothesis, but does not prove that the application has no other defect.

A useful report includes versions, OS, mode, a redacted error, the reproduction time and one before/after comparison. Remove subscription URLs, query-string tokens, node credentials and controller secrets. Completion means the original workflow and control both work, including after reconnecting—not merely that one latency number appears.

Related guides

References

References checked: 2026-10-14. Links below are project and platform documentation. This is an independently edited guide.

DNS,Fake-IP,Troubleshooting,Diagnostics