Clash FAQ

The core establishes connections, resolves domain names, and applies routing rules. The GUI client handles configuration imports, system proxy controls, service management, and logs. A subscription provides node or configuration data remotely. mihomo is a core; clients that use it can still differ in their interfaces and override mechanisms. Installing a client does not automatically provide usable nodes. When troubleshooting, note the client name, core details, and configuration source separately so interface differences are not mistaken for protocol failures.

Clash Home is a resource site for clients and configurations. It is not affiliated with the original Clash project or the teams behind individual GUI clients. The Clash ecosystem consists of independent projects, and similar names do not imply shared maintainers. Before downloading, verify the specific client, target operating system, and processor architecture. For project details, consult its documentation, release notes, and license. Our guides explain general workflows; they do not replace account support from subscription providers or bug-report channels maintained by software developers.

Rule mode is the usual starting point for everyday use: connections are matched against rules in order and handled by the selected policy. Global mode sends connections entering the core through the global policy, which can help determine whether routing rules are causing a problem; it does not mean all device traffic is being captured. Direct mode typically connects traffic entering the core straight to its destination, although the core may still resolve names and listen for connections. Restore your previous mode after testing, then check the matched rule and route on the connections page rather than relying on the toggle alone.

No. A client's software license and access to node services are separate. A client being free to use does not mean remote servers are provided at no cost. Public nodes can have uncertain availability, operators, and logging policies, so avoid using them for sensitive data. Before importing an unfamiliar configuration, review its remote rules, DNS settings, scripts or overrides, and whether it exposes a local control interface. If a subscription URL has been exposed, ask the provider to reset it; deleting it from the client does not make the old URL safe to use.

Start by filtering clients by operating system, then check configuration compatibility, core support, service installation, and local override features. Windows users can look at Clash Plus, then compare Clash Verge Rev, FlClash, and Clash Nyanpasu. Clash for Windows is no longer maintained, so treat it as a migration source rather than the default for a new setup. Back up your subscription source, rules, and policy group selections before migrating; do not overwrite the old application directory. Test the old and new clients separately to avoid competing changes to system proxy settings or port conflicts.

After adding the subscription URL on the configuration page and updating it successfully, select that configuration to make it active. Next, open the proxy page and choose a node for the policy group you intend to use. Then enable the system proxy or, if needed, TUN. Finally, open the connections and logs pages and visit a known test destination to confirm the connection reaches the core and matches the expected policy. Seeing an item in the configuration list only means the data was saved; it does not mean the configuration is active. A successful node latency test also does not prove that browser traffic is being handled by the client.

Start with the update error. For authentication failures or access denied messages, check whether the subscription expired or was reset, and make sure the URL was copied in full. If the response is a web page or empty, verify that you copied the subscription URL rather than the account management page. For timeouts, check your local network and whether the update request depends on a proxy that is already unavailable. Never submit a full subscription URL to a public converter or forum. If the old configuration still works, keep it while asking the provider to verify the format and account status; deleting it first could leave you without a working configuration.

Use the log to find the line number, then inspect the surrounding lines. Check for tabs mixed with spaces, missing hyphens before list items, and missing spaces after colons. Make sure the file is YAML supported by Clash or mihomo, not a web page, a Base64 node list, or JSON for another core. Once the syntax parses, check that node names referenced by policy groups and policy names referenced by rules actually exist. Keep a copy of the original file and fix one issue at a time before reloading. This makes it easier to distinguish syntax errors from unsupported fields.

TUN creates a virtual network interface and changes routes, so it requires more privileges than a standard system proxy. Follow the client's instructions to install its service or helper component, then confirm the service is running. Desktop systems may require administrator approval; Android requires permission for the system VPN connection request. If it still fails, check for conflicts with another VPN, virtual adapter utility, or security app. Avoid repeatedly reinstalling drivers. Close conflicting programs, restart the relevant services, and use the logs to identify whether the failure involves permissions, interface creation, or route changes.

First confirm that Android's VPN permission is still active, then check the client's per-app routing settings: an allowlist captures only selected apps, while a bypass list excludes specified apps. Also check whether a rule sends the domains used by the app directly. Android typically allows only one standard VPN service at a time, so another VPN or local filtering tool may replace the current connection. If the connection drops when the screen locks, review battery optimization, background activity, and autostart permissions. Reconnect after each change and use the logs to see whether requests reach the core.

