Clash Setup Guide
Import a Subscription and Test Your Connection

Follow this order: import a configuration → choose a mode → connect → verify traffic. First establish a connection you can test, then adjust DNS, TUN, and custom rules.

Before you begin, get a subscription link that supports your current core, or a working local YAML configuration. The client reads the configuration, runs the core, and routes system traffic; installing the client does not provide proxy nodes. The subscription provider determines its validity period, node availability, and configuration access. Temporarily close other proxy clients and VPNs, but keep your regular internet connection available to avoid competing traffic entries.

Change one setting at a time. Each step should produce a result you can observe. If the result isn’t what you expect, stop and troubleshoot that step rather than toggling settings at random. The steps below are designed to get your first connection working. Save configuration syntax and networking details for later.

01 Import a Subscription or Local Configuration

Launch the client and open Configuration or Subscription from the sidebar or bottom navigation. An empty list is normal the first time you open it. Look for New, Add, or a plus button, then choose the option to import from a URL. Paste the full subscription link from your provider, give the configuration a recognizable local name, and select Save, Download, or Import. The name only identifies the local entry; it doesn’t change the nodes in the link.

Before pasting, check that the link has no leading or trailing spaces, line breaks, or punctuation added by a messaging app. Use a subscription labeled for Clash or compatible with your current core—not an account login page, order page, or regular webpage. Subscription links often contain access credentials, so don’t post the full URL in public comments, screenshots, or online conversion tools. If you need help, hide the URL parameters and personal information first.

Wait for Parsing to Finish, Then Activate the Configuration

The client usually downloads the remote content first, then checks the YAML structure. When the import succeeds, a new entry should appear in the configuration list. If it isn’t activated automatically, select that entry and choose Use, Enable, or the equivalent option. Then open Proxies and check for the policy groups defined in the configuration. Seeing a name in the list alone doesn’t prove that the core loaded the configuration; make sure the groups display correctly and the logs aren’t showing repeated errors.

To import a local file, choose Import from File on the same page and select the saved .yaml or .yml file. On a phone, save the file to the system file manager first, then open it with the file picker. Whether you can import from the share menu depends on the client. The imported configuration may be a copy, so changes to the original file might not carry over. Re-import it or edit the local configuration in the client instead.

If Import Fails, Troubleshoot This Step First

If the download times out, check that your regular internet connection works, then confirm the subscription hasn’t expired and the provider’s service is available. If parsing fails, make sure you downloaded configuration content—not a login prompt or webpage—and check whether the configuration uses fields unsupported by your core. Don’t delete unfamiliar keys at random: a configuration that saves successfully may still be incomplete.

For your first import, don’t rely on a proxy connection that isn’t set up yet. If your local network can’t reach the subscription URL, use an alternate URL explicitly provided by your provider, or obtain the local configuration on a trusted device and import it. For format differences, see the terms guide’s notes on configurations and subscriptions. For further help with failed updates, see the subscription update troubleshooting checklist. Keep the imported configuration active and move on to choosing an outbound route.

02 Choose a Proxy Mode and Outbound Node

Open Overview or Proxies and find Outbound Mode or Mode. For your first setup, choose Rule, usually represented by the core configuration value rule. This mode applies the configuration’s rules in order to choose a direct connection, proxy policy group, or other action for each connection. It doesn’t send every request through the same node, so seeing DIRECT for some connections doesn’t mean the proxy has failed.

Global mode typically sends regular outbound connections to a global policy group. It can help test node connectivity or provide a single outbound route when needed, but only for traffic that reaches the core. Direct mode favors direct connections and cannot confirm that proxy nodes are working. For everyday rule-based routing, start with Rule mode and consider other modes only after testing the connection.

Choose an Outbound in the Policy Group, Too

Open Proxies and expand the main proxy policy group. Its name comes from the configuration and might be Proxy, Node Selection, or something more specific; check the configuration or group options rather than guessing from the name. In a manual selection group, choose a currently available node and make sure it’s marked as selected. If the group refers to another group, expand that one too and confirm the final outbound isn’t set to Direct or Reject by mistake.

If the configuration includes an automatic selection group, you can keep its default policy to start. Just note that automatic selection uses the configured test target and doesn’t guarantee access to every website. Client-side Test or Latency Test options can help rule out obviously unreachable nodes. A failed test could also be caused by the test URL or network restrictions, so don’t judge every connection by a single test result.

Keep the Subscription Rules; Avoid Changes That Cancel Each Other Out

You don’t need to rewrite rules or manually change every purpose-specific group during first-time setup. First make sure the main proxy group has a working outbound, then check that frequently used app groups refer to the expected policy. Group selections usually affect new connections only; existing long-lived connections may keep using the old outbound. After switching, test with a new request instead of relying on a page that’s already playing or loading.

Don’t edit the same rules in both the subscription configuration and the client’s override settings. Clients merge these settings differently, and options shown in the interface may not edit the original YAML directly. For policy groups, DIRECT, and rule matching, see rules and traffic routing. For custom group types, rule providers, and overrides, see the Advanced configuration guide. By the end of this step, you should know the current mode, the main proxy group, and its selected outbound.

03 Enable the Connection and Traffic Entry

