A Clash interface showing “Connected,” latency beside a node, or continuously scrolling logs does not mean browser traffic is successfully passing through the proxy. The client may have only loaded the configuration, tested latency, or started the core. Actual web access still depends on the application, system proxy or TUN, Clash inbound port, rule matching, policy group, proxy node, DNS, and destination site—all as part of one chain. A break at any layer can look like “connected but websites won’t open.”

First identify which layer is failing

The first step is not to switch through more nodes, but to determine the scope of the failure. In addition to a familiar website, test a local network address, a regular domain, and a direct IP connection. If only one site fails, the cause may be a site restriction, a matching rule, or the node’s exit. If all domains fail while IP addresses work, check DNS first. If the browser works but the terminal, games, or app store do not, those applications likely ignore the system proxy and need an app-specific proxy or TUN.

  1. Check the local network: Fully exit Clash or disable the system proxy, then confirm that websites work through a direct connection. Adjusting the proxy is pointless if the underlying network is already down.
  2. Compare different applications: Test a browser, the command line, and an application that does not read the system proxy. Differences in the results can show whether the problem is at the application proxy layer or the system-wide forwarding layer.
  3. Watch the connection logs: While opening a website, check whether the logs show the corresponding domain, matched rule, and final policy. If there are no new entries at all, the traffic probably never reached Clash.
  4. Distinguish timeouts from resolution errors: “Server address not found” points more toward a DNS failure; “connection refused” commonly indicates a local port problem; a long timeout calls for further checks of the policy, node, and routing.

Logs are the most direct evidence in the troubleshooting process. A normal request typically shows the destination domain or IP, rule type, policy group, and actual node. If the log shows DIRECT, the request was sent directly according to the rules. If it shows a proxy node followed by a timeout, the traffic has already entered the core; focus on node availability, policy groups, and the remote network rather than the system proxy switch.

Verify the subscription, configuration, and policy selection

A successful subscription update only means that the client downloaded the content; it does not mean the updated configuration is the one currently active. Some clients keep multiple local configurations, with updating and switching handled separately. Open the configuration page and verify the active configuration name, update time, and enabled status. If the client asks you to reload after updating, reload it before testing.

Check whether the core can load the configuration completely

The configuration file defines ports, DNS, rules, policy groups, and nodes. YAML indentation errors, policy groups referencing missing nodes, or failed rule-provider downloads can cause loading failures or partial malfunctions. Check the core startup log first instead of relying only on the subscription page’s “Update complete” message. If a parse error appears, return to the last configuration that started successfully, then restore custom content section by section.

When using remote rule sets, also confirm that the rule files have been downloaded. During the first configuration load, after a network change, or when a rule-provider URL is temporarily unreachable, a policy group may exist while its required rule data is not yet ready. Reload the configuration and watch the rule download entries. Avoid adding many overrides to a configuration from an unknown source, or subscription problems and local changes may become difficult to separate.

Check the proxy mode and policy group

Common modes include rule, global, and direct mode. Rule mode matches requests from top to bottom against the configured rules; global mode generally sends requests to the selected global policy; direct mode bypasses the proxy. If the client is left in direct mode, websites will not use the node even if the latency test returns a result.

  • Rule mode: Suitable for everyday use. Check which rule the request ultimately matches and which policy group that rule points to.
  • Global mode: Useful for briefly checking whether the rules are wrong. If global mode works but rule mode does not, focus on rule order, policy-group references, and fallback rules.
  • Direct mode: Use it to temporarily bypass the proxy. Remember to switch back to the required mode after troubleshooting.

A policy group having the expected name does not mean its selected member is correct. A manually selected group may still point to a node that has stopped working, while an automatic latency group may have chosen a result unsuitable for the current network. Open the policy group, explicitly select a recently working node, and make a real web request. A latency test only shows that the test address responded at that moment; it does not replace an actual TCP, TLS, and destination-site test.

Check the system proxy, listening address, and port conflicts

Without TUN, browsers and most desktop applications rely on the system proxy to send requests to Clash. The “system proxy” switch in the client must match the HTTP, SOCKS, or mixed port actually listened to by the core. If the core failed to restart, a port is occupied, or the system still points to an old port, the proxy may appear enabled while every request is rejected locally.

First check whether requests reach the core

Keep the log window open and refresh the page. If no new requests appear, check in order whether the system proxy is enabled, the proxy server is set to the local machine, and the port matches the active configuration. A common local address is 127.0.0.1. Use the port currently shown by the client or defined by mixed-port, port, or socks-port in the configuration file; do not copy a port from another device.

You can explicitly specify an HTTP proxy from the command line for testing. The port below is only an example; replace it with the port actually used by the client before running the command:

curl.exe -I -x http://127.0.0.1:7890 https://example.com/

