First-time setup · 4 steps

How to Import a Clash Subscription
and Configure a Proxy

Start with a working subscription, then select a profile, configure rule-based routing, and verify the connection. Test with a browser first, then configure other apps if needed. Allow about 10 minutes to complete the main setup.

Before you begin, get a subscription URL from your service provider or a Clash- or mihomo-compatible YAML configuration file. A subscription is a URL used to fetch configuration; it’s not a client installer or a regular website login URL. The client reads the configuration, applies its rules, and establishes connections. Installing the software alone does not provide working proxy nodes.

After installing the client on your Mac, launch it from the Applications folder. If you’re using another proxy tool or VPN, disconnect it temporarily so you can tell which program is routing your traffic. Leave the default ports, DNS, and advanced settings unchanged; adjust only the settings covered in this guide. That makes it easier to return to a known working state if something goes wrong.

Step 1: Import a subscription and select a profile

Open the client and go to the “Subscriptions” or “Profiles” page. Look for “Add,” “Import,” or a plus button. If there are separate options for remote URLs and local files, choose the one that matches what you have: use remote import for a copied subscription URL, or local import for a .yaml or .yml file saved on your computer. Don’t paste the contents of a file into a URL field or rename a web page link to make it look like a YAML file.

For a remote subscription, return to your provider’s subscription page, choose a format explicitly labeled Clash or mihomo, and copy the full URL. After pasting it, check the beginning, end, and any parameters in the middle—especially everything after the question mark. Some pages list formats for several clients, and a regular node-sharing link may not work as a Clash configuration. If the page offers only a QR code, first check whether your client supports QR import instead of repeatedly trying the wrong option.

Give the profile an easy-to-recognize local name, such as “Everyday,” then import or save it. Wait for the request to finish, check whether the update succeeded, and look for configuration content such as proxy groups, rules, or nodes. Seeing a new name in the profile list only confirms that an entry was created. Make sure it parsed correctly and is selected as the active profile. Some clients mark the active item with a check; others require you to click “Use” or “Activate.”

To use a local file, choose the file import option and select the original YAML file. Wait for the client to parse it, then select the profile. YAML is a text-based configuration format where indentation defines structure; there’s no need to edit it for your first setup. If the client reports a syntax error, get a fresh copy of the original file. Avoid saving it with a rich-text editor, which may add unwanted characters. If the file references remote rules or proxy providers, it may still need network access on first load, so a successful file import doesn’t guarantee that all remote content has loaded.

If the import fails, first identify where the error occurs. A request timeout usually means you should check your network and whether the subscription URL is reachable. If the response is a web page or parsing fails, make sure you copied the subscription endpoint—not a login page, purchase page, or sharing instructions. An expired URL or a change in account status can also cause updates to fail. Copy the URL again from your provider’s page and retry once. Don’t change proxy ports, DNS, and rules all at once and hope for the best.

Subscription URLs may contain credentials that grant access to your account. Hide the full URL before sharing screenshots. Don’t post it in public comments or submit it to an online converter you don’t trust. To refresh your nodes later, use the current profile’s “Update” option; you usually don’t need to delete and recreate the profile each time.

Step 2: Choose rule mode and a proxy node

Once you’ve confirmed that the profile is enabled, open the Proxy page or find the mode selector. For your first setup, choose “Rule”; some interfaces label it “Rule” in English. Rule mode reads the matching conditions in the active profile and decides whether each connection uses a direct route, a proxy, or another policy. It preserves the profile’s everyday routing rules and makes it easier to see why a connection takes a particular route in the next step.

“Rule mode” and “selecting a node” are two different actions. The mode determines how connections are routed; proxy groups determine which exit to use for a given policy. Open the proxy groups and check whether they offer manually selectable nodes, an automatic selection group, or other subgroups. Group names come from the subscription and may not be called “Node Selection.” Find the group the profile uses for regular proxy traffic, then select an available option.

If a group has a manual test or latency test button, run it once to check whether the selected node can connect to the test destination. When the test finishes, click a node to select it and look for a selection indicator. Don’t leave after clicking the test button: testing and selecting are separate actions. Automatic selection groups usually choose an exit based on the profile’s test conditions. You can keep their defaults for your first setup; there’s no need to adjust the test interval or tolerance right away.

Global mode usually sends connections routed through the client to the global policy. Use it for a brief comparison if Rule mode doesn’t behave as expected; it won’t automatically make every app use the proxy. Direct mode usually sends routed connections straight to their destinations, so it can’t verify that proxy nodes work. If you switch to Global for a test, check which option the global policy actually selects rather than relying on the mode name to tell you the exit.

Keep the profile’s existing rules and proxy group relationships for now. Don’t change every option labeled DIRECT just to make one website use a proxy. DIRECT means a direct connection and may be an intentional route in the rules. You also don’t need to adjust separate policy groups for individual apps during your first connection. Get the main route working with a browser first, then configure routing for specific apps if needed.

Check the Proxy page again. It should show Rule mode, and the selection group referenced by the rules should have an option selected. If every node test fails, try another node and check the status of your subscription service; switching modes repeatedly won’t fix an unreachable node. For details on rule priority and nested proxy groups, see the installation guide. Leave the profile structure unchanged for now.

