Clash FAQ

Clash usually refers to a family of rule-based proxy tools and its configuration ecosystem; mihomo is a maintained core project in that ecosystem. GUI clients such as Clash Verge Rev handle subscription imports, proxy group selection, and system settings, while the core parses configuration, matches rules, and establishes connections. When troubleshooting, first determine whether a GUI action failed or the core failed to start, then check the relevant logs. Clients may bundle different cores and support different configuration fields, so verify that older configurations load correctly after migration.

A client provides a local proxy and traffic-routing features, but installing it does not provide a remote proxy service. Connecting requires valid server details or a subscription containing them. Import a configuration you are authorized to use, set it as the active profile, then choose an available policy on the proxy page. Subscription URLs often contain credentials, so treat them like passwords. When reporting an issue, redact tokens, account details, and server authentication information; never post a full configuration publicly.

Rule mode selects a policy for each connection according to the rules in the configuration. Global mode sends connections that reach the core to the global policy, which still needs an outbound selected. Direct mode generally connects those requests straight to their destinations. Global mode does not take over every app on the device: traffic that does not enter through the system proxy or TUN may bypass the client. For everyday use, start with Rule mode. If one site behaves unexpectedly, briefly switch to Global for comparison, then check the connection log to see whether routing rules are the cause.

The system proxy is mainly for apps that follow the operating system’s proxy settings. TUN uses a virtual network interface and routing to capture traffic, making it useful for some apps that ignore the system proxy. You do not have to enable both. For initial setup, use the system proxy alone and confirm the subscription and outbound connection work before enabling TUN as needed. If your client supports using both, follow its documentation and avoid letting another VPN change routes at the same time. If connectivity breaks, turn off TUN and troubleshoot from the simpler setup you have already verified.

Clients that support the same configuration format and core features can usually reuse a subscription, but GUI overrides, scripts, keyboard shortcuts, and service-mode settings may not carry over. Back up the old configuration and local rules, then import the subscription into the new client separately and check that its core accepts the protocols and fields. Once the basic connection works, migrate overrides one at a time to avoid introducing multiple variables. Do not let two clients control the system proxy or TUN simultaneously. After verifying the new setup, disable the old client’s autostart and background services as needed.

Make sure you copied the complete subscription URL, not an account page link. Check whether it has expired, its token has been reset, and your device clock is correct. Review the import log for an HTTP status or parsing error: 401 and 403 usually indicate an authorization issue, 404 may mean the URL has changed, and an HTML response may come from a sign-in or verification page. If the log shows a timeout, check whether your current network can reach the subscription service. Avoid repeatedly submitting the URL to unfamiliar converter sites; use a compatible format provided by the service when available.

Open the core log and note the error’s line number and field name, then inspect that line and the one above it. YAML indentation must use spaces; list markers, spaces after colons, and quote boundaries can all affect parsing. If the error mentions an unknown protocol or field, check whether your core supports it instead of changing indentation alone. You can revert to the most recent configuration that started successfully, then restore local changes a section at a time. Avoid editing subscription-generated files long-term, as an update may overwrite your changes. Put custom settings in a client-supported override mechanism instead.

First check that the service mode or helper service required by your client is installed and running. Windows typically requires permission to install a background service; macOS may require approval for a helper component; Linux may need network administration permissions and an available TUN device. Follow the client’s documentation, and do not use elevated privileges for every app as a substitute for configuring its service. If permissions are in place but TUN still fails, close other VPNs and try again. Check the logs for driver, route, or port conflicts, and record your original settings before making changes so you can restore your network.

Confirm that the core is running, the active configuration is enabled, and the system proxy points to the address and port the client is actually listening on. Don’t copy a port from another guide. Then check whether the browser has its own proxy settings, extensions, or bypass list. Visit a new site with the connections page open: if no request appears, check how traffic enters the client; if a request appears with a DIRECT policy, check the rules and mode. Also rule out another proxy app overriding system settings. After changes, close existing connections or restart the browser so reused connections don’t skew the results.

Mobile clients typically route traffic through the operating system’s VPN interface, which requires approval at the system prompt on first connection. Android generally allows only one standard VPN service at a time, so starting another VPN may disconnect the current one. If the connection drops when the screen locks, check battery optimization, background activity, and the manufacturer’s autostart restrictions. Adjust permissions only for clients that need them. Don’t disable every battery-saving feature just to keep a connection alive; first confirm that background restrictions are causing the issue, then balance reliability against battery life. Verify the connection by testing actual access, too.

