Clash Setup Guide

Before you start, understand the difference between the client and the subscription. The client reads the configuration, applies rules, and establishes connections. The subscription provides usable nodes, policy groups, and sometimes traffic-routing rules. Installing the client alone doesn’t give you a working outbound connection. First, sign in to your service provider’s account and get a subscription URL for your client. Make sure your service is still active. A webpage sharing link, an account sign-in page, and a subscription URL are different things and can’t be used interchangeably.

Open the client and go to “Profiles” or “Subscriptions.” Look for “New,” “Import,” or a plus button. If asked to choose a type, select remote subscription or URL import, then paste the full URL into the address field. The profile name is just for your own reference, so use a label that makes it easy to identify; don’t use the subscription URL as the name. Check that no spaces, line breaks, or extra punctuation have been added to the start or end of the URL, then click Download or Import and wait for the request to finish.

A successful import usually appears as a profile card or subscription entry. Some clients activate the new profile automatically; others require you to click “Use,” “Activate,” or the profile name. Make sure the active profile is selected, then open “Proxies” and check that its policy groups appear. An imported entry alone doesn’t mean the profile is active. If the Proxies page still shows old content, check which profile is enabled before trying again—don’t repeatedly import the same subscription.

If your provider gives you a local configuration file, import it from the same area and use a Clash configuration format supported by your client. The same file extension doesn’t guarantee compatible contents: a link might return a generic node list, a full YAML configuration, or a format specific to another client. If parsing fails, fields are unsupported, or a protocol isn’t recognized, first check the subscription type and core requirements. Don’t delete erroring fields at random—you could break a valid configuration.

If the import fails, start with the error shown on the Profiles page, then check the Logs for the request result at the same time. An authentication error usually means you should check your account or get a new URL. For a timeout, determine whether the issue is your current network or the subscription server. A parsing error usually points to a format or compatibility issue. If updating the subscription requires a proxy but you don’t yet have a working profile, you can get stuck in a startup loop. Check your provider’s first-import instructions instead of repeatedly changing unrelated DNS settings.

Subscription URLs often include account-specific parameters, so treat them as sensitive information. When asking for help, share only the error text after removing URLs and node credentials. Don’t send a subscription QR code or full configuration. Once this step is complete, the Proxies page should show the policy groups supplied by the subscription. Keep the original configuration and default rules for now. In the next step, change only the mode and outbound policy to avoid altering too many variables at once.

Once the configuration has loaded, look for the mode selector at the top of the Proxies page, in the mode section of the home screen, or in the system tray menu. For your first setup, choose “Rule.” It matches connections against the rules in your configuration and routes them to the corresponding policies, preserving the intended split between direct and proxied traffic. Mode selection determines how traffic that has reached the core is handled; it doesn’t automatically route traffic from every app through the client. Configure traffic routing separately in the next step.

“Global” sends connections that reach the core through a single global policy. It can help with a temporary comparison or a task that needs one consistent outbound route, but it doesn’t guarantee that every app on your system uses the proxy. “Direct” sends connections that reach the core straight to their destinations, which can be useful for pausing proxy routing or troubleshooting. There’s no need to leave Global on for everyday browsing, and Direct doesn’t mean the client is closed—the core may still be running and the system proxy may still be enabled.

After switching to Rule mode, expand the main policy group in your subscription. Its name depends on whoever created the configuration; it might be “Proxy,” “Select Node,” or something else. There’s no standard name across clients. Find the group referenced by the rules, then choose a node from it. If the selected option is Auto Select, Failover, or another policy group, expand it to see where it ultimately routes traffic. If the final policy is DIRECT, that connection is direct; don’t infer the outbound route from the top-level group name.

If your client has a connectivity test, run it to see whether a node can complete the test. The result reflects only that node’s performance to the test address at that moment; it says nothing conclusive about every website, video, or game. A timeout might also mean the test address is unreachable. For your first verification, choose a specific node. Once your browser connects normally, you can enable automatic selection. That makes it easier to tell whether a problem comes from a changed outbound node or another setting.

Don’t rewrite all the rules included with the subscription or change every category group to use the same outbound route. Start with the main policy group, then check which group a specific site matches. Change a group only when its current route doesn’t meet your needs. Rule updates, subscription updates, and manual overrides can interact, so before making advanced changes, read the Protocol Guide’s notes on rule and configuration compatibility. Keep a copy of the original configuration so you can restore it.

At the end of this step, the client should show “Rule” mode, and the main policy for proxied traffic should point to a working outbound route. Your browser may still be using its previous network path. That’s expected: the mode is set, but the system hasn’t routed requests through the client yet. Leave the configuration as is and move on to enabling traffic routing.

Check the core status on the client’s home screen or status bar. If it isn’t running, failed to start, or shows a configuration error, fix that before enabling the system proxy. The system proxy sends requests from apps that follow the operating system’s proxy settings to the local core. If the core isn’t listening, enabling the system proxy first could temporarily prevent your browser from reaching websites. Keep the client running and check for port conflicts or startup errors before continuing.

