Clash Setup Guide

BEFORE YOU START

Before You Begin: Client and Subscription

First, get a client for your operating system and a valid subscription URL from your service provider. The client loads the configuration, runs the core, and routes traffic; the subscription provides nodes and related settings. Installing a client does not create working proxy nodes, and the download pages on this site do not provide personal subscriptions. If you already have a subscription, check with your provider that it is still valid and has traffic remaining, then copy the full URL.

For your first setup, temporarily quit other proxy clients and disable browser extensions that set a proxy manually. This helps prevent competing settings from overriding each other. If your computer uses a work VPN or corporate network management software, don't change its routes or DNS settings without checking your network requirements first. If you plan to keep an older client, stop its connection before starting the new one; there's no need to delete the old configuration just to switch.

Haven't chosen an installer yet? Visit the client downloads page and select your platform. Platform-specific details such as permissions, system architecture, service mode, and virtual network adapters are covered in the guide for all platforms. This walkthrough starts with the client open and covers only the steps needed to establish a working connection.

STEP 01 / SUBSCRIPTION

Import a Subscription and Activate the Configuration

Open the client and find “Subscription” or “Configuration” in the sidebar. Look for “Add,” “Import,” or a plus button. Choose the option to import from a URL and paste the full address from your service provider. Some clients have a URL field at the top of the page; enter the address and click “Import.” The name field is just for identifying the configuration, so choose any useful label—it won't affect how you connect.

Before importing, check the start and end of the URL to make sure you haven't copied instructions, line breaks, or extra spaces. Subscription URLs often contain access credentials. Don't post one in a public comment or include the full link in troubleshooting screenshots. If your provider offers formats for multiple clients, choose one compatible with your client or core—not the URL for your account dashboard.

After starting the import, wait for the client to download and parse the configuration. When it finishes, you should see a new configuration entry, an update time, or node details. A new entry does not mean the configuration is active. Select it, or choose “Use” or “Activate” from its menu, and make sure it is marked as the current configuration. Then open the “Proxies” page and check for policy groups. If you still see the old configuration, go back and check which one is active.

If you received a local .yaml or .yml file, choose “Import from file” on the same page, select the file, and activate it. Renaming a regular web page or error message with a configuration file extension won't make it a valid configuration. Local configurations usually don't update automatically; future updates depend on remote resources in the configuration and the client's settings. A local file is not a drop-in replacement for a subscription URL.

Import Failed? First Identify Where It Failed

If you see a timeout, authentication failure, or parsing error, check the error message for that entry first, then look at the matching timestamp in the “Logs” page. Authentication failures are often caused by an expired subscription URL, changed credentials, or an account issue. A parsing error may mean the server returned a web page, the subscription format is incompatible, or the file has invalid syntax. Don't keep clicking Import and creating duplicate entries, and don't reinstall the client right away.

Some networks can't reach subscription servers directly. If your client lets you choose a direct or proxied connection for subscription updates, follow your provider's instructions. Without an existing working connection, you can't use a configuration you haven't imported yet as the route for downloading it. Once the import issue is resolved, keep one clearly active configuration and then choose an operating mode.

STEP 02 / ROUTING

Choose Rule Mode and a Proxy Policy

Find the operating mode on the home, proxy, or settings page. For a first setup, choose “Rule,” shown as Rule in English-language clients. Rule mode uses the rules in your active configuration to decide whether each request connects directly or through a proxy. It determines how traffic is routed; it does not send browser traffic to the core. You'll enable the traffic entry point in the next step.

“Global” mode usually sends regular connections that reach the core through the global policy. It does not mean every app on your device is being routed through the core. “Direct” mode sends regular connections that reach the core straight to their destinations. For an initial setup, don't leave Global on indefinitely or switch to it as a catch-all fix for access problems; doing so can hide mistakes in your rules or policy group selection.

Next, open the “Proxies” page and find the main policy group defined by your configuration. Its name comes from the subscription and may be “Proxy Selection” or something else, so don't infer its purpose from the name alone. Expand the group and choose an available node or an automatic group provided by the subscription. Check for nested groups: the main group may point to another group, with the actual egress node one level deeper.

If the page has a “Test” or “Connectivity” button, or a speed-test icon, run one test. The result only shows whether the node can reach the test URL configured by the client; it doesn't prove that every site will work and isn't a bandwidth test. If it times out, try another node for comparison. Don't assume the lowest number is the best choice for every app—judge by how the specific requests you need actually perform.

After making a selection, confirm that the selected indicator in the policy group has changed. For a request that should use a proxy, check that its group isn't set to DIRECT, which means the request connects directly. You can keep automatic groups such as url-test and fallback at their subscription defaults for now; there's no need to change their test interval or tolerance. Learn more in Proxy Group Types Explained.

STEP 03 / TRAFFIC ENTRY

Start the Core and Connect

Return to the client home page and make sure the core is running and the active configuration loaded without errors. Some clients start the core automatically; others require you to click “Start” or a connect button. If the logs show a configuration load error, go back and fix it rather than repeatedly toggling the system proxy. Apps can only send requests to a proxy port once the core is listening.

