Clash FAQ
Config & Connection Troubleshooting

The client provides an interface for importing configs, switching proxy groups and viewing logs. The core reads the config, handles connections and applies routing rules. mihomo is one actively developed core in the Clash ecosystem. A subscription provides a URL with config or node information. Installing a client alone does not provide a working connection; you also need a valid config and the relevant service. When troubleshooting, first confirm that the config is enabled and the core is running, then check the selected proxy group. This helps avoid mistaking a subscription issue for an installation problem.

For everyday use, start with Rule mode so connections are routed according to the config. Global mode applies the global policy to connections handled by the core, making it useful for briefly checking whether rules are causing a problem. Direct mode sends those connections straight to their destinations. Global mode does not capture every app on your system; coverage still depends on the system proxy or TUN. Switch back to Rule mode after testing and check the actual connection logs rather than relying on the mode button alone.

You can't determine compatibility from the URL alone. A Clash YAML config typically includes proxies, proxy groups and rules, while Base64 content may be just a node list for another client, without a complete routing config. Ask your subscription provider for a format explicitly labeled Clash or mihomo. If your client supports format conversion, follow its instructions. Subscription URLs may contain access credentials, so don't submit them to unfamiliar online converters or share the full URL publicly.

Many basic fields may carry over, but that doesn't mean configs are fully compatible in both directions. Some protocols, DNS options and extended rules supported by mihomo may not be recognized by older cores. Third-party clients may also merge or override config values. Before migrating, back up the existing file, run the client's config check, then review startup logs for field or protocol errors. If you see an unknown type, check the core's supported features instead of simply deleting the offending field and carrying on.

Clash Tutorial Hub curates client download links and Chinese-language config guides. It is not affiliated with the client projects and does not provide subscription accounts or proxy nodes. Client downloads, core features and subscription services are separate parts of the setup: check your platform and permissions for installation issues, config formats and logs for configuration issues, and contact your service provider about account expiry or data limits. To verify a client's source, check the project name and release channel; don't infer ownership from search terms such as “official Clash site” in a page title.

Add the URL on the client's config or subscription page. Once it downloads, select that config and set it as the active one; seeing an entry in the list doesn't necessarily mean it's enabled. Next, check that the core is running and that a proxy group has selectable policies, then enable the system proxy and test in a browser. If the only available policy is the default Direct option, check the subscription download result and config parsing logs. For your first setup, verify the system proxy before enabling TUN so you can pinpoint where a problem occurs.

First check whether you downloaded a config or a web page. HTML tags in the logs often mean the URL points to a login page, error page or gated share page. Copy the subscription URL from your provider again. If the response is YAML, check indentation, spaces after colons and accidental tabs; also inspect the line just before the reported error. Whenever possible, fetch the original config again. Save a copy before editing, then run the client's config check before reloading it.

Close other proxy clients and any leftover cores, then check whether a process is using the same listening port. Reinstallation is usually unnecessary. Stop the conflicting process or change mixed-port to an unused port, then reload the config. After changing the port, update browsers, terminals and other apps where you set the proxy manually. For a system proxy managed by the client, turn it off and back on. Don't change only the config while leaving apps pointed at the old port; the core may start normally but still be unreachable.

Turn off TUN first and confirm that the regular system proxy works. Then install or repair the service component as instructed by your client. Windows typically requires administrator approval; macOS may require approval for a helper; Linux requirements depend on how it runs and your network-management permissions. After granting access, restart the relevant service, enable TUN and check the route and adapter logs. Close other VPNs or traffic-capture tools to avoid route conflicts. Don't leave system security protections disabled just to dismiss a warning.

When a mobile app creates a tunnel for the first time, it usually asks for permission to configure a VPN. Allow it in the system prompt. On Android, if the connection drops when the screen locks, check battery optimization, background activity and auto-start restrictions. First confirm that the app is actually being stopped in the background, then adjust its settings as needed. On iOS, check that the VPN configuration is enabled and that another VPN isn't switching connections. The system VPN icon only indicates tunnel status; it doesn't confirm that the subscription is valid or every destination is reachable. Check the client logs as well.

