Clash FAQs and Troubleshooting

Clash is a proxy configuration system built around rule-based traffic routing and proxy groups. The core reads the configuration, establishes connections, and applies DNS and routing rules; the graphical client handles subscription imports, mode switching, log viewing, and system proxy controls. When choosing a client, also confirm its core, supported operating systems, and configuration-field compatibility.

The original Clash established the configuration structure and rule model. Clash Meta expanded its protocol, DNS, rule, and transparent-proxy capabilities, and the project was later renamed mihomo. Many newer clients use the mihomo core while retaining Clash in the interface name. Common base fields usually remain compatible, while extension fields require support from the corresponding core.

For everyday use, choose Rule mode, which selects direct or proxied traffic based on domains, IP addresses, and rule sets. Global mode sends most connections through the currently selected policy and is useful for temporarily testing a node, but should not be treated as a long-term troubleshooting conclusion. Direct mode bypasses the proxy and helps determine whether the issue comes from the proxy path or configuration rules.

The client mainly provides configuration parsing, rule-based routing, and connection management; it is not a subscription service. Subscription URLs, node availability, data allowances, and expiration dates are managed by the relevant provider. Before importing publicly shared configurations from unknown sources, review their maintenance status, data practices, and terms of use, and avoid sending sensitive information over untrusted connections.

A subscription is usually an updateable remote URL that returns a complete configuration or a collection of nodes. The configuration file is the YAML content actually loaded by the client and may also include DNS settings, rules, and proxy groups. A node is simply a connection entry within that configuration. Subscription updates may regenerate or overwrite related content, so use overrides or keep a separate copy for long-term custom rules.

First confirm that the import reported success, then check whether a new configuration actually appears in the configuration list. If the configuration exists but its proxy groups are empty, common causes include an empty subscription response, an expired URL, an HTML page returned instead of a configuration, an unsupported subscription format, or a parsing failure at a specific field. Use the update history and core logs to identify the exact error line.

First verify in a browser or the provider’s dashboard that the subscription URL is valid and has not expired. Then check the system clock, network connection, and whether the URL was copied completely. Review the client’s update log to distinguish connection timeouts, certificate errors, permission denials, and YAML parsing failures. If the old configuration still works, keep a backup instead of deleting all configurations before finding the cause.

TUN mode creates a virtual network interface and changes system routes, so it generally requires administrator privileges or an installed service. On Windows, check that service mode is installed correctly; on macOS, verify system-extension or network permissions; on Linux, check the running user’s permissions, the TUN device, and related capability settings. After fixing permissions, fully quit and restart the client.

First check whether the browser uses its own proxy settings, an extension, or security software that controls networking. Then verify that the system proxy address and port match the client’s listening port, and confirm that the core is running. Some applications do not read the system proxy and require an in-app proxy, TUN mode, or another system-level interception method; enabling a toggle alone does not route every program through the proxy.

Some UWP apps are restricted by local loopback isolation and cannot connect directly to a proxy port running on the local machine. In a client that supports this feature, open its UWP loopback tool, select the apps that need network access, and save the changes. Restart the target app afterward. If an app’s identity changes after an update, check the selection again. Do not select every unrelated system component at once.

Global mode commonly uses a proxy group named GLOBAL, although the actual name depends on the configuration. Open the proxy or policy page and confirm that the group points to a specific node rather than an unavailable auto-select group. Do not judge by a single latency result: test the target website, connection stability, and sustained transfer performance as well. Switch back to Rule mode after verification.

A latency test often checks only a short connection to a designated test endpoint; it does not confirm that DNS, TLS, and the target website path are working. Check in order whether the proxy group selected that node, DNS returned a usable address, the rules assigned the target domain to the expected policy, and the node restricts any required protocol. Rule matches, connection errors, and DNS records in the logs are more useful than a single latency number.

Open the client’s connection records or live log, then visit the target website and inspect the domain, destination address, matched rule, and final policy. Modern pages often request the main domain, static asset domains, and third-party APIs at the same time, so inspect multiple connections. If the result is unexpected, adjust rule order or override content rather than merely renaming a proxy group.

Remote subscription updates typically rewrite the subscription configuration, so directly editing its rules, DNS, or proxy groups may be overwritten. Prefer the client’s override, extension-script, configuration-merge, or local rule-set features. If none are available, create a separate local configuration and record its source. Keep a working version before editing so you can roll back after a parsing failure.

Keeping a VPN or TUN interface running on mobile consumes some battery. Increase overly frequent health-check intervals, avoid enabling many frequently updated rules and logs at once, and choose protocols and modes based on actual needs. On Android, check battery optimization, background activity, and persistent-notification permissions. iOS background behavior is managed by the system; after switching networks, verify the connection again.

Switch to Direct mode first to confirm that the underlying network works, then return to Rule mode and check whether the current configuration loaded successfully. Next, confirm that no proxy group selected an unavailable node, and that the system proxy or TUN status matches your expectations. Watch for connection logs while accessing a site. If no new log entries appear, traffic is probably not reaching the client; if errors appear, continue by checking DNS, rules, and the node path.

Test several nodes from the same configuration first. If all of them time out, prioritize checking the local network, DNS, system clock, firewall, and the client’s listening status. If only a few nodes time out, the node address, port, or route is more likely at fault. You can also retest on another network. Repeatedly clicking latency tests can create extra concurrent requests, so wait for one round to finish before comparing results.

Find the client’s log directory and determine whether the interface process crashed or the core failed to start. Common causes include a syntax error in the most recently imported configuration, incorrect permissions on the configuration directory, missing core files, a leftover process from an older version holding the port, or unmet system requirements. Temporarily move the latest configuration aside and restart, but do not wipe all data; logs and older configurations can help with recovery.

Record the line number and field name shown in the log, then check indentation, colons, quotation marks, duplicate keys, and list formatting. If the syntax is valid but the log reports an unknown field, the current core version likely does not support that extension. Update to a compatible core, ask the subscription provider to adjust the format, or remove the incompatible field. Do not delete an entire DNS or rule section just to bypass one error.

First confirm that the local subnet is assigned Direct by the rules, and check whether TUN routes cover the LAN addresses. Common private ranges and localhost should normally stay direct, but real networks may use custom address ranges. If other devices need to access a proxy or development service on this machine, also check LAN access permissions, the listening address, and the system firewall. Define the intended access scope before opening a port.