If an explicitly proxied request succeeds while the browser still fails, the core, node, and basic outbound path are probably working. The issue is more likely that the system proxy has not taken effect, the browser has its own proxy setting, an extension changed the network configuration, or the application does not read the system proxy. If the command immediately says it cannot connect to 127.0.0.1, check whether the core is running and whether the port is listening. If the request appears in the logs but times out remotely, return to the policy and node layers.

Rule out occupied ports and duplicate processes

Running two proxy clients on the same device, or leaving an old Clash process running, can cause them to compete for the same port. The new client window may open even though its core failed to listen. Look for address already in use, bind, or listening failures in the startup log. Close duplicate processes and start the core again. Changing the port can also avoid the conflict, but the system proxy must be updated to the new port as well.

The LAN-sharing option is not the same as local use. For local access only, listening on 127.0.0.1 is usually sufficient. Consider allowing LAN access only when other devices need to connect, and configure the system firewall accordingly. Do not expose a LAN listener just to fix a browser problem on the same device.

Clear leftover system proxy settings

After an abnormal client exit, the operating system may retain a proxy setting that points to an old port, leaving the browser unable to connect even after Clash is closed. Restart the client and first disable the “system proxy.” Confirm that the manual proxy is cleared on the operating system’s proxy settings page, then enable it again if needed. Corporate networks, automatic configuration scripts, and browser policies can also override manual settings, so verify the final effective values in the system network settings.

DNS failure: domains do not open, but the network may still be working

DNS converts domain names into addresses. Clash or mihomo can take over DNS and use rules, Fake IP, or real-address results to determine how connections proceed. When DNS is misconfigured, a node may show latency and the proxy port may work normally, yet the browser may repeatedly report a domain-resolution failure. Check DNS separately after confirming that requests have reached the core.

Recognize resolution problems from the symptoms

  • Domain access fails while existing connections or services that use IP addresses directly still work.
  • The logs show DNS timeouts, unreachable upstream servers, resolution loops, or rejected queries.
  • The problem starts immediately after changing networks, especially when moving between a company network, campus network, public Wi-Fi, and home network.
  • Access returns after disabling TUN or Clash DNS, indicating a problem in the DNS interception path.

System commands can help determine whether the operating system can currently resolve domain names:

nslookup example.com

The result of nslookup alone cannot prove that Clash DNS is working perfectly. Some applications may use the browser’s built-in secure DNS, while TUN may intercept ordinary DNS requests. Check the client’s DNS logs and the browser settings together. If the browser has independent encrypted DNS enabled, it may bypass the system resolution path or conflict with the expected rules. During troubleshooting, temporarily switch back to system DNS to establish the boundary, then choose the final setup.

Understand Fake IP and redir-host

In supported Clash Meta (mihomo) configurations, fake-ip mode returns a reserved address for a domain and restores the domain when the connection is made, improving consistency for rule matching and transparent proxying. Seeing a reserved address is not necessarily an error. The real issue is usually that DNS traffic was not intercepted correctly, the Fake IP mapping was lost, or certain LAN devices and specialized applications are incompatible.

redir-host returns the real resolved address and follows a different compatibility path, but that does not make it more reliable in every situation. Do not switch modes simply because you see a Fake IP. If only a printer, LAN device, game platform, or specific application fails, check whether its domain should be excluded in fake-ip-filter, and confirm that LAN domains are resolved by an appropriate name server.

Check DNS upstreams and circular dependencies

DNS upstreams must be reachable under the current network conditions. If an upstream itself requires the proxy, while the proxy connection first needs to resolve the node’s domain, a dependency loop can occur. The default name servers in the configuration are typically used to resolve proxy-node domains and should be directly reachable during startup. This is especially important when subscription nodes use domain names.

After changing DNS, reload the configuration, clear the operating system or browser cache, and test again. Do not add several upstream addresses from unknown sources at once; more addresses cannot fix a routing error and can make the source of timeouts harder to identify. For a fuller explanation of the fields and their relationships, see the user guide.

TUN is enabled, but access still fails

TUN uses a virtual network interface to intercept more traffic, making it suitable for applications that ignore the system proxy. It involves the virtual adapter, routing table, DNS interception, system permissions, and firewall, creating several more failure points than a standard system proxy. Turning on the switch does not prove that the virtual interface was created successfully; rely on the core log and the system’s network-interface status.

Confirm permissions and driver status

Creating and configuring a virtual interface on Windows generally requires sufficient system privileges. macOS may require approval for a network extension or administrator credentials, while Linux needs a TUN device and the relevant network-management permissions. If the log reports failure to create the interface, set routes, or obtain permission, resolve the permission issue before switching nodes again.

After sleep, an upgrade, or a network-adapter change, an old virtual interface or route may not have been released correctly. Disable TUN and wait for routing to recover, then enable it again. If it still fails, fully exit the client and restart the system; this usually clears leftover state more reliably than repeatedly toggling the switch. After restarting, enable only the system proxy to verify the core and node, then enable TUN to determine whether transparent interception introduced the problem.

