Clash FAQ

Clash refers to rule-based proxy tools and their configuration ecosystem. Clients typically handle subscription imports, policy selection, system proxy settings, and log displays, while the core processes connections, DNS, and rule matching. mihomo is an actively developed core in this ecosystem. Different clients may use different cores and support different configuration fields. When troubleshooting, note the client and core names and versions from the About or core information screen, then check the relevant documentation. A setting in the interface does not guarantee that the currently loaded core supports every related option.

Installing the app only means the client is ready to run; you’ll also need a valid proxy configuration. This can be a Clash subscription from a service provider or a YAML file you maintain yourself, with working proxies, proxy groups, and rules. Tutorials and configuration snippets on this site explain how fields relate to one another; they are not a substitute for an actual service. Before importing, make sure the subscription format is compatible with the core. After importing, check that proxies appear, choose a policy, and enable the system proxy. Subscription URLs often contain access credentials, so protect them like passwords.

Rule mode matches connections against rules in order and applies the specified policy when a rule matches. It’s suited to everyday, site-by-site routing. Global mode sends connections that reach the core through the global policy, making it useful for checking whether rules are causing a problem; it does not mean every app is being routed through the proxy. Direct mode sends connections reaching the core straight to their destinations, though the core may still handle DNS. After switching modes, test with a new connection. Existing long-lived connections may keep using their previous route, so don’t judge the change by an already-open tab.

Common fields in an old configuration can often serve as a starting point for migration, but they must be checked against the core used by the new client. Before migrating, export the configuration and note your proxy group selections, system proxy port, TUN settings, and DNS settings. After importing, check that the syntax is valid, then test a connection. UI settings, scripts, and override mechanisms from the old client may not transfer directly. Choose a maintained client from the downloads page and fix fields based on the errors it reports. Once the new client works, disable the old client’s startup and proxy services to prevent both from routing traffic.

On the client’s configuration or subscription page, choose Import from URL, paste the complete address, and set the downloaded configuration as active. If you’ve added a subscription but haven’t activated it, the proxies page may still show old content. If the list is empty, check that the response is Clash YAML—not a login page, an error message, or an encoded list for another tool. Then confirm the configuration contains proxies or that proxy-providers successfully retrieved them. Don’t paste subscription URLs into public conversion sites; use a compatible link recommended by your service provider.

Start by checking the HTTP status and error type in the update log. A 401 or 403 may indicate an issue with credentials, permissions, or provider restrictions; a 404 may mean the URL has changed. For a timeout, check your network and DNS resolution. Sign in to your provider’s dashboard, copy the URL again, and check your account status and whether the subscription was reset. If updates require a proxy but your current proxy is unavailable, switch to a direct download or temporarily use a working configuration if the client supports it. Keep a local copy before updating. Deleting the configuration won’t fix a remote link and could leave you without proxies that still work.

Start with the line number and field name in the log, then inspect a few lines above and below it; the line flagged by the parser may only be where it noticed the problem. YAML uses spaces for indentation: keep each level consistent and don’t use tabs. Check for a space after colons, list-item hyphens, matching quotes, and exact matches between policy and proxy names. Enclose names with special characters in matching quotes. Fix one issue at a time and validate the configuration again; if another error appears, undo the most recent change. For subscription-generated files, use an override where possible so the next update doesn’t overwrite your fix.

First, check that the core used by your client supports TUN, then follow the client’s instructions to install its service or grant system permissions. Windows often requires administrator privileges or service mode; macOS may require approval for a helper component or network permissions; Linux needs suitable network management capabilities and an available TUN device. After granting access, restart the core and check whether route or device creation errors persist. Disable network interception by other VPNs to avoid route conflicts. Don’t keep piling on privilege-escalation commands. Use the logs to distinguish insufficient permissions, a missing device, and an address conflict, then address the specific cause.

