Clash Troubleshooting

The client handles interface tasks such as managing subscriptions, choosing proxy groups, and toggling the system proxy. The core reads the configuration, handles connections, matches rules, and applies DNS policies. mihomo is one of the cores in the Clash ecosystem; not every client with Clash in its name uses the same core. When troubleshooting configuration compatibility, note both the client name and core version. Don’t assume a field is supported based on the interface name alone.

Get a subscription link from a trusted provider, or prepare a local YAML configuration with working proxy nodes. The client manages traffic; installing it doesn’t provide a working proxy connection by itself. After importing a configuration, make sure it’s selected and its proxy groups include nodes. Then enable the system proxy or turn on TUN if needed. Subscription URLs often contain account credentials, so don’t post them publicly or submit them to untrusted online converters.

Avoid relying on free nodes from unknown sources for account sign-ins or sensitive activity. With public nodes, it’s often hard to verify maintenance, data limits, operators, or logging policies, and a working connection today doesn’t guarantee future reliability. A free client and a paid proxy service are two different things. If a public node stops working, check its source and service status first. Don’t disable certificate verification in your browser just to restore a connection.

Use Rule for everyday traffic, so connections handled by the core follow your rules. To isolate a rule-related issue, temporarily switch to Global and select a node you know works. Direct sends connections handled by the core straight to their destinations. These modes only affect traffic routed through the core; they don’t automatically take over every app. If Global works but Rule doesn’t, check rule order, the matched proxy group, and its current selection. Switch back to Rule when testing is done.

Not by default. Start with the system proxy for browsers and other apps that follow system proxy settings. Consider TUN for games, some command-line tools, or apps that ignore those settings. Enabling both doesn’t necessarily cause a conflict, but it makes troubleshooting more complex. When setting things up, enable one traffic-capture method at a time. Once connection logs show the target app’s traffic, combine methods only if needed.

Make sure you copied the subscription URL, not the provider’s login or account page URL. Check the import message to distinguish a download failure from a parsing error. If the link returns a web page, an authentication prompt, or an incompatible node list, the client may not be able to create a configuration. Use the Clash or mihomo subscription option explicitly provided by your service. If the import succeeds but no nodes appear, check whether you need to select the configuration manually and whether your plan still includes active nodes.

Check your provider’s account page to see whether the subscription expired, your data allowance ran out, or the link was reset. For a 401 or 403 error, check authorization and access restrictions first. For a 404, make sure the URL is complete. For a timeout, check the network path used to fetch the subscription. Some clients can update subscriptions through the current proxy, provided an existing node still works. Don’t keep refreshing rapidly. Save the error details, make any necessary changes, then try one manual update.

On Windows, you may need to install and enable service mode or grant administrator permission as prompted by the client. On macOS, you may need to approve a helper service or network extension. On Linux, the client typically needs the appropriate network permissions. Check the client’s service installation option and core startup logs instead of repeatedly toggling the switch. On Android, approve the local VPN permission as well. In most user environments, two apps can’t use the VPN interface at the same time.

Port 7890 is commonly used as the mixed-port, providing HTTP and SOCKS proxy access to apps. Port 9090 is often used as the external-controller port, allowing a client or dashboard to control the core. These are common examples, not fixed values for every configuration. When setting a proxy in a browser or command-line tool, use the active proxy port from your configuration—not the controller port. If the service is for local use only, bind it to a loopback address so other devices can’t access the management interface.

Start with the core log: note the field name, line number, and error type. Then check the indentation, colons, list nesting, and proxy group references at that location. YAML indentation must use spaces, not tabs. Every node or group referenced by a proxy group must exist. Core versions can support different fields, so don’t assume an indentation fix will resolve a compatibility issue. Restore the last working configuration, then reapply changes one at a time. After each save, confirm the core starts; avoid changing several sections at once.