Step 3: Route traffic through the client

Once the profile and node are ready, enable traffic routing. On a Mac client, find “System Proxy” on the home page, in Settings, or in the menu bar. First confirm that the core is running without errors, then turn the system proxy on. The core is the background component that processes connections; an open client window doesn’t guarantee that the core is running properly. If the client reports a startup failure or a port conflict, fix that error before enabling more network features.

The system proxy updates macOS proxy settings so that apps which respect them send requests to the client’s local listening port. For your first test, use a browser because it’s easier to compare with the connection log. You don’t need to enter the same address manually in a browser proxy extension. If an extension has its own proxy configured, disable it or switch it to use system settings so the two configurations don’t conflict.

Leave the system proxy on, open a new browser tab, and visit a page. Don’t assume a connection is working just because the client’s switch is on, and don’t rush to enable TUN at the same time. The system proxy covers only apps that follow system settings. Some command-line tools, games, and apps with their own network stack may ignore it. If the browser works but a particular app doesn’t, check that app’s proxy support before assuming the entire profile has failed.

If you need to route traffic from more apps, consider TUN mode. TUN routes traffic through a virtual network interface and usually covers more apps than the system proxy, but results also depend on routes, exclusions, and DNS settings. A desktop client may require a helper service or service mode; follow the client’s prompts and check which app is named in the system authorization dialog before approving it. Don’t copy privileged commands from the web, and don’t change system routes just to get a browser working for the first time.

To test TUN, turn off the system proxy first, then enable TUN and test it on its own. This helps you identify which method is routing your traffic. If the client’s instructions require both, follow its current guidance. If your connection drops or DNS stops resolving, turn off TUN and return to the system proxy setup that worked before. Don’t keep stacking DNS, route, and firewall changes while your network is already having problems.

Windows users can follow the same sequence: confirm the core is running, enable the system proxy, then test in a browser. Check platform-specific instructions if a particular app doesn’t follow the setting. On Android and iOS, tapping Connect usually brings up a system VPN authorization prompt. Approve it, then return to the client and confirm the connection status. A VPN icon in the phone’s status bar means the routing tunnel is established, but it doesn’t prove that the selected proxy node is working.

During a connection, try to use just one tool to route traffic. A corporate VPN, security software, or another proxy client may change routes or DNS, making the same steps produce different results. Follow your organization’s policies if the device is managed. For details on helper services, permissions, and platform differences, see the platform setup guides.

Step 4: Verify that the proxy is working

First, open a page you know works on your current network to confirm that your basic connection is still available. Then visit a destination expected to use the proxy and check whether it loads. If the page was already open, use a new tab or reload it so cached content isn’t mistaken for a new network request. There’s no need to run a speed test right away; first confirm that the request followed the expected route.

At the same time, open the client’s “Connections,” “Activity,” or “Logs” page and find the entry for your latest visit. Available fields depend on the client and its log level, but you can usually compare the destination domain, matched rule, and proxy chain. If a request expected to use a proxy shows DIRECT, check the matched rule and proxy group. If it shows the selected proxy but still times out, check the node, destination, and upstream network instead of repeatedly toggling the system proxy.

Connection logs are more useful than checking your exit IP alone when you need to understand Rule mode. Different websites may match different rules, and an IP-check page may be set to use a direct connection. So a local exit shown by one check doesn’t necessarily mean the proxy is broken. If you need to compare exit IPs, test the same destination using the same routing method, and confirm that the request actually matched a proxy policy. Before sharing logs, hide subscription URLs, credentials, and any browsing records that aren’t relevant.

If the browser can’t load the destination, troubleshoot in this order: confirm the current profile is selected, check the selected option in the proxy group, then check that the core is running and that the system proxy or TUN is enabled. Next, try a different node, make the request again, and check the new log entry. Change one thing at a time and note the result. Changing the profile, mode, node, and DNS all at once makes it impossible to tell what caused the change.

If the browser works but a command-line tool or another app doesn’t, focus on that app. Check whether it supports the system proxy, has its own proxy configured, or needs a restart to pick up the new settings. Existing long-lived connections may keep using their old route, so reconnect after switching nodes. For command-line proxy settings, app exclusions, or TUN DNS issues, see the troubleshooting guide. You don’t need to repeat the entire first-time setup.

Finish by checking that your network recovers when you exit. Turn off the system proxy or TUN before quitting the client, then open a regular webpage to confirm that your connection is back. Most clients clean up their settings on a normal exit, but an unexpected shutdown can leave a proxy entry pointing to a local port. If you can’t get online after quitting, reopen the client and disable traffic routing. If that doesn’t help, check the relevant settings under macOS “System Settings → Network → Current network service → Details → Proxies.” The exact path may vary by macOS version.

After completing your first setup, keep the verified profile and use its subscription update button to get future changes. If an app starts acting up after an update, check its new connection log before changing routing rules. That’s all you need for everyday use. For another device, a Linux core setup, or a deeper look at routing rules, consult the relevant sections of the installation guide.