Clash FAQs

The client provides an interface for managing subscriptions, choosing a mode, and setting the system proxy. The mihomo core reads the configuration, establishes proxy connections, applies rules, and handles DNS. A subscription is how a provider supplies configuration or proxy details. These are separate components, not the same service. Installing a client does not provide a working proxy, and switching clients will not restore a subscription that the provider has disabled. When troubleshooting, first check that the current configuration is loaded, then confirm the core is running, and finally check the subscription service status. This helps distinguish account issues from installation problems.

Rule mode checks connections against rules from top to bottom and applies the policy for the first match. Global mode sends connections handled by the core to the global proxy group, where you still need to select a working outbound. Direct mode lets connections handled by the core reach their destinations directly. These modes only control traffic that has already been routed through the core; they do not make apps that bypass the proxy use it automatically. Use Rule mode for everyday browsing. Switching to Global temporarily can help diagnose routing issues, but switch back when testing is done. Direct mode does not turn off TUN; the virtual interface may still handle routing and DNS.

For your initial setup, enable the system proxy first and test the subscription, outbound, and rules with a browser that respects system proxy settings. The system proxy only affects apps that use it; it does not route all processes. Enable TUN if you need to handle games, some command-line tools, or apps that ignore proxy settings, then check service permissions, the virtual interface, and DNS. During troubleshooting, change one setting at a time. If both methods are enabled, turn one off at a time to compare results and avoid overlapping traffic paths that make the cause harder to identify.

A latency test usually only shows that an outbound can reach its configured test address. It does not guarantee access to a specific site, protocol, or app. Check the connection log to confirm the browser’s request reaches the core, then verify the matched rule, proxy group, and actual outbound. If there is no log entry, check traffic routing first. If there is an entry but the connection fails, check DNS resolution for the destination, outbound restrictions, and service status. Also check whether you tested a single proxy or an automatic proxy group: the group may choose a different proxy than the one you tested manually.

In the client, open the Config, Subscription, or Profiles page and find the option to import from a URL. Paste the full subscription URL from your provider, save it, update it, and set that configuration as active. Don’t paste the subscription URL into external-controller or use a web dashboard URL as a subscription. After importing, check that usable proxy groups appear and review the logs for parsing errors. Subscription links often contain account credentials, so don’t post them in public chats, screenshots, or online converter sites. If a link has been exposed, reset it in your provider’s account portal.

First, check your provider’s account portal to confirm your account is active, you have available quota, and the subscription URL hasn’t been reset. Copy the link again from the portal and check for missing characters, trailing spaces, or an outdated URL. Review the update log: 401 or 403 errors usually point to authorization or access restrictions, 404 means the URL may be wrong, and timeouts call for checking the network path. If your network can’t reach the subscription domain directly, enable updates through the proxy if the client supports it, and make sure a working configuration is already available. If the response is an HTML page or login screen, don’t keep importing it; ask your provider for the correct Clash or mihomo configuration URL.

Keep a copy of the original file, then check the line reported in the log and the line above it for indentation, colons, and list structure. YAML indentation must use spaces, not tabs. Proxy names referenced by proxy groups must exist, and rule policy names must match. If supported by your core, run mihomo -t -f config.yaml from the configuration directory and use the error reported by your installed core as the source of truth. Passing syntax checks only means the configuration can be parsed; it doesn’t guarantee a working outbound. If you see an unknown field or unsupported protocol, check the core type and subscription format instead of deleting the whole section.

On desktop, first confirm that the service mode required by the client is installed and running. If needed, grant administrator access or system network extension permissions as directed by the client. On Android, approve the system VPN connection request and stop other apps using the VPN slot. On Linux, check /dev/net/tun, the service account, and required network permissions based on how the client starts. Don’t make every file writable. Find the earliest permission or interface error in the log. If the interface is created successfully but traffic still fails, check routing and DNS instead of repeatedly elevating permissions or reinstalling the client.

