Before You Start: Prepare the Client and Configuration Separately

The client provides the interface and runs the core; the configuration supplies nodes, proxy groups, and routing rules. Installing a client does not give you proxy nodes. Before you begin, get a Clash or mihomo subscription URL from a trusted source, or a ready-to-use YAML configuration file. Also make sure your device can access your local network and any required configuration download URLs without a proxy.

Subscription URLs may contain personal access credentials. Copy the entire URL, and don’t share it in public chats, screenshots, or online conversion tools. If your provider gives you a single proxy URL, first check whether your client supports importing it that way. This guide focuses on full configuration subscriptions; a single node URL is not interchangeable with a configuration file.

For your first connection, quit other proxy or VPN clients temporarily and note your current network status. Change one setting at a time so you can tell what caused any difference. On a device with an existing configuration, use the client’s export or backup feature to keep a copy of the original. You don’t need to edit the client’s auto-generated runtime configuration.

1. Import a Subscription and Activate the Configuration

Add the URL on the Configuration Page

Open the client and go to “Configuration” or “Subscription.” Look for “New,” “Add,” or “Import from URL.” Paste the full subscription URL into the address field. Check that it doesn’t contain extra spaces, line breaks, or punctuation added by a chat app. If the client asks for a name, choose a recognizable local label. It’s only for organization and won’t change the subscription.

Click “Import,” “Download,” or “Save,” then wait for the client to fetch the configuration. When it’s ready, a configuration card or entry should appear in the list. Select it and choose “Enable,” “Set as active,” or the equivalent option to make it the running configuration. A successful download does not mean the configuration is active. If you added a subscription but are still running the default configuration, the Proxies page may not show its groups.

After switching configurations, open the Proxies page. You should see the proxy groups defined in the configuration and the available exits within them. Group names come from the configuration provider; they may not be called “Node Selection” or “Auto Select.” First, make sure you can expand the list. Don’t enable System Proxy yet—you still need to choose a mode and an exit.

Local Files and Subscription Updates

If you have a file, choose “Import from file” on the Configuration page, locate the .yaml or .yml file on your device, and activate it after importing. Changing the file extension won’t convert its format. Don’t import a login page saved by your browser as a configuration file, either. Being able to open a file in a text editor doesn’t mean it meets the core’s requirements.

To update a subscription, open the configuration entry’s menu and choose “Update” or “Refresh.” The client fetches the latest remote content, which may change node names and rules. If you need to keep custom changes, learn how your client handles overrides instead of repeatedly editing a local copy of the remote subscription. See the YAML manual for details on configuration structure.

2. Choose a Proxy Mode and Exit Node

Start with Rule Mode

Once the configuration is active, go to “Home,” “Overview,” or “Proxies” and find the mode selector. For your first connection, choose “Rule” or Rule. In this mode, the core processes connections according to the configuration’s rules: some traffic can connect directly, while other traffic goes to a specified proxy group. Whether Rule mode suits your needs depends on the subscription’s rules; clients don’t make the same fixed decision for every website.

“Global” or Global mode typically sends every connection that reaches the core to the GLOBAL group. Check which exit that group is set to after switching modes. If it’s set to DIRECT, traffic may still connect directly. “Direct” or Direct mode doesn’t route traffic through proxy nodes. It’s useful for restoring normal access or comparing results, but it isn’t the right target mode for your first proxy connection.

This setting determines how traffic is routed after it reaches the core, not how device traffic gets to the core. Choosing Global mode doesn’t mean every app is covered. Check separately whether your browser follows system proxy settings and whether the mobile VPN connected successfully.

Choose a Node in the Proxy Group

Open the Proxies page and expand the group responsible for proxy traffic. In a manual selection group, click an available node to select it. If the group refers to another group, expand that one too and check the final exit. Don’t assume a node is selected just because you can see the top-level group name. Some configurations have separate groups for different types of traffic. For now, check only the group your test request will use; there’s no need to set every group to the same value.

You can run a latency test from the group and wait for it to finish. A latency value means that test request completed; a timeout means it didn’t return within the limit. Results depend on the test URL, network conditions, and node load. They don’t directly measure download speed or prove that your target app will work. For your first connection, choose an exit that responds to the test, then verify it with a real request.

If the group contains only DIRECT or the expected nodes are missing, go back and check that you selected the right configuration and that its remote node list loaded successfully. Don’t paste in unknown nodes just to fill the list. For a deeper explanation of select, url-test, and rule targets, see the YAML manual’s sections on proxy groups and rules.

3. Connect and Check How Traffic Enters the Client

Desktop: Check the Core, Then Enable System Proxy

After choosing a mode and node, check the core’s status on the client’s Home page. If there’s a “Start” button, start the core first. If you see a configuration error, fix it on the Configuration page instead of repeatedly toggling the network switch. Once the core is running, enable “System Proxy.” Apps that follow system proxy settings will then send requests to the client’s local listening port.

