Clash Connected but No Internet: System Proxy, DNS, and Rule Mode Troubleshooting Checklist

First, clarify what “Connected” actually means

When the Clash client shows “Running,” “Connected,” or a VPN badge, it usually means only that the core is running, the configuration has loaded, or the system has granted VPN interface access. It does not necessarily mean browser traffic is passing through Clash, nor that the node selected by the current proxy group can reach the target address. Start troubleshooting by checking the application state, traffic entry point, rule decision, and node exit separately.

A web request generally follows this path: the application opens a connection, the operating system sends traffic to Clash through proxy settings or routing, Clash resolves the target domain, the rule engine chooses a proxy group, DIRECT, or REJECT, the proxy group selects a node, and the node establishes the remote connection. A failure at any point can appear as endless loading, DNS resolution errors, connection resets, or internet access failing only in certain applications.

Checking the client’s connection log is more effective than repeatedly toggling settings. If opening a webpage adds no new connection entries at all, the issue is usually with the system proxy, TUN routing, or the application’s own proxy settings. If entries appear but show DNS errors, focus on DNS configuration. If a request clearly matches a proxy group and then times out, check the node and upstream network.

Turn off the proxy to verify the basic network

At the start of troubleshooting, temporarily disable the system proxy and TUN mode while keeping the configuration file. Do not rush to delete the subscription or reinstall the client. Then test the local gateway, a regular website, and DNS. This separates a network outage from an outage caused by traffic passing through Clash. If no websites open even with Clash disabled, fix the Wi-Fi, mobile network, router authentication, captive-portal login, or ISP connection first instead of changing proxy rules.

Check the address, gateway, and network authentication

• Make sure the device has a normal IPv4 or IPv6 address rather than an unusual automatically assigned local address.
• On hotel, airport, and campus networks, complete the web-based sign-in before enabling the system proxy or TUN.
• Switch from Wi-Fi to a mobile hotspot. If the hotspot works but the original network does not, focus on that network’s DNS, UDP restrictions, and firewall policies.
• Check the system date and time zone. A large clock offset can make TLS certificate validation fail, causing several HTTPS websites to become inaccessible at once.

Use layered tests to separate DNS and connection failures

Test IP connectivity first, then test domain resolution. On Windows, use ping 1.1.1.1 and nslookup example.com in a terminal; on macOS and Linux, use ping -c 4 1.1.1.1, dig example.com, or nslookup example.com. Some networks restrict ICMP, so a failed ping alone does not prove that the network is down. Also check browser access and DNS query results.

Verify the system proxy, ports, and TUN traffic entry

Clash commonly takes over traffic through the system proxy or TUN. The system proxy mainly affects applications that follow the operating system’s HTTP, HTTPS, or SOCKS settings. TUN uses a virtual network interface and routing to handle a broader range of TCP and UDP traffic. A client can manage both, but during troubleshooting you should identify which one is active instead of mistakenly blaming the node for a system-proxy problem.

The system proxy is enabled, but the browser shows no connection entries

First, confirm that the system proxy points to the local loopback address and that its port matches the listening port in the current configuration. A common setup enables mixed-port for both HTTP and SOCKS connections; older configurations may use port and socks-port separately. If a configuration update changed the port while the operating system kept the old one, the browser will immediately report that the proxy server refused the connection.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

Also check whether the browser or application has its own proxy setting. An independent proxy may take priority over the system setting and still point to another client that has already exited. Command-line tools do not always read the desktop system proxy automatically. If only terminal programs fail, check their HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY environment variables instead of assuming Clash has failed altogether.

TUN is enabled, but every request times out

TUN mode depends on a virtual interface, the routing table, and system permissions. The first time it is enabled, Windows may require administrator privileges to install or start network components; macOS, iOS, and Android will request VPN access. If permission was revoked, the virtual interface failed to initialize, or the default route was not added, the interface may still show the core as running even though application traffic is not entering the processing chain correctly.

Disable other VPNs, network accelerators, and similar proxies, then test again. Multiple programs modifying the default route or DNS can easily create routing-priority conflicts. If the browser works after disabling TUN and leaving only the system proxy enabled, the node and basic proxy port are probably fine. Narrow the investigation to TUN permissions, the interface stack, routing, and DNS hijacking settings.