Follow your provider’s recommended schedule. If they don’t specify one, start with updates every few hours to once a day, then adjust based on how often nodes change. Note that a client’s full subscription update and the proxy-providers interval have different scopes, and the interface may use different time units. After setting a schedule, check that the last updated time changes; an enabled switch alone doesn’t confirm it’s working. Background restrictions can delay scheduled updates on mobile devices, so refresh manually before an important connection if needed.

Keep Rule mode enabled. Find the target domain or address in the connection list, then check the matched rule, proxy group, and final node. Rules are generally evaluated from top to bottom, so a broad rule near the top can override a more specific one below it. MATCH is usually placed last. If you see an IP address but no domain, check DNS handling and domain detection as well. After changing rules, close existing connections and retry: established long-lived connections may not switch routes immediately.

Use the client’s supported override, configuration merge, or extension script features, and back up your settings first. Changes made directly to a downloaded subscription file may be overwritten during the next update. Whether an override appends to a list, replaces a field, or supports scripts depends on the client—don’t assume instructions for another app will apply. After saving, check the effective configuration to confirm the rule order and proxy group names, then update the subscription manually to verify your changes remain.

First check whether the app reads system proxy settings. Command-line programs may need their own proxy options or environment variables. For example, for a tool that supports HTTP proxies, set http://127.0.0.1:7890; use the port from your active configuration. HTTP and SOCKS proxy syntax isn’t interchangeable, and some tools distinguish between resolving domains locally and resolving them through the proxy. If the app has no proxy settings, consider TUN. Check the connection logs to verify traffic—browser access alone doesn’t mean every app is using the proxy.

First, check the client’s connection list for a test request. Then inspect its matched proxy group and final node. You can also use a trusted IP lookup site to check the exit address, comparing results with the proxy enabled and disabled if needed. An unchanged exit address doesn’t always mean something is wrong—the destination may be routed directly. A changed address doesn’t prove every app is using the proxy. Test each app that needs proxy access, and note the test time and target domain so you can match the results to the logs.

Not necessarily. First make sure your device can connect to the internet directly. Then check that the subscription is valid, the system clock is accurate, and node domains resolve correctly. Latency tests usually connect to a specific test URL; if that URL is unavailable, all nodes may appear to time out. Try another trusted test URL supported by the client. If some nodes work, compare their protocols and service status. If none do, review the connection error logs rather than assuming the installation is at fault.

Make sure the core is running, the proxy port is listening, and the system proxy address and port are correct. Then check whether a browser extension, custom proxy setting, enterprise policy, or another proxy app is overriding the system settings. Destinations in the system proxy bypass list won’t appear in the core either. Temporarily disable other traffic-capture tools and restart the browser to test. If the connection list is still empty, troubleshoot the path from the app to the local proxy first—not the remote node.

Some UWP apps are subject to AppContainer loopback restrictions and can’t directly access a proxy on the local loopback address. First confirm that a regular browser works on the same port. Then use the client’s loopback exemption tool to authorize only the apps that need it, following the prompts to grant administrator permissions. Not every app installed from the Microsoft Store has the same restrictions, and enterprise policies may prevent changes. If no loopback tool is available, consider TUN and check the connection logs to confirm the traffic path.

Turn TUN off and compare the results to confirm that traffic capture is causing the issue, then check routes, DNS, and connection logs. If LAN devices are unreachable, review direct rules for private IP ranges and route exclusions. For domain issues, check Fake-IP mappings, resolver connectivity, and the app’s own encrypted DNS settings. Use targeted fake-ip-filter entries for incompatible domains instead of filtering every domain. Change one setting at a time, reconnect, and compare the results.

Check whether the system proxy still points to a local port that’s no longer active, and clear any leftover proxy settings. Then make sure the TUN interface, routes, and DNS have been restored. You can reopen the client, turn off the system proxy and TUN, exit normally, and reconnect to your current network. If the issue persists, check other VPNs, browser extensions, and manual DNS settings. A network reset can affect existing configurations, so record custom settings first. Don’t start by removing all network adapters.