Not necessarily. A client speed test typically connects to a specific test URL. A timeout could mean the test server is unreachable, DNS is failing, the handshake failed or the node itself is unavailable. First test a service you actually need to reach through that node, then check the connection logs. If needed, try a known-accessible test URL and use the same conditions for each node. A speed-test result isn't the same as download speed or performance across all sites. If several nodes fail at once, check your local network, system clock and subscription status before rerunning tests.

select lets you choose the outgoing proxy manually, which is useful when you want to stay on the same node. url-test picks a candidate based on test results; the test URL and interval affect the choice. fallback selects the first available candidate in the configured order, prioritizing your preset preference. All three work only with candidates listed in the config; they don't add new nodes automatically. Changing a policy usually affects new connections, while existing long-lived connections may keep using the previous route. Reconnect when testing a change.

Use the client's override, rule extension or config merge feature instead of editing a remote file that subscription updates may replace. Rules are matched from top to bottom, so put specific domain rules before broad rules and MATCH. The target proxy group name must exactly match the name in your config. After adding a rule, reload and check the matched rule and route in the connection details. Merge order varies between clients; saving the rule is only the first step. Confirm it's present in the final active config.

In Fake-IP mode, mapped addresses from the reserved range are usually expected. The core uses the mapping to associate a domain with a connection; it doesn't mean the real server is at that address. If a LAN device, particular game or app that relies on real DNS responses has problems, add the required domains to fake-ip-filter. Then clear the relevant DNS cache if your client supports it and try again. Don't change all your DNS settings just because an address looks unfamiliar; first check whether the affected app and its requests are going through the core.

When reproducing the issue, note the client name, core details, operating system, mode and time, and capture the relevant logs from just before and after the failure. Before sharing, redact the full subscription URL, access credentials, node passwords, account identifiers, and any domains or addresses you don't want public. QR codes in screenshots may also contain subscription details. Share only the necessary snippets, such as parsing errors, connection failure reasons and matched rules; avoid uploading the entire config directory. If a full subscription URL has been exposed, ask your provider to replace it or revoke the old credentials.

First distinguish a server-side rejection from a local connection failure. A 401 or 403 may indicate an issue with credentials, permissions or your provider's policy; a 404 often means the URL has changed. For a connection timeout, also check your current network, DNS and the route used for the update request. Sign in to your provider's site to check the expiry date, data limit and latest URL. When copying it, make sure you don't omit query parameters or include spaces. If updating requires a node that's currently unavailable, try Direct mode or another working network. Avoid rapid repeated retries, which may trigger additional limits.

First check whether the core is listening on the expected local address and port, then see whether another program has changed the system proxy settings. Browser extensions, in-app proxy settings and terminal environment variables can override system settings, and some apps don't use the system proxy at all. Make a new request in your browser and check whether it appears in the client's connection list. If it doesn't, check how traffic is being captured; if it does, check the rules and node. Consider TUN only if you need to capture apps that don't follow the system proxy.

Some UWP apps are subject to network isolation and may not be able to access a local loopback proxy. First confirm that a regular desktop browser works through the same proxy. Then check whether your client provides a UWP loopback exemption tool; if so, exempt only the apps that need it. You can also use Windows CheckNetIsolation to view and manage rules. Confirm the app's package identity before making changes. Don't exempt every Store app or assume every Store app connection problem is caused by loopback restrictions.

First check whether the app appears in the client's connection list. Then confirm that its TCP or UDP traffic is being captured and that the selected node supports the required transport. A working browser proves only that part of the route works; it doesn't confirm that UDP is working for games or voice apps. If the problem starts only after enabling TUN, turn it off temporarily for comparison and check routes, DNS and conflicts with other VPNs. Change one setting at a time and record the results. If needed, retest on another network you're authorized to use.

Open your system network settings and check for a manual proxy still pointing to a local address; the listening port may no longer be available after the core exits. Disable the leftover proxy, then confirm that TUN or the VPN has disconnected normally. If needed, restart the client and turn off traffic capture before quitting. If the problem persists, check whether DNS is still set to an address that only works while the client is running, and restore your original network settings. Don't reset the entire network right away; keep the logs and original config to help identify the cause.