Subscription · Mode · Connection · Verification

Clash First-Time Setup

If you’ve installed the client and have a subscription URL ready, follow these four steps to complete the initial setup. It usually takes about ten minutes. First, make sure the profile loads; then choose how traffic should be routed; finally, enable traffic handling and check the results. Avoid changing DNS, TUN, and routing options all at once—you’ll have a harder time identifying the cause if something goes wrong.

If you haven’t installed a client yet, choose one for your platform on the download page. You’ll also need a subscription URL from a trusted source that’s compatible with the client’s core, or a complete local configuration file. The client loads the profile and handles connections, but installing it doesn’t provide proxy service by itself. Check with your subscription provider to confirm the subscription is valid and hasn’t expired.

For your first setup, temporarily close other proxy clients and disconnect other VPNs. Keep one local network connection that can access regular websites. Subscription URLs may contain account credentials, so don’t share them in public chats, screenshots, or online conversion tools. Paste the URL only into the client’s subscription section; there’s no need to share any of its parameters.

Step 1: Import a Subscription

Open the client and go to “Profiles” or “Subscriptions.” Look for “Add,” “Import,” or a plus button. If your provider gave you a subscription URL, choose a remote profile or import from URL—not a local file. Paste the full URL, optionally give the profile an easy-to-recognize name, then select Import or Download. The name is for your reference and won’t change the subscription.

Check that the URL has no spaces, line breaks, or trailing punctuation before and after pasting. Use an option your provider specifically identifies as compatible with Clash or your current core. Don’t use an account page, payment page, or plain-text node share as a complete subscription. A URL opening in a browser doesn’t necessarily mean it returns a valid profile; the client must be able to parse its proxies, policy groups, rules, and other settings.

Once the download finishes, the new profile should appear in the list. Select it or choose “Enable” or “Set as current” to load it into the core. Importing a profile and switching to it are two separate steps. If the previous empty profile is still active, the Proxies page may have no groups to use. Return to the list, confirm the new profile is selected, and check for any loading errors.

Next, open the Proxies page. If the profile’s policy groups are visible and there are no obvious parsing errors, you’re ready to continue. You don’t need to rewrite the subscription’s rules or delete unfamiliar groups to tidy up the page. Rules may refer to those groups, so removing them can prevent the profile from loading or send some traffic through an unintended route.

Local Profiles and the First Update

If you have a local YAML file, choose “Import from file,” select the configuration on your device, and enable it. On a phone, you may need to save the file locally or to the system’s Files app first. Don’t try to convert formats by changing a file extension, and don’t treat a short snippet with only a few proxy settings as a complete profile. Check the client’s loading result to see whether the file can run as is.

After enabling a remote profile, run “Update subscription” once to confirm the client can fetch it again. A successful update confirms that the profile was retrieved; it doesn’t guarantee that every node is usable. Local files usually don’t have a remote update URL, so you’ll need to import the revised file again. Set an automatic update interval after your first successful connection to avoid confusing update problems with connection problems.

Before moving on, confirm two things: the profile list shows an active profile, and the Proxies page displays its policy groups. Next, choose a proxy mode and a node to use.

Step 2: Choose a Proxy Mode

Return to the home or settings page and find “Proxy Mode.” For your first setup, choose “Rule.” Rule mode matches requests against the rules in your profile, then routes them to a direct connection, a proxy group, or a reject policy. It doesn’t send every website through the same node, so different results for different sites may be exactly what the profile is designed to do.

“Global” generally sends connections already handled by the core through the global policy. It can be useful for troubleshooting comparisons, but it doesn’t route every app through the core by itself; traffic handling still depends on an entry point such as the system proxy or TUN. “Direct” sends handled connections straight to their destinations. Keep Rule mode for your first connection rather than switching modes repeatedly instead of checking what’s happening.

Proxy Modes for Your First Setup
Mode How It Handles Connections Recommended for This Setup
Rule Routes traffic according to the profile’s rules Use this as your starting point
Global Applies the global policy to handled connections Use when comparing routes during troubleshooting
Direct Sends handled connections directly to their destinations Use to understand or compare the direct route

Choose an Available Node in a Policy Group

Once you’ve chosen a mode, open the Proxies page and find the main policy group for general proxy traffic, using the profile’s descriptions as a guide. Group names depend on the subscription provider, so don’t look for one specific label. Expand the group: if it’s a manual selection group, choose a node. If it points to another policy group, continue down the chain until you can tell which node will handle the connection.

If the profile includes an automatic selection or failover group, leave its policy intact; you don’t need to set every group to the same option. Groups for specific regions or uses may control some sites separately, so choosing a main proxy group won’t necessarily affect every rule. For your first setup, change only the main node you need and leave the rest at their subscription defaults to avoid mistakes.