Desktop: Test Your Browser with the System Proxy

Turn on “System Proxy” in the client and wait for its status to show that it is enabled. This points your system proxy settings to the client's local listening address and works for apps that follow those settings. A browser with its own proxy settings or a proxy extension may ignore the system settings, so for your first test, make sure the browser is set to follow the system proxy.

There's no need to change ports for your first connection. The listening port shown in the client is the one currently in use; common port numbers mentioned in guides are not fixed requirements. If the logs report that a port is already in use, check whether another proxy process is still running. If you need to change the port, do so in the client settings and confirm that the system proxy setting updates too. When configuring another app manually, use the actual port shown after the change.

Mobile: Approve the System VPN Request

Tap the connect button on the client home page. The first time you connect, the system will usually ask permission to add a VPN configuration or establish a VPN connection. Allow it after confirming the request came from the client you just opened, then unlock or authenticate as required. Return to the client and wait for its status to change. A VPN icon in the status bar only means a tunnel is active; it doesn't confirm that the node and rules are correct. Verify those in the next step.

If another VPN is already active, disconnect it before starting this client. Switching back and forth between two VPN apps can cause one to replace the other's connection. Mobile background restrictions can also interrupt a connection. Adjust battery or background activity settings in the platform guide only if the connection works in the foreground but drops in the background.

TUN: Enable It Only If You Need It

Consider TUN mode only when an app doesn't follow system proxy settings. TUN uses a virtual network adapter and routing settings to capture traffic, and may require administrator access, service mode, or additional driver support. Clients handle how TUN interacts with the system proxy differently. For initial troubleshooting, keep to one clear traffic-routing path, and never enable TUN in multiple clients at the same time.

If your browser works through the system proxy but a specific app still doesn't, check the TUN settings for your operating system in the guide for all platforms. If enabling TUN disrupts local network services or your work network, turn it off to compare. Don't change routes, DNS, and rules at the same time. Make one change at a time so you can tell what affected the result.

STEP 04 / CHECK THE RESULT

Verify Access, Matched Rules, and Egress

Keep the client running and open a known-accessible HTTPS page in your browser, preferably a destination that your configuration is set to proxy. Make a new request rather than relying on a page that's already open; open a new tab or reload the resource if needed. Cached pages, existing downloads, and reused connections can make it look as though nothing has changed.

At the same time, open the client's “Connections” page and check whether the new request appears. Find the request and inspect its domain, matched rule, policy group, and actual egress. Fields vary by client, but at minimum confirm that the request reached the core and whether its final route uses a node or DIRECT. If the test domain appears under the expected policy group and the page loads, the first round of proxy-path verification is complete.

Next, visit a site that your configuration is expected to connect to directly and check that its connection entry shows a direct route. In Rule mode, different destinations using different egress paths is normal. Don't assume the proxy isn't working just because a local service still shows its usual IP address. An IP lookup page only reflects the route used for that page's request; by itself, it can't prove that all traffic on the device uses the same egress.

No Connection Entries? Check the Traffic Entry Point

If new requests never appear in the connection list, first check that connection logging isn't paused and that the browser actually sent a network request. Then check whether the system proxy is enabled, whether the browser follows system settings, and whether the mobile VPN is still connected. If only one app has no entries, check whether it bypasses the system proxy. Don't switch through a long list of nodes before confirming that traffic reaches the core.

Entries Appear but Pages Won't Load? Trace the Actual Route

If an entry appears but the request fails, first check whether its egress matches what you expect, then inspect the logs for the same time. If the wrong policy group is selected, correct it. If a node times out, try another and compare. If only one domain fails, check whether the destination service is available. Diagnose DNS errors using the actual logs; a page failing to load alone isn't a reason to disable Fake-IP or replace all your DNS settings.

Finish with a controlled comparison. If it won't disrupt other tasks, turn off the system proxy or VPN you just enabled and retry the same request as a new connection. Then reconnect and try again. Compare the page result and connection entries rather than relying on the button color. In troubleshooting screenshots, include the error time, destination, and error type, but hide subscription URLs, access credentials, and personal information.

DAILY USE

Disconnect and Everyday Use

Once setup is verified, everyday use only requires an active configuration, Rule mode, and a confirmed working traffic entry point. Subscription updates can change available nodes or policy groups. If something stops working after an update, first check whether your selected node was removed, then choose another. Starting the client at login doesn't necessarily mean traffic routing will resume automatically; check client startup separately from system proxy and connection-recovery settings.

To stop proxying, first disable the system proxy or TUN, or disconnect on mobile, then quit the client normally. Some clients restore system settings on exit, but don't assume they all behave the same way. If your browser can't connect after the client has closed, check whether the system is still pointing to a local proxy that is no longer running. Restore automatic or previous network settings, then test again.

At this point, the setup should work end to end: the configuration is active, the policy group has a clear egress, the traffic entry point is in the expected state, and connection logs explain where requests went. For custom rules, DNS and Fake-IP, service permissions, or platform-specific issues, continue with the installation and configuration guide for all platforms. For differences between clients, see the client comparison. There's no need to configure every advanced option before your first connection.