First, check the actual mixed-port and listening address. Then specify the proxy explicitly in tools that support proxy arguments. For example, if the port is 7890, use curl -I --proxy http://127.0.0.1:7890 https://example.com and compare the result with a request made without a proxy. If you need to set HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY in your terminal, use the syntax for your current shell and check which variables the tool reads. Environment variables usually affect only the current process and its child processes. Remove temporary settings after testing so the terminal doesn’t keep pointing to a local port after the client is stopped.

Use the update frequency recommended by your provider. In the client, find the automatic update or update interval setting for the active subscription, and check whether the value is in minutes or hours. Don’t repeatedly retry a broken link at very short intervals; this can trigger rate limits. Note the difference between updating the full configuration and the interval for proxy-providers: the client manages the former, while the core fetches provider content according to the latter. After an update, confirm that the active configuration and proxy groups are still correct. Scheduled updates may not run on time if the client is fully closed or the mobile OS restricts background activity.

First, confirm that the current mode is Rule, then make sure you edited the active configuration, not an inactive copy. Rules are matched in order, so more specific rules should generally come before broad ones, with MATCH at the end. Every policy group referenced by a rule must exist. Save the changes, reload as required by the client, and create a new connection to check which rule matches; existing long-lived connections may keep using the old route. If subscription updates overwrite local changes, use the client’s override or merge feature to preserve your rules, then check the generated configuration for duplicate rules or indentation errors.

Ask your provider whether they offer a configuration URL compatible with your core. If you can import it directly, there’s no need to convert it. A subscription containing only proxy details is not equivalent to a full configuration with rules, DNS, and proxy groups, so check that the converted file includes everything you need. A conversion service can access the original subscription URL and its credentials. Use a trusted service or a tool you host yourself; don’t submit the link to an unknown website. Conversion also can’t make an older core support newer protocols. If the logs report an incompatible protocol, switch to a compatible core or ask your provider to change the output format.

Turn off proxy routing first and confirm your local network can reach ordinary websites. Then check the system clock, account status, and subscription update results. Test one specific proxy manually and check whether the failure occurs during DNS resolution, the TCP connection, or the handshake. Every proxy timing out could also mean the test address is unreachable; don’t assume all outbounds are down based only on the test list. Compare results on another trusted network. If only your current network fails, focus on network restrictions and DNS. If multiple networks fail at the same stage, send your provider the time of the issue and logs with sensitive details removed.

In your system network settings, make sure the proxy address matches the client’s actual listening address. A common local address is 127.0.0.1, but use the port in your current configuration rather than assuming it’s always 7890. Then check browser extensions, in-app proxy settings, and bypass lists, which may override or skip system settings. If the app’s requests don’t appear in the connection log, compare with an explicit proxy argument. If that works but the system proxy doesn’t, check how the app reads proxy settings. Some apps only read settings at startup, so restart them after making changes. Consider TUN for apps that ignore the system proxy.

First, confirm that a regular desktop browser can access the internet through the same proxy. Then check whether the affected app is subject to loopback isolation. Use the client’s UWP loopback tool to exempt apps that need it. Alternatively, run CheckNetIsolation LoopbackExempt -s in an administrator terminal to view existing exemptions, then configure only the target app by its package family name. Don’t exempt every app at once. Restart the affected app and check the connection log. A loopback exemption only allows access to the local proxy; it doesn’t replace subscription, rule, or DNS configuration.

Turn off TUN and the system proxy in the client, then exit normally. Check whether the system proxy still points to a local port that is no longer listening. If direct access works again, restart and enable only one traffic-routing method at a time, watching for the first routing or DNS error. If the internet is still down, check whether the active network adapter’s DNS was manually set to an unreachable address, and look for routing conflicts with other VPNs, virtual adapters, or security software. Record the original values before restoring network settings; don’t delete all network adapters. Restart the system if needed to clear leftover state. Once the network is back, enable features one at a time and keep the smallest configuration that reproduces the issue.