Check routing, exclusions, and loops

TUN must prevent Clash’s own connections from being sent back into TUN, or traffic loops can occur. Mature clients usually handle the core process and required routes automatically, but custom routes, third-party firewalls, VPNs, virtual-machine software, and other network filters can change the result. During troubleshooting, temporarily disable other VPN or proxy tools and leave only one program intercepting network traffic.

If the internet works after enabling TUN but LAN devices become unreachable, check whether private subnets are set to bypass the proxy as needed and whether auto-route and strict-route settings suit the current system. Conversely, if the LAN works but all internet requests time out, check that the default route was written correctly and that the outbound interface changes properly between Wi-Fi and Ethernet. Do not proxy every private address; doing so can interfere with router administration pages, file sharing, and local DNS.

Avoid confusing system proxy and TUN by stacking them

Some clients support enabling the system proxy and TUN at the same time, and this can work with a correct configuration. During troubleshooting, however, it makes the request path harder to identify. First disable TUN and test the browser with only the system proxy. Once that works, disable the system proxy or keep it as recommended by the client, then test TUN separately with the terminal and other applications. Watch the logs at every step instead of drawing conclusions from a page opening once by chance.

Check application- and OS-specific differences

When only some programs fail on the same device, do not keep changing the global subscription. A browser may use its own proxy or secure DNS; command-line tools may read the HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY environment variables; games and app stores may bypass the system proxy entirely. Identify the network path used by the application first, then choose an in-app proxy, system proxy, or TUN.

Windows

Check whether the manual proxy in “Settings” matches the client, and look for an old automatic configuration script. Network isolation or loopback restrictions in some applications can make a desktop browser work while an app store fails. A firewall may also block the core from listening or making outbound connections. If the client executable path has changed, recheck its firewall permission and use the client logs to verify whether the affected application is generating requests.

macOS

System proxy settings are saved separately for each network service. After switching between Wi-Fi and Ethernet, the proxy may still be configured only on the previous service. Open the settings for the network service currently in use and check the web proxy and secure web proxy. TUN or enhanced modes also require the network extension to be active; if a system update reset its authorization, approve it again as prompted by the client.

Linux

A desktop environment’s system proxy does not necessarily affect terminal programs, and terminal environment variables do not necessarily affect graphical applications. Set the scope clearly and test each separately. With TUN, check /dev/net/tun, the routing table, policy routing, and DNS management services to prevent NetworkManager, systemd-resolved, and manually written resolver settings from overwriting one another.

Android and iOS

Mobile clients usually intercept traffic through the system VPN interface. If the status bar shows a VPN but requests fail, check whether the system restricts the client’s background activity, another VPN is enabled, or the current Wi-Fi requires portal authentication first. Switching between cellular data and Wi-Fi quickly shows whether the problem is limited to one access network. Per-app routing and LAN bypass settings can also change the result.

A minimal-change path to restoring access

The sequence below layers failure points from the outside in and is suitable when “it worked yesterday, but nothing opens today.” Test immediately after each step and record changes in the logs. Once access returns, review the last change instead of continuing with the remaining steps.

  1. Disable the system proxy and TUN, then confirm that the device’s basic network and direct local access work normally.
  2. Start the Clash core and confirm that the configuration loads successfully, with no YAML, rule-provider, listening-port, or permission errors.
  3. Verify the active subscription configuration, reload it after updating, and explicitly select a node that can be tested.
  4. Confirm that the client is not in direct mode; briefly use global mode to determine whether the rules are the source of the failure.
  5. Enable only the system proxy, refresh the page, and watch the logs. No logs means checking the system proxy; logs mean checking the rules, node, and DNS.
  6. Use an explicit proxy command to test the local listening port and rule out browser extensions and application settings.
  7. Check for occupied ports, duplicate core processes, and old proxy addresses left in the system.
  8. Use the resolution errors and DNS logs to check upstreams, browser secure DNS, Fake IP, and node-domain resolution.
  9. Once the system proxy is stable, enable TUN and verify permissions, the virtual interface, routing, and conflicts with other VPNs.
  10. Restore rule mode and your everyday settings, then verify separately with the browser, terminal, and target application.

If every node times out in global mode while the basic network works, test the same configuration on another network to distinguish local network restrictions from a subscription-node failure. If only one node fails, switch nodes and keep the logs. If the entire configuration cannot load, contact the configuration provider to confirm the subscription status and format. When reporting the issue, include the operating system, client version, core type, proxy mode, DNS mode, and sanitized error logs; this makes an accurate diagnosis much easier than simply saying “it won’t connect.”

Most “Clash connected but no internet” problems are not caused by a single switch. A reliable process is to verify the basic network first, then confirm the configuration and node, check whether traffic reaches the local port, and finally troubleshoot DNS and TUN. If you need to redo the installation and permission setup, follow the complete tutorial step by step instead of layering changes onto old settings.