Use Rule mode, then filter the Connections page by the target domain or app to see the matched rule, policy group, and final outbound. To avoid cached connections affecting the result, close existing connections to the site and visit it again. Rules are generally matched from top to bottom, so a broad rule near the top may take precedence over a more specific one later. A final MATCH rule catches connections that did not match earlier rules. Before adding a custom rule, confirm that its policy name exists and check whether subscription updates may overwrite local changes. Whether a page loads in the browser alone does not show whether the intended rule took effect.

Manual selection is useful when you want a fixed outbound. An automatic latency-testing group chooses based on probe results, while a failover group generally selects an available member in configuration order. A probe only reflects connectivity to its specified test address; results may differ for other sites, video, or games. If you need a stable region for sign-ins, choose a fixed outbound to avoid session reauthentication from frequent changes. If no group members are available, check the subscription and basic connectivity first. Don’t try to fix the issue just by shortening the probe interval: frequent tests increase network requests and battery use on mobile devices.

Fake-IP maps domains to virtual addresses in a reserved address range, allowing the core to use the domain when handling the actual request. The address returned by a DNS lookup is therefore not the site’s real IP, and that does not necessarily indicate a DNS failure. Some local network services, games, and apps that require real IP addresses may not be compatible. Follow your core’s documentation to filter specific domains or adjust DNS mode. Don’t clear all DNS settings. After making a change, reconnect the app and, if needed, clear the system DNS cache. Confirm that both DNS queries and connections follow the intended path.

GeoIP data is used to match IP address locations, but it affects routing only when the configuration uses GEOIP or a related rule. First check the connection log for an earlier domain rule, rule set, or MATCH that takes precedence. Then confirm which database and update path your configuration uses. A core may rely on MMDB, another geographic data format, or a separate rule set; these files are not interchangeable. After an update, reload the data as required by the client and test with a new connection. An IP’s registered location may differ from where a service is hosted, so check the connection log and domain rules together.

Autostart, enabling the proxy on launch, restoring the previous configuration, and running a background service are separate settings. Enabling one does not guarantee the others are enabled. Confirm that the client actually starts after you sign in, then check whether the active configuration, policy group, and proxy switch are restored. TUN also requires a helper service and permissions. If the issue occurs only during startup, the network may not be ready yet; check the logs and try a delayed-start option if the client provides one. Avoid creating multiple startup tasks to launch the same app, as they may compete for listening ports or overwrite system proxy settings.

Turn off the proxy and check basic network access first. Confirm that your device clock is correct, the subscription is still valid, and there are no traffic or connection limits. Then test just one known-good outbound and check the logs for DNS resolution, handshake, or connection-refused errors. If every outbound fails, check the local firewall, network restrictions, and conflicts with other VPNs before repeatedly changing configurations. A built-in test address may itself be unreachable and show a timeout, so compare actual access with the logs. If the issue occurs on only one network, retest on another trusted network to narrow it down.

Some UWP apps are restricted by network isolation and cannot access a loopback proxy address on the local device. First confirm that this is the issue, then use the client’s loopback exemption tool or run CheckNetIsolation LoopbackExempt as an administrator to manage the specific app. Run CheckNetIsolation LoopbackExempt -s to view existing exemptions; adding one requires the exact app package identifier. Exempt only apps that need it, record the change, and remove the exemption when it is no longer needed. Don’t apply this fix to ordinary desktop apps with connectivity problems.

First define what you expect: which domains should resolve through the proxy, and which local-network or direct domains may use local DNS. Then check whether core DNS, TUN DNS interception, browser Secure DNS, and system resolver settings are bypassing one another. The resolver location shown by a test page is only a clue; assess it alongside your configuration, connection logs, and packet captures if needed. Not every direct DNS query should appear at the proxy exit. Change one layer at a time and establish a new connection after each change. Encrypted DNS protects queries in transit, but does not automatically route them through the proxy.

Turn off TUN to compare and confirm that routing or DNS interception is responsible. Then check whether local network addresses, private IP ranges, and local domains use a direct connection. Configure bypass or direct rules for your actual network rather than excluding every address range. If you also use a corporate VPN, the routes may conflict; compare the routing tables and interface priorities. Printer discovery may rely on multicast, so adding a domain rule alone may not help. First try accessing the device directly by its address, then check the discovery protocol and reconnect the device after making changes.

Check whether the system proxy still points to a local port that is no longer listening, and disable it in your system network settings if needed. Then check whether TUN, a helper service, or another VPN is still running; closing the GUI does not necessarily stop the background core. If you manually changed DNS or routes, restore them using your notes instead of resetting every network setting. Test direct web access and local network access separately. When restarting the client, enable only the system proxy first. Once it works, re-enable TUN to identify which setting caused the problem.