DESKTOP: ENABLE THE SYSTEM PROXY FIRST

In the Windows, macOS, or Linux client, look for the “System Proxy” toggle. It’s commonly on the home screen, in settings, or in the tray menu. Turn it on, then open a new browser tab for the verification steps. Support for system proxies varies across desktop environments and apps; browser extensions, enterprise policies, or an app’s own proxy settings may override the system setting. If your browser has a proxy-switching extension, disable it temporarily to prevent it from overriding the client.

For your first setup, use the system proxy alone. Leave TUN off, and don’t enable “Allow LAN.” That setting lets other devices connect to the proxy running on your computer; it doesn’t affect whether your own browser can use the proxy. Don’t expose the listener to a wider network just to test your connection. If another proxy or VPN is running, save its settings and disconnect it first to reduce conflicts between proxy, routing, and DNS settings.

MOBILE: APPROVE THE SYSTEM VPN PROMPT

On Android and iOS, the client usually connects using the button on its home screen. The first time you connect, the system asks for permission to add or establish a VPN connection. Confirm the app’s identity and follow the system prompt to allow it. Once connected, you can check for an active connection in the system status area or VPN settings. The VPN indicator means the app has a system traffic-routing channel; it doesn’t guarantee that every connection uses a remote node. Actual routing depends on rules, policies, and app exclusions.

If the connection drops as soon as you tap Connect, check the client logs for configuration errors, incomplete authorization, or another VPN using the connection. On Android, a per-app proxy list may exclude your browser. On iOS, on-demand connection settings can affect automatic reconnection. For your first test, keep the default routing scope and verify the connection while the client is in the foreground. Once the basic connection works, troubleshoot background disconnects, battery optimization, and auto-connect settings in the FAQ.

Use TUN Only When You Need It

If the browser works through the system proxy but a desktop app still bypasses it, consider TUN. It routes traffic through a virtual network interface, often requiring a service component or elevated permissions, and can affect routing and DNS. Before enabling it, read the client’s service installation or permission prompt and note your current settings. TUN isn’t a speed boost or a requirement for everyone. Don’t change the system proxy, TUN, and DNS settings all at once during your first setup. For details on how it works, see the Protocol Guide.

You should now see that the core is running and either the desktop system proxy is enabled or the mobile VPN is connected. Don’t treat the “Connected” status alone as proof that everything works. Next, verify where a real request is routed.

Open a new browser tab, visit a site you expect to use the proxy for, and open the client’s “Connections” page. Use a new request rather than relying on a page that’s been open for a while: it may be cached, or an existing connection may keep using its previous route. If there are many entries, filter by domain or process. Some clients show entries only while a connection is active, so a record disappearing after the page loads isn’t necessarily a problem.

Find the request you just made and check its matched rule and policy chain. Ideally, the domain matches the expected rule, and the policy chain ends at the node or proxy route you selected in step two. Seeing the request in the list only confirms that traffic reached the core. If its final policy is DIRECT, it’s still a direct connection. If the client doesn’t show the full chain, check the Rules page and use an appropriate log level. There’s no need to leave verbose debug logging enabled for a basic check.

Next, visit a familiar service you expect to connect directly and check its record the same way. This tests traffic routing; it isn’t a comparison of the two sites’ loading speeds. Your rules may send some direct connections through the core, so an entry in the Connections list doesn’t mean the traffic went through a remote proxy. Likewise, a site loading in your browser doesn’t prove the proxy works: the site may be reachable directly.

To check your outbound IP, you can use a reputable public IP lookup service and compare the results before and after connecting under the same network conditions. First check whether the lookup domain itself is routed through the proxy by your rules. Its result shows the route for that request only—not necessarily for other apps, domains, or address families. A changed result can be useful supporting evidence, but use the rule and policy for the specific request to diagnose traffic routing.

If a page won’t load, work back through the four steps. If there’s no matching request on the Connections page, check whether the app follows the system proxy, is excluded, or is being routed by another tool. If the request appears but ends at a direct policy, check the policy group and rules. If it matches a proxy but fails to connect, check the node and service status. If you see a certificate error, don’t bypass the browser warning or install an untrusted root certificate. Use the Troubleshooting FAQ to check your system time, network, and error details.

Once the connection works, do one brief stability check: close and reopen a browser page and confirm it still matches the expected policy. On mobile, check that the connection stays active during normal use. If you switch from Wi-Fi to mobile data, treat it as a new network and verify again—UDP availability, DNS, and system connection state may differ. A single speed test or successfully loaded page doesn’t replace testing your actual use cases.

Finally, learn how to disconnect. On desktop, turn off the system proxy to pause proxying, then quit the client if needed. If you use TUN, make sure it has stopped too. On mobile, tap Disconnect and confirm the status in system VPN settings. If your browser can’t connect after you quit, check whether a manual proxy setting still points to a local port; don’t delete all your configuration. Note which profile and main policy are working so you won’t need to import everything again next time.