Clash Setup Guide
Import a Subscription and Verify the Connection
Set up Clash in this order: import a subscription → choose a proxy mode → connect → verify. If you already have a client and a valid subscription, follow this roughly 10-minute checklist. Network or subscription issues require separate troubleshooting.
Before you begin, get the subscription link from your configuration provider, or a local YAML configuration supported by your current core. The client reads the configuration and handles traffic; installing it alone does not provide a working proxy. Subscription links often contain credentials, so paste them only into a trusted client. Before sharing screenshots, asking for help, or posting logs, remove URL parameters and other sensitive information.
Step 1: Import a Subscription and Enable the Configuration
Open the client and go to “Profiles” or “Subscriptions.” Desktop clients usually have a field for the subscription URL; you may need to click “New” or “Import” first. On mobile, tap the plus icon, usually in the top-right corner. Choose URL or remote configuration, paste the full subscription link, then tap “Import” or “Save.” If there's a name field, enter a label that helps you identify the configuration. The label is for your reference and doesn't change the subscription.
Make sure there are no extra spaces, line breaks, or punctuation added by a messaging app before or after the link. Use an address your provider explicitly identifies as compatible with Clash or mihomo—not an account homepage, purchase page, or subscription management page. Some providers offer a dedicated subscription link on your account page; the URL in your browser's address bar is not a substitute. Don't rely on the link's file extension to identify its format either: the server may generate the subscription response dynamically.
Wait for the download and parsing to finish. On success, a new item appears in the configuration list; the client may show an update status or a refresh button. Select the configuration card, or choose “Enable” or “Set as current,” and confirm the current indicator has changed. Some clients select an imported configuration automatically, while others only save it. If you import without enabling it, the Proxy page may still show policy groups from the previous configuration.
Importing a Local YAML File
If you received a file, choose “Import from file,” select the YAML file saved on your device, and set it as the current configuration. On mobile, this may open the system file picker; find the folder where the file is actually saved rather than selecting a screenshot or chat message. A regular local configuration imported offline won't automatically have a remote subscription URL. Whether it can be updated later depends on its resource references and the client's management features.
If parsing fails during import, first check the format provided. A Base64 node list, a single proxy link, and a complete Clash configuration are different things and aren't interchangeable by default. Ask for a compatible format, and don't submit a subscription containing credentials to an unfamiliar service just to convert it. For more on the differences, see the glossary. For now, continue with a configuration that loads successfully.
Step 2: Choose Rule Mode and a Proxy Policy
Once the configuration is enabled, open the “Proxies” page and find the “Rule,” “Global,” and “Direct” modes. For your first setup, choose “Rule.” This mode uses the rules in the current configuration to decide where connections go: some connect directly, while others are sent to a specified policy group. The same mode name doesn't guarantee identical behavior across configurations; the loaded rules and policy groups determine how traffic is routed.
Next, check the policy groups on the page. Group names come from the configuration and may be organized by purpose or region, so they don't have to match the names in this guide. Find the selection group that handles the main proxy exit, expand its options, and choose a proxy your provider confirms is available. If there's an “Auto Select” policy, you can use it, but make sure it includes candidate proxies rather than being empty. Changes usually take effect immediately; there's no need to reimport the entire subscription.
Keep in mind that a policy group can reference other policy groups. Choosing an automatic policy in an outer group doesn't necessarily fix the final exit; the actual proxy depends on the inner selection or automatic test results. If the page shows DIRECT, that policy connects directly—it doesn't mean the proxy connection succeeded. Check where the main policy group points, then verify the actual route in the connection logs. That's more reliable than looking at a single latency number.
Rule, Global, and Direct Modes
| Mode | How intercepted requests are handled | When to use it in this guide |
|---|---|---|
| Rule | Routes requests according to the matching rules in the configuration. | The recommended starting point for initial setup and everyday use. |
| Global | Routes traffic through the global policy instead of matching the usual rule list. | Use briefly if needed to check whether a rule selection is causing the problem. |
| Direct | Connects kernel-handled requests directly to their destinations. | Useful for comparison, but it doesn't disable system traffic interception. |
Proxy mode only affects requests already sent to the core; it doesn't automatically route every app through the proxy. On desktop, in particular, selecting “Rule” isn't enough—you also need to configure the system proxy in the next step. Global mode doesn't mean every device's traffic is intercepted either; apps that bypass the client may still connect directly. Keeping “whether a request reaches the core” separate from “which policy handles it” makes troubleshooting much clearer.
For now, keep the subscription's existing DNS, rules, and port settings. Don't add complex overrides or switch to Fake-IP at the same time. Verify the basic connection first, then make changes as needed. For details on rule order, policy group types, and configuration syntax, see the complete guide.
Step 3: Enable the System Proxy or Connect on Mobile
Your configuration and policy are set. Now route app requests through the client. Return to the home screen or status page and make sure the core is running without repeated shutdowns, configuration load errors, or port conflict warnings. Some clients start the core when the app opens; others require you to tap “Start.” Check the status page and logs. Choose one interception method for your device, and don't enable multiple methods during initial setup.
Windows and macOS: Start with the System Proxy
On the client's home or settings page, enable “System Proxy.” This usually points the system proxy address to the local core's listening port, routing requests from browsers and apps that follow system proxy settings. After enabling it, return to your browser and reopen the page. Existing long-lived connections may keep using their previous route, so refreshing a page that's already playing may not reflect the change.
If the client reports that a port is in use, first check whether another proxy client is running or you previously set a system proxy manually. Temporarily quit other proxy clients and try again; don't force-quit unfamiliar system processes. If you need to change the port, make sure the client's listening port matches the one in the system proxy settings. This guide doesn't require changing it to a specific number. Apps with their own proxy settings also need to be checked separately.
Android and iOS: Authorize the System Connection
Tap “Start” or “Connect” on the client's home screen. The first time, a system prompt will usually ask you to approve a VPN connection or add a VPN configuration. Review the request and allow it; some devices may also ask for your unlock credentials. Return to the client, confirm the connection is active, and check for the VPN indicator in the system network status. This authorization creates a local traffic interception tunnel; the indicator alone doesn't confirm that the remote proxy is working.
If the device is already connected to another VPN, disconnect it before starting this client. Android app routing settings may allow only selected apps through the tunnel, so make sure your test browser is included. If the mobile client disconnects as soon as it starts, first check that authorization is complete and the configuration loads, then check system background restrictions. Avoid changing every battery management and network setting as a first step.
Linux and TUN: What to Consider
Linux desktop environments vary in their support for system proxy settings. If the client doesn't update your desktop settings automatically, configure the proxy in the desktop network settings using the actual listening address and port shown by the client. Terminal apps may also require proxy environment variables. Don't assume that because a browser works, the entire system is routed through the proxy. Start by testing the app you plan to use.
TUN is a separate interception method that may require installing a service, administrator permissions, and changes to routing and DNS. For a first setup, start with the system proxy. Consider TUN only if you need to cover apps that ignore system proxy settings. Don't enable TUN, Global mode, and DNS overrides all at once just because one app doesn't behave as expected; it will be hard to tell which change made a difference. For more, see troubleshooting.
Step 4: Verify the Connection in the Logs
Leave the client running, open a site you intend to access through the proxy in your browser, and open the client's “Connections” page. Start a fresh request in a new tab to avoid mistaking cached content for a live connection. Find the entry for the site's domain or destination address, then check its matched rule, policy group, and actual proxy chain. Field names vary by client, but the key is to confirm that the request reached the core and see which exit handled it.
The basic proxy test is successful if the log shows the expected rule and the proxy you selected, and the page loads. Then visit a site that should connect directly according to your configuration and check whether it uses DIRECT. Direct connections are normal in Rule mode and don't mean the proxy is off. Testing both proxied and direct traffic confirms that routing rules work, not just that one page opens.
You can also use a trusted public IP lookup page as a reference and compare the exit address with traffic interception on and off. But a browser's exit address only shows the route for that request; it doesn't mean every app uses the same proxy or prove that DNS is behaving as expected. For detailed DNS interception and leak tests, see the DNS section of the complete guide. For now, focus on verifying the connection path.
What to Check If It Doesn't Work
If a page won't load, first check whether the request appears in the connection list. If there's no entry, check that the system proxy is enabled, the mobile connection is still active, and the browser isn't excluded by app routing. If the request appears but goes direct, check the current mode, matched rule, and policy group selection. If it uses a proxy but reports a connection error, check proxy availability, subscription status, and your local network. This order helps separate interception, routing, and proxy exit issues.
Some clients offer a “Latency Test” or “Connectivity Test” to help shortlist proxies, but the test target differs from the site you're actually trying to reach. A successful test doesn't guarantee access to every site, and a failed one should be considered alongside the error in the logs. To compare proxies, use the same test site and mode, changing only one option at a time. For help interpreting results, see proxy latency questions.
Finally, check what happens when you disconnect. After testing, turn off the system proxy or mobile connection, then quit the client normally and confirm that sites which should connect directly still load. If the network misbehaves after you close the desktop client, check for a system proxy setting that still points to localhost. On mobile, confirm the VPN has disconnected. Don't leave apps pointed at a local proxy port after the core has stopped.
Ongoing Updates: Maintain Subscriptions, Rules, and Clients Separately
Once the basic connection works, return to “Profiles” or “Subscriptions,” manually update the current remote configuration, and confirm the URL is still valid. If the client supports automatic updates, set a sensible interval in the configuration's edit screen and check the units: the interface may use minutes, while resource fields in the configuration may use seconds. Don't copy the same number between them. Whether updates run while the app is closed depends on whether the client keeps running in the background.
Refreshing a remote subscription may replace configuration content you edited directly. For rules or settings you need to keep, learn how the client handles overrides, merges, or extensions instead of repeatedly editing the downloaded file after each update. Rule resources may have their own update schedule, so refreshing a subscription doesn't necessarily refresh every resource. Core and client upgrades are a separate update path that handles software capabilities and compatibility.
Keep a verified working setup as a baseline and change one thing at a time. If something breaks, use the connection logs to see what changed. To learn about rule order, TUN, DNS, or persistent overrides, continue with the complete guide, from beginner to advanced. For specific errors, use troubleshooting; for unfamiliar fields and terms, see the glossary. There's no need to change every setting during initial setup.