After enabling it, open a new browser tab and try a website. If needed, quit and reopen the browser so it reloads the proxy settings. Don’t assume the local port is always 7890: it varies by client and configuration. When setting a proxy manually in a browser or command line, use the listening address shown in your client.

If the browser works through the proxy but your terminal, game, or another app doesn’t, first check whether that app supports and follows system proxy settings. To route more apps, consider TUN mode. Enabling TUN in a desktop client may require installing a service, granting administrator privileges, or approving a network extension. Follow your client’s prompts; not seeing a permissions prompt doesn’t mean the service installed correctly.

TUN and System Proxy are different ways for traffic to enter the client. You don’t need to enable both for your first test. Get System Proxy working first, then test TUN if needed. This makes it easier to isolate routing and permissions issues. If your network stops working after enabling TUN, turn it off, restore the last working settings, then check the service status and logs. See the YAML manual for routing, DNS, and exclusions; don’t change them all during your first connection.

Mobile: Approve the System VPN Prompt

In the Android or iOS client, return to the Home page and tap “Connect” or the start button. The first time, the system will usually ask you to approve a VPN configuration. Read the prompt and confirm. If you’re asked for your device passcode or biometric authentication, complete the system check, then return to the client and confirm the connection status has updated. If you cancel authorization, the client can load the configuration but can’t route traffic through this connection method.

Other VPNs, work profiles, or network filtering tools on the same device may conflict with the connection. For your first test, run only one tool of this type. On a managed device, follow your organization’s policies; don’t try to bypass its restrictions. A VPN icon only means the tunnel is established. It doesn’t confirm that the node, rules, or target website are working. You still need to test a real request.

4. Check Rule Matches and Your Actual Exit Route

Compare a New Request with the Connection Log

Leave the client running and open the “Connections” or “Logs” page. Then return to your browser and open a new target page. Switch back to the client and look for the domain or destination you just accessed. Connection records typically show the destination, matched rule, proxy group, and final exit. Fields vary by client, and short-lived connections may disappear from the active list quickly. Check the logs or connection history if needed.

If the record shows that the request went through your selected node, that request reached the proxy exit. If it shows DIRECT, check which rule matched and whether its proxy group is set to direct. It’s normal for some requests to go direct in Rule mode. Don’t change the entire configuration just to make every record show a node name.

If no new connection appears, first check that the client isn’t filtering out records. Then check your browser proxy extension, System Proxy status, or VPN status. If the request never reached the core, changing nodes usually won’t help. For terminal commands or apps with their own proxy settings, check the app’s configuration too. A successful browser test doesn’t mean other apps use the same connection method.

Cross-Check the Exit IP and Your Target App

Next, visit a trusted public IP lookup site and compare the result with one from when the proxy was off. In Rule mode, the lookup site itself may match a direct-connection rule, so check the connection record for that request too. Don’t mistake your device’s private network address for its public exit IP, or rely only on the listed location; geolocation databases can be delayed or inaccurate.

A changed exit IP only proves that this lookup request took a different network route. Finally, open the app you actually need and try a real task, such as loading a page, signing in, or making an API request. Check its connection record. If the browser works but the app doesn’t, check the app’s proxy settings, DNS, UDP requirements, and account restrictions before assuming all nodes are unavailable.

After changing modes or nodes, start a new connection. Existing long-lived connections may keep using their original exit. If your client has a “Close connection” option, you can disconnect the test connection and retry, but this will interrupt any transfer in progress. For your first test, make a fresh browser request instead of repeatedly changing settings during a large download.

If It Fails, Check the Entry Point, Rules, and Exit—in That Order

Entry point: No new connection records? Check System Proxy, the app’s proxy settings, TUN, or mobile VPN authorization. First make sure the target traffic reaches the core.
Rules: A connection appears, but takes an unexpected route? Check the current mode, matched rule, and proxy group selection. Don’t mistake traffic routing for a connection failure.
Exit: A node is selected, but requests time out? Try another authorized node that responds to the test, then check the subscription status and your network. If all nodes fail, note the specific error in the logs.

Once the apps you need are working, configure options such as launch at startup or scheduled subscription updates, and keep a copy of the working configuration. Before quitting the desktop client, make sure System Proxy is disabled or restored by the client; otherwise, your system may keep sending requests to a local port that is no longer running. If something breaks later, retrace these four steps first. It’s easier to find the cause than changing modes, DNS, and routing all at once.

For more on configuration fields, rule syntax, and overrides, see the YAML Configuration Reference. To compare platform support and workflows across clients, see Client Comparisons. Once you’re connected, you’re done—there’s no need to add extra options to a working configuration.