If the client offers a latency test, run it once as a quick check that the node can reach the test address. A timeout could be caused by your local network, service status, or the test target; it doesn’t automatically mean the whole subscription is invalid. Lower latency doesn’t guarantee faster downloads either. Pick a node that passes the initial test, then verify it with a real website and the connection log.

Keep Rule mode selected and note which node the main policy group is using. There’s no need to change the rules, overrides, or core-specific settings now. For custom routing, see the cross-platform setup guide. The next step is to make sure your apps’ requests actually reach the client.

Step 3: Connect the Client

First, check that the client says its core is running. Some desktop clients start the core automatically; others require you to click “Start” or “Run.” If there’s an error, read it rather than relying on the tray icon to confirm the status. Once the core is running, enable traffic handling for your device.

Desktop: Enable the System Proxy First

Find “System Proxy” on the home or settings page and turn it on. The client will try to set the system proxy address to its local listening address, so browsers and apps that follow the system proxy send requests to the core. Keep the default listening port and TUN mode off for your first test, then open a new browser tab and visit a website you want to test.

A browser may ignore the system proxy if it has its own proxy extension, custom proxy address, or direct-connection rule. Disable those settings temporarily or switch the browser to use the system proxy. Command-line tools, games, and some apps may also ignore it, so one app connecting directly doesn’t prove the client is broken if the browser test works.

If the system proxy switches itself off or the client reports that the port is in use, quit other proxy tools and restart the current client. Don’t change the listening address to a local network address, and don’t enable “Allow LAN” just to browse on the same device. That option lets other devices use your proxy and isn’t needed for a first setup.

Mobile: Approve the System Connection

On mobile, tap “Start” or “Connect.” Your system may ask for permission to add a VPN configuration or establish a VPN connection. Confirm that the request comes from the client you just installed, then approve it and complete any device authentication the system requires. The VPN interface is how the system routes traffic through the client; you don’t need to install a separate VPN app.

After granting permission, return to the client and confirm its status shows that it’s running. Check for a connection indicator in the system as well. If another VPN is active, the system may ask you to replace or disconnect it. Decide which connection to keep so the apps don’t compete. Keep the client in the foreground during testing to avoid interference from background restrictions.

Don’t treat “Running” as the finish line. It only means the client has started or set up a traffic-handling entry point. You still need to confirm that the node works and traffic is routed as expected in the final step.

Step 4: Verify the Proxy Works

Open a new browser tab and visit a site you use regularly that should go through the proxy according to your profile. Refresh the page or open a new path instead of relying on an old cached page. If it loads, open the client’s “Connections” or “Logs” page and find the request for that domain. Check which rule matched and which node handled it.

If the connection log shows a direct connection, first check whether that domain is supposed to bypass the proxy. Rule mode allows direct and proxied traffic side by side; not every request will use a proxy node. If the log shows a proxy policy group, check that its selected node matches your choice in Step 2. Some clients show the full policy chain; others show only the final node. Check the details in your client.

You can also open a trusted public IP lookup site in your browser and compare the results with the proxy on and off. However, the lookup site is subject to your rules too: if it matches a direct rule, seeing your local network’s IP is normal. Two proxy nodes may also share the same public IP, so switching between them may not change the result. Check IP results alongside rule matches and connection logs rather than treating them as the only evidence.

Choose Your Next Step Based on What You See

If there’s no connection log entry for the request, first check whether it reached the core. Make sure the system proxy is still on, the browser has no separate proxy settings, and you’re viewing the active client’s connection page. On mobile, confirm the system connection is still running. Don’t keep switching nodes before traffic reaches the core; it won’t fix a problem with the traffic entry point.

If a connection is logged but times out or fails, focus on node reachability, subscription validity, and service status. Try another node in the same policy group, then repeat the request to the same site. If only certain domains fail, check whether a reject rule matched or DNS resolution is failing. See the Help Center for a detailed troubleshooting sequence; there’s no need to change all your network settings during the initial setup.

After verifying the website, turn off the system proxy or tap Stop on mobile, then visit a site that normally works without a proxy. On desktop, turn off the system proxy before quitting the client. Otherwise, the proxy address may remain configured after the local service stops, preventing your browser from connecting. If access is still affected, first check that the system proxy settings have been restored before looking for other causes.

Turn the connection back on and confirm the settings still work. Your first setup is complete once you can reliably repeat the cycle: connect, browse, check the log, and disconnect. You can set up automatic subscription updates and launch at startup later. For platform-specific startup options, see configure launch at startup; there’s no need to do it during this test.