select lets you manually choose a proxy or another policy, making it useful when you need a fixed route. url-test compares candidates using the configured test URL and interval, then selects an option based on settings such as tolerance supported by the core; the result only reflects connectivity to that test target. fallback selects an available option in candidate order, typically switching when the primary route fails. All three need to be referenced by rules to affect the relevant connections. After changing a policy, use a new connection to check which group and proxy were selected. A single test result doesn’t represent the actual speed of every website.

Prefer the client’s local override, rule-append, or merge feature, and check when it runs. Rules are usually matched from top to bottom, so exact domain rules should come before broad rules and the final MATCH rule. Referenced policy names must exist and match case exactly. For example, when routing a domain through a specific policy, make sure its proxy group has a working outbound option. Save and reload the configuration, then check the connection log to see which rule matched. Editing a subscription cache file directly is risky because updates can replace it. Save custom rules separately and verify the merged result after an update.

Give each configuration a name that identifies its source and purpose, and note whether it’s a local file or a remote subscription. After switching profiles, check that the active indicator, proxy groups, and DNS settings have changed. System proxy and TUN switches may be client-wide settings and might not change with the configuration. Back up the original configuration, local overrides, and any client settings you need—not just the proxy list. Remote subscription updates typically replace their contents; local files are maintained by you. When moving to another device, import and test one configuration first, then restore additional settings one at a time to spot compatibility issues.

First, make sure the host and other devices are on a LAN that allows them to communicate, LAN access is enabled in the client, and the client is listening on the right interface. On another device, enter the host’s LAN IP address and the actual HTTP or mixed port used by the client in its proxy settings. Don’t use 127.0.0.1; that points to the device itself. If the connection still fails, check the host firewall, guest network isolation, and whether the port is already in use. Only expose the proxy on a trusted network, and set authentication and firewall rules as needed. The external controller is a management interface, not a proxy port for other devices, and should never be exposed directly to the public internet.

First, confirm that regular websites work without the proxy. Then check that the configuration loaded successfully and your subscription account is active. Compare several proxies: if only one fails, check that proxy’s service status first; if all fail, check your device’s clock, DNS, network restrictions, and client logs. A test can time out simply because its test URL is unreachable, so verify with a new connection to a real destination rather than relying on the test button alone. You can temporarily switch networks for comparison, changing one thing at a time. If the log reports an authentication failure or unsupported protocol, fix the credentials or compatibility issue instead of continually increasing the test timeout.

The system proxy affects apps that follow system proxy settings; it doesn’t automatically route every connection. Check that the proxy address and port configured in your system match the values the client is actually listening on. Disable standalone proxy extensions in your browser, then use a new connection and check the client’s connection log. Command-line tools, games, and some apps may need their own proxy settings, or TUN if you need system-wide routing. If requests appear in the connection log but match DIRECT, check your rules and policy selection instead of changing the system proxy again. Quit other proxy apps so they don’t keep overriding your system settings.

Some Windows apps restricted by app containers can’t access a local loopback proxy, even when a regular desktop browser works. In that case, check for loopback restrictions. Make sure the client listens on a local address, then use its UWP loopback tool or Windows CheckNetIsolation tool to exempt the app package if needed; you may need administrator privileges. Apps differ in how they’re packaged and how they handle networking, so this won’t apply to every Microsoft Store app. Restart the affected app and check the connection log. If you’re using TUN, check routes and DNS as well—loopback exemptions don’t replace those checks.

With Fake-IP, a domain first resolves to a mapped address, which the core then associates with the real destination. Access can fail if DNS and the connection take different routes. Check whether another tool is handling DNS, whether your browser’s encrypted DNS is bypassing the intended route, and whether the domain needs to be added to fake-ip-filter. If your connection stops working after you close the client, turn off any lingering system proxy first. Then check whether system DNS still points to a stopped local service, restore its previous automatic or specified setting, and clear the DNS cache before trying again. Keep a record of network settings before changing them and restore settings one at a time. Before sharing troubleshooting logs, redact subscription URLs, credentials, and sensitive domains.