Clash FAQ

The client manages configurations, lets you choose policies, and controls the system proxy. The core parses the configuration, matches rules, and establishes connections. The service provider supplies nodes or a complete configuration through a subscription. Installing a client does not provide proxy service. When troubleshooting, distinguish between interface actions, core errors, and subscription status. Compatibility across clients depends on the core in use and the fields it supports. Before switching clients, check the core name in the About screen or core settings, then review the import log.

Rule mode is usually best for everyday use: rules in the configuration determine whether connections use a proxy or connect directly. Global mode applies the global policy to connections handled by the core, while Direct mode typically sends those connections straight to their destinations. Global mode does not take over every app on your device; traffic must still reach the core. To check whether a routing rule is causing a site to fail, briefly switch to Global and test with the same node, then switch back to Rule mode. If both modes fail, check the node, DNS resolution, and local traffic interception.

A system proxy registers an HTTP or SOCKS proxy with the operating system. Each app decides whether to use it, and some games, command-line tools, and apps with their own network stacks ignore it. TUN mode routes traffic through a virtual network interface, typically covering more apps but requiring the right permissions and DNS settings. If your browser works but another app does not, first check whether that app supports the system proxy before enabling TUN. Avoid running multiple clients that take over routing at the same time; they can compete for the default route or forward traffic more than once.

Whether they work together depends on the node protocol, configuration format, and server status—not simply on whether the service is paid. Paid proxy subscriptions are usually private links for fetching configurations. Public nodes can stop working at any time, and their operators and data practices may be difficult to verify. Before importing anything, check its source, supported core, and terms of use. Don’t concatenate multiple complete configurations. If you need to combine them, use the merge or rule override features supported by your client and keep a copy of the original configuration so you can revert. This site does not provide nodes or maintain subscription services.

Check both. First choose a client for Windows, macOS, Android, or Linux, then select a package for your device’s architecture. x64 and AMD64 usually refer to the same architecture; ARM64 is a different processor architecture. On macOS, check your chip in About This Mac; on Windows, check System Information; on Android, check your device specifications. Don’t infer the architecture from the operating system version alone. If the app won’t launch after installation, note the system error and check the client’s minimum requirements instead of repeatedly installing the same incompatible package.

First, check the provider’s account page for the subscription’s expiration date, account status, and whether the link has changed. Then make sure the copied link doesn’t contain extra spaces, line breaks, or webpage text. If the client shows an HTTP status code, 401 or 403 usually points to an authorization issue, 404 may mean the URL has changed, and 429 means you should stop retrying so frequently. If the download succeeds but parsing fails, check that the response is a configuration supported by your client—not a login page or plain node-sharing text. Redact full subscription URLs from logs and screenshots. If a link is exposed, regenerate it through the provider.

First determine whether the issue is permissions or configuration. Desktop clients may require a service component, authorization for a helper app, or administrator privileges during initial setup. On Android, you’ll typically need to allow the VPN connection in the system prompt. After granting access, check the logs for remaining permission, device creation, or route-writing errors. If a component fails to install, reinstall the service as directed by the client. Don’t change system drivers or disable security protections without a clear reason. Also quit other VPNs and apps that take over virtual network interfaces. Elevated permissions won’t fix invalid fields or indentation in a configuration.

Keep a copy of the original file, then check the line number and field name in the log. YAML uses spaces for indentation; list markers, colons, and indentation must be consistent. Policy group names must exactly match the names referenced by rules, including capitalization and spaces. If the core reports an unsupported protocol or field, check core compatibility instead of simply deleting the offending line. Change one thing at a time and reload the configuration to isolate the cause. If the issue started after a subscription update, switch back to the last working configuration and send the provider a redacted error snippet and the client’s core name.

A node selection in a policy group only affects connections that reference that group. Confirm the client is in Rule mode, then find the request in the connection log and check which rule matched and which policy was ultimately applied. If the match is DIRECT, changing a different policy group won’t affect it. Custom rules are usually evaluated from top to bottom, so a broad direct rule near the top may override later rules. Make sure the active configuration is the one you edited and check whether a subscription update overwrote your local changes. After editing, create a new connection; existing connections may not be matched again.

Use the client’s override, merge, extension script, or persistent rules feature instead of editing a remote configuration file that gets replaced on every download. Check where the feature inserts rules, put specific domain rules before the appropriate broader rules, and keep MATCH as the final fallback. After saving, update the subscription and confirm your rules are still present and are actually matching. Override syntax varies across clients, so check it again when switching. Rule providers organize rule sets; whether your rules persist depends on how the client loads them.

First check the client for its local listening address, port, and supported proxy protocols. Then follow the tool’s documentation to set its proxy options or environment variables. Many tools support HTTP_PROXY and HTTPS_PROXY, but some only read lowercase variables or their own configuration file. Don’t assume one setting works for every program. HTTPS_PROXY specifies the proxy endpoint; when using a regular HTTP proxy, its value may still start with http://. Open a new terminal to test, then remove temporary variables when you’re done. Don’t expose the local listening address to the network to fix a proxy issue on a single device.

First check whether the DNS mode is causing the issue. Keep the node and rules unchanged while testing the affected domain and app. If an app needs real IP addresses, LAN discovery, or special domain resolution, add the necessary domains to fake-ip-filter using syntax supported by your core. Then restart the app and clear its DNS cache. Excluding a domain changes how it resolves; it does not automatically send the connection direct—routing rules still apply. Don’t add every domain to the filter. If you need to switch to redir-host, also check that your upstream DNS, routes, and existing rules are suitable.

Pause the proxy and check your basic network connection. Then verify the subscription status, system time, and whether the node is still available under your service plan. Test other nodes and a different network to tell apart a single-node outage, a local network restriction, and a configuration-wide issue. The built-in test connects to a specific test address; a timeout alone doesn’t prove that every destination is unreachable, and the result is not a download speed test. Check the logs to see whether the failure is in DNS resolution, connection establishment, or the TLS handshake. Don’t repeatedly retry in batches. If the same node keeps failing across networks, send the provider redacted logs.

Confirm the core is running and that the local proxy port matches the port registered with the system. Then check whether a browser extension or a separate proxy setting is overriding it. Quit other proxy tools, toggle the system proxy off and back on, and test a new connection. Check whether the system bypass list includes the destination domain; system proxy settings generally apply only to apps that respect them. If the connection still fails after you close the client, look for a system proxy setting left behind that points to a local port. Don’t just switch nodes and overlook the local proxy endpoint: if the port is in use or the core failed to start, every node may appear to be down.

Some apps using AppContainer network isolation can’t access a local proxy port directly. That can leave your browser working while a specific app fails. First confirm the affected app uses this type of isolation, then check whether your client can manage loopback exemptions. If it can, grant access only to the apps that need to reach the local proxy. Windows users familiar with its administration tools can also use CheckNetIsolation to inspect and manage exemptions. Don’t enable exemptions for every app. Loopback exemptions won’t fix server or DNS issues; if the app still fails after authorization, check the connection log.

If domains won’t open, first distinguish a DNS resolution failure from a proxy connection failure. Check the core logs for resolution errors, and confirm that dns-hijack, upstream DNS, and routing settings are supported by your core. On Android, check for conflicts between Private DNS and the client’s DNS interception; don’t change several settings at once. If the connection drops only when the screen is locked, check battery optimization, background activity permissions, and the system VPN status. Make sure another VPN app hasn’t taken over the connection. Test after each change and keep the original settings so background restrictions aren’t mistaken for a failed node.