Once you’ve chosen a configuration and node, return to Overview. If the client has a separate Start Core button, start the core first and wait for it to stabilize before routing traffic. Some clients start the core automatically; others use Connect as a single entry point. The distinction matters: a running core can handle requests, but traffic only has a chance to use the proxy once the system or app routes it to the core.

Desktop: Enable the System Proxy First

On Windows, macOS, or a Linux desktop environment that supports proxy settings, start by enabling the client’s System Proxy. You usually don’t need to enter a local address and port manually; the client sets the system proxy using its own listener settings. For your first connection, leave TUN off and don’t enable LAN access. The goal is simply to route requests from your local browser through the imported configuration, with as few variables as possible.

After enabling it, open a new browser tab and make a request. If your browser has a proxy extension, switch it to follow the system proxy. If you’ve entered a proxy address manually before, make sure it isn’t still pointing to another client’s port. Some Linux desktop environments and apps ignore the system proxy, so enabling the toggle doesn’t guarantee that every app is routed. Start by testing with a browser known to support system proxy settings.

Consider TUN only if you need to handle apps that don’t follow the system proxy. TUN may require a service component, administrator privileges, or route changes; read the current client’s prompts before enabling it. TUN isn’t another name for Global mode: TUN determines which traffic enters the core, while Rule or Global mode determines how that traffic is handled once inside. For details, see TUN and Fake-IP in the Advanced configuration guide.

Mobile: Allow the Current Client to Create a VPN

On Android and iOS, tapping Connect usually opens a system VPN permission prompt. Check that the app name matches the client you just installed, then allow it to add or establish a VPN connection. Return to the client and wait for its status to show Connected. The system status bar or settings page may also display a VPN icon. That icon confirms the tunnel is set up, but you’ll still need to test node connectivity and rule-based routing in the next step.

If your phone is already running another VPN, a VPN-based filter, or a work profile, check whether it’s competing for the system VPN connection. If the connection drops frequently after switching apps, check battery management, background permissions, or the client’s background operation guidance. Don’t change every system permission at once. Some clients also let you choose which apps use the VPN; an excluded browser won’t use the client, even if the connection status looks normal.

Keep the client running when you’re done; don’t quit it yet. You now have a configuration, an outbound selection, and a traffic entry. Next, test a real request instead of judging success by the color of a toggle.

04 Verify Rule Matching and Connection Results

Open a new browser tab and visit a working website that you expect to match a proxy rule. Don’t just refresh a cached page; cached content can still appear when the network is down. Then open the client’s Connections page and find the domain or destination you just visited. If search is available, filter by domain. Make sure the connection timestamp matches your test, then check the matched rule, policy chain, and final outbound.

A reliable test checks both sides: the browser completes a new request, and the client shows the expected route. If the rule points to a proxy group, the final outbound should be the node you selected—or the node actually selected within that group. If the rule points to a direct connection, DIRECT is the expected result. Don’t require every request to show a changed exit IP; Rule mode allows different destinations to use different routes.

Diagnose by Symptoms; Change One Setting at a Time

If the client doesn’t show the browser’s new connection at all, go back to Step 3 and check the traffic entry first: is the system proxy enabled, is a browser extension overriding it, is the mobile VPN still connected, and is the app excluded? Some connection records appear only briefly, so watch the logs while making the request. Confirm that traffic reaches the core before checking the node; troubleshooting in the opposite order can waste time.

If the connection appears but the page won’t load, check whether the final outbound is what you expect. If you chose the wrong group, go back to Step 2 and correct it. If the outbound is right but the request times out, try a known-working node and make a new request. If the logs specifically report a DNS resolution failure, review the DNS settings rather than pasting in an unfamiliar configuration. Destination domains, subscription URLs, and connection details in logs may be private; remove anything unnecessary before sharing them.

If only one app isn’t working, check whether it follows the system proxy, has its own proxy settings, or is reusing an old connection. A working browser doesn’t mean every app is routed. If you need broader coverage, configure TUN separately using the client’s documentation, then repeat the same verification steps. For deeper troubleshooting of rule priority, DNS, and routing, see Advanced usage; you don’t need to set everything up during your first connection.

After Connecting, Check Updates and How to Disconnect

Return to the configuration page and find the subscription’s update option. Confirm that it updates the configuration you’re currently using. Remote subscriptions can usually be refreshed manually or updated automatically, depending on the client; local files may not support remote updates. After updating, check that the configuration is still active and the main policy group selection is unchanged, then make a new request. For persistent local changes, use the client’s override feature so an update doesn’t overwrite edits to a remote subscription copy.

Finally, learn how to stop the connection. On desktop, turn off the system proxy before quitting the client. If you use TUN, disable that traffic entry too. On mobile, tap Disconnect and make sure the system VPN is no longer active. Close Window in the system tray may only hide the interface, not stop the core. If regular websites stop loading after you quit, check whether the system proxy still points to a local listening port that’s no longer running. Restore the original settings, then test again.

For an explanation of a field, start with the terms guide. To manage rule providers, merge subscriptions, or use an external control panel, see the Advanced configuration guide. Keeping everyday connection steps separate from configuration maintenance makes it easier to troubleshoot and return to a known-good setup.