Open the client's connections page, make a new request to the destination, and inspect its domain, matched rule, and proxy chain. Rules are usually evaluated in order, so an earlier broad rule can take precedence over a more specific one. MATCH is the catch-all rule and should be last. After changing rules or policy selections, existing long-lived connections may keep using their original route. Close those connections or restart the app before testing again. If the connections page shows only the destination IP, check name resolution and sniffing settings. Do not infer that a particular rule worked solely from the exit address shown by a website.

Use the client's separate override, configuration merge, or extension features rather than editing cached files that subscription updates may replace. Check the merge order and whether list fields are appended, prepended, or replaced; this depends on the client and is not consistent across all software. After saving, inspect the final active configuration to confirm that custom rule placement, policy group references, and DNS fields are intact. When switching clients, verify the override mechanism again—scripts and extension files from the old client may not transfer directly.

Whether you can share one subscription depends on the provider's device limit, concurrent connection limit, and terms of use. The client cannot change those restrictions. Even with the same URL, platforms may differ in supported protocols, TUN settings, and override options. A safer approach is to share the node source while keeping system-specific fields in local overrides on each device. Sync only the configuration you need, and never put a subscription URL containing access credentials in a public repository. If it works on one device but not the other, compare core capabilities and the final configuration before assuming a device limit is responsible.

Make sure the host and the other device can communicate over the same local network. On the host, enable LAN access in the client and check the listening address and actual HTTP or mixed proxy port. On other devices, enter the host's LAN IP, not 127.0.0.1, which refers to the device itself on each machine. Allow trusted LAN access through the host firewall only as needed, and enable proxy authentication if appropriate. Never expose the proxy port or control interface to the public internet. Other devices will lose access if the host sleeps, its IP changes, or the client exits.

Start by defining what you expect: which resolvers should handle each domain, and which connections should go through the proxy. A test site's listed resolvers may be the egress points of recursive DNS services, so their locations alone do not prove a leak. Check the client's DNS logs, system resolver settings, browser secure DNS, and TUN DNS interception settings one by one. A browser's encrypted DNS may bypass the core's configured DNS path, or it may still connect through the proxy; verify both separately. Change one setting at a time and observe the actual routing of DNS queries and destination connections.

Pause the proxy first and confirm that your local network, system clock, and basic DNS resolution are working. Restart the client and check that the configuration loaded successfully. Then verify the node address, port, authentication details, and protocol support. Cross-check with a known working node and a different test destination. A latency test can time out because its test server is unreachable or the timeout threshold is too short; that does not necessarily mean the node is offline. If all nodes fail, investigate the local service and network first. If only one fails, contact the provider. Recording the error type and time is more useful than repeatedly running the test.

Check that the core is running and that the address and port recorded in system proxy settings match the client's listening values. Then confirm that the app follows the system proxy: browser extensions can override proxy settings, while terminal tools often need separate proxy options or environment variables. If the connections page shows no new entry when you make a request, the traffic likely never reached the core. If an entry appears but uses the wrong route, check the rules and policy group. During troubleshooting, let only one program manage system proxy settings to prevent other clients, extensions, or VPNs from repeatedly changing them in the background.

Some packaged Windows apps are restricted by network isolation and cannot access a proxy on a loopback address, even when a standard desktop browser works. First confirm that the affected app is subject to this restriction. Then use the client's UWP loopback utility to add an exemption only for the apps that need it, and restart the app to test. Do not grant access to every app by default. Windows' built-in CheckNetIsolation tool can also inspect and manage exemptions, but confirm the exact app package identifier before using it. A loopback exemption addresses local access restrictions only; it cannot fix node, DNS, or remote service failures.

For a port conflict, close other proxy clients and any leftover core processes, then identify which process is listening on the port. Do not terminate an unknown system process. You can also switch the current client to an unused port, but update system proxy settings and any apps configured manually. If internet access stops after closing the client, check system network settings for a manual proxy still pointing to a local port. If you used TUN, confirm that its service and routes were restored correctly. Once network access is back, start just one client to avoid problems caused by multiple instances.

Include your operating system, processor architecture, client name, core details, current mode, steps to reproduce, and a short excerpt of logs from around the time of the failure. Say whether the issue affects all connections or only a particular app, and whether it occurs only with TUN, on a specific network, or under a particular rule. Before sharing, remove full subscription URLs, passwords, access tokens, node account details, and unnecessary personal domains. Check screenshots for exposed addresses and configuration sidebars. Share a minimal configuration with sensitive details removed rather than uploading the entire configuration directory. Further redact any log details that could identify you.