Identify DNS resolution, Fake-IP, and caching issues

Typical DNS failures include a domain not opening while its IP responds directly, repeated resolution timeouts in the connection log, some domains working while others fail, or old results continuing to be used after switching networks. Clash Meta, also known as mihomo, can use its built-in DNS module for standard resolution, Fake-IP mapping, split-DNS queries, and fallback decisions. Valid configuration fields do not guarantee that an upstream DNS server is reachable on the current network.

First, check whether the query reaches Clash

Enable DNS logging or review the client log and confirm that a query appears when you visit a test domain. If the system is still querying an old DNS server, TUN DNS hijacking may not be active, or the browser may have enabled its own secure DNS. Temporarily disable the browser’s independent DNS to keep the query path simple. Restore it later if needed, after confirming that Clash DNS works.

Check upstream protocols and network capabilities

Traditional UDP DNS, TCP DNS, DoH, and DoT have different network requirements. An upstream address that works on a mobile network may fail on a corporate or campus network. In particular, if the proxy node is not connected yet and the domain name of the proxy server depends on a DNS server that can be reached only through the proxy, startup can become a dependency loop. The DNS used to resolve the proxy server’s domain must be reachable directly through the current local network.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - 223.5.5.5

The snippets above show field relationships only and should not directly replace an existing subscription. When the configuration is managed by a subscription provider or the client’s override layer, make the change in the corresponding override instead; otherwise the next subscription update will overwrite the local edit. If IPv6 is enabled but the local IPv6 route is unstable, applications may prefer unreachable addresses. You can temporarily disable IPv6 responses in Clash DNS for comparison, but the long-term setting should reflect actual network capability rather than trial and error.

Special behavior in Fake-IP mode

Fake-IP first returns a reserved address to the application, then the core uses the domain mapping to process subsequent connections. An address in the 198.18.0.0/16 range is therefore usually part of the intended mechanism, not evidence that the domain resolved to an incorrect public address. The key checks are whether Clash captured the application connection and whether the mapping record still exists. If the DNS query passes through Clash but the subsequent connection bypasses it, the application cannot directly access the Fake-IP it received.

LAN device discovery, printers, router admin domains, and some services that require real addresses may need to be added to the Fake-IP filter. Filter specific, known domains rather than excluding broad domain ranges, or rule matching and DNS split-routing results will become difficult to predict. After making changes, clear the system DNS cache and fully quit and relaunch the affected application so an old connection pool does not keep using historical results.

Check rule mode, proxy groups, and node exits

Once connection entries appear, check which rule each request matched, which proxy group received it, and which node the group ultimately selected. Clash evaluates rules in declaration order and usually stops at the first applicable rule. A broad rule near the top can hide a more specific rule below it, while the final MATCH catches requests that matched nothing earlier.

Use mode switching for comparison, not as a permanent fix

Temporarily switch from rule mode to Global mode and select a known-working node. If the site loads, the system proxy, basic DNS path, and node exit may be working; the problem is more likely in the rule set, proxy-group selection, or DIRECT routing. If Global mode still fails, continue checking the node, protocol compatibility, and firewall. After the comparison, switch back to rule mode and fix the specific rule instead of hiding the problem with Global mode.

DIRECT mode can also show whether a local website was incorrectly sent through the proxy. If DIRECT works but rule mode fails, check whether the domain matched a proxy group and whether the selected node is suitable for that target. Conversely, if proxy mode works but DIRECT times out, the target is not reachable through the current local network and the rule should send it to an appropriate proxy policy.

A proxy-group name does not prove that a usable node is selected

A select proxy group requires manual member selection; url-test selects automatically based on a test URL and interval; fallback generally switches in order of availability. Automated test results reflect only the test address at a particular moment and cannot fully represent every website, protocol, or long-lived connection. If latency looks normal but webpages fail, inspect the actual request log instead of relying only on the group’s latency test.

• Make sure the proxy group has not selected REJECT, an unavailable node, or an expired child proxy group.
• Manually switch between two nodes in different regions and on different routes, then test the same website again.
• If TCP webpages work but games, voice calls, or QUIC fail, check whether the node supports UDP and whether TUN is handling UDP traffic.
• If only certain websites fail, check domain rules, IP rules, rule-set update status, and where the final MATCH sends the request.
• If the problem started after a subscription update, confirm that proxy-group names still match their rule references and that no rule points to a group that no longer exists.

Check the firewall, port conflicts, and other network software

If the configuration works on another device but always fails on the current one, check the operating system’s security boundary. A firewall may allow the client interface to run while blocking the core process from making outbound connections; security policies may also prevent a local program from listening on the proxy port. After a client upgrade, the core’s file path may change, and existing allow rules may not automatically match the new path. Recheck network permissions.

Confirm that the listening port belongs to the current Clash core

On Windows, use netstat -ano | findstr 7890 to view the port and process ID; on macOS and Linux, use lsof -i :7890. If another program is using the port, the Clash log will usually report a listening failure. Close the conflicting program or change the port consistently in both the configuration and system proxy settings; changing only one is not enough.

Avoid stacking multiple network-control tools

Corporate VPNs, virtual-machine networks, container networks, game accelerators, and traffic-filtering tools can all modify routes, install virtual network adapters, or change DNS. Exit them one at a time and check the default route and connection log after each change. If a reboot restores connectivity briefly and it fails again when a particular network program starts, that pattern usually identifies the source of the conflict.

LAN sharing requires additional checks

When other devices connect to Clash on this computer over the LAN, the local configuration must allow LAN access, and the proxy port must be allowed through the system firewall. Client devices should use the LAN address of the device running Clash, not 127.0.0.1, because a loopback address always points to the client device itself. For access control, expose the listener only on trusted networks and restrict usage with the authentication fields supported by the client.

Restore the configuration and verify it in a fixed order

After completing each individual test, consolidate temporary changes into a stable configuration. Do not leave multiple temporary DNS servers, duplicate rules, or Global mode enabled indefinitely. The following order works for most desktop and mobile clients and makes it easier to pass the findings to whoever maintains the configuration.

1. Confirm the basic network: Disable the system proxy and TUN, then verify that the current network can complete authentication and access regular websites.
2. Start the core: Load the configuration and inspect the startup log to confirm successful YAML parsing, port binding, and rule-set loading.
3. Enable only the system proxy: Visit a test website in a browser and confirm that an entry appears in the connection list.
4. Verify DNS: Check domain query results and logs, clear the cache, and test the same domain again.
5. Verify the node: Briefly select a known-working node in Global mode, then return to rule mode and compare the results.
6. Verify the rules: Check the actual match, proxy group, and final node, then correct any incorrect DIRECT, REJECT, or group-name reference.
7. Enable TUN separately: Confirm VPN permission, the virtual interface, and routing, then test an application that does not follow the system proxy.
8. Restore the security boundary: Re-enable the necessary firewall and network software, checking each item for newly introduced conflicts.

Common symptoms and what to check first

Connection list is empty

First check the system proxy address, port, application-specific proxy, TUN permissions, and route takeover.

Domains fail, but IP addresses are reachable

First check Clash DNS, system DNS, the browser’s independent DNS, upstream reachability, and caches.

Global mode works, but rule mode fails

Check rule order, rule-set status, MATCH routing, proxy-group references, and the DIRECT path.

The browser works, but other applications fail

Check whether the application bypasses the system proxy; if necessary, verify TUN interception and UDP support.

All nodes time out at once

Check the local network, DNS, system time, firewall, and egress restrictions before judging the subscription nodes.

It stopped working after a subscription update

Check configuration parsing logs, proxy-group names, rule references, override content, and client field compatibility.

If the problem persists, export a minimal diagnostic record: operating system and client version, core type, traffic interception method, time of failure, test network, rule mode, matched policy, and sanitized error logs. Do not publish the full configuration file or subscription link. Clear path information is more useful for diagnosis than saying “I already reinstalled it,” and it avoids repeatedly changing settings unrelated to the failure.