Clash Subscription Setup and Connection Guide.

Step 1: Import and Enable a Subscription Profile

On your provider’s subscription page, find the option for Clash or mihomo, then use the adjacent copy button to copy the full URL. Don’t share the URL in public chats or screenshots—it may contain account-linked access credentials. If the page offers formats for multiple clients, choose one explicitly marked as compatible with your client instead of trying a different format at random.

Return to the client and open “Configuration” or “Subscription” in the sidebar. Look for “New,” “Add,” or “Import from URL.” Paste the link, give the profile a recognizable local name such as “Daily,” then click “Import” or “Save.” Some clients put the URL field at the top of the configuration page; paste the link and click the download icon. The local name only helps you identify the profile—it doesn’t change the nodes provided by the service.

Wait for the download to finish. You should see a profile card or a new subscription entry in the list. Select it, then choose “Enable,” “Use,” or the equivalent selected state to make it the active profile. Downloading and enabling a profile are two separate steps: seeing a file in the list doesn’t mean the core is using it. If a syntax or field error appears after switching profiles, fix that before continuing.

Open the Proxies page and check that policy groups and their nodes are visible. Group names come from your subscription and may be “Proxy,” “Proxy Selection,” or something else. If you see only built-in entries such as DIRECT and REJECT, return to the configuration page and confirm that the right profile is active, then check the subscription update status. Don’t switch to Global mode yet; changing modes won’t restore missing nodes.

If the import fails, check that the URL is complete and doesn’t contain extra spaces, line breaks, or missing trailing parameters. A timeout may mean your current network can’t reach the subscription server. A parsing error may mean the server returned a sign-in page, an error page, or an incompatible configuration format. A URL opening in your browser doesn’t mean it returned a configuration the client can read. For more help, see troubleshooting failed subscription updates. Avoid submitting the URL to an unknown online converter.

If your provider supplied a local YAML file, choose “Import from file,” select the file, and enable it. File imports may not support automatic remote updates, so you might need to download a new profile when nodes change. Whether you imported a URL or a file, this step is complete when the profile is active, the Proxies page shows the expected groups, and there are no unresolved configuration errors.

Step 2: Choose a Rule Mode and Proxy Node

Once the nodes have loaded, find the “Mode” setting on the client’s home, Proxies, or Settings page. For your first setup, choose “Rule.” This mode uses the configuration’s rules to decide whether each connection goes direct, through a proxy group, or to another outbound route. It’s useful for separating traffic that needs a proxy from ordinary browsing. Keep the subscription’s default rules for now; don’t add a large set of custom rules yet.

“Global” mode usually sends all connections that reach the core through the global policy, making it useful for temporarily checking whether rules are affecting the result. “Direct” mode usually connects those requests straight to their destinations. One point is easy to miss: mode determines how traffic is handled after it reaches the core; it does not route app traffic into the core. Even in Global mode, apps may still connect directly if you haven’t enabled the system proxy or VPN routing.

Return to the Proxies page and find the main policy group actually referenced by your configuration’s rules. Expand it and select a node. If the group offers “Auto Select” or “Failover,” you can use a group already defined by the subscription. For initial troubleshooting, pinning a specific node makes results easier to compare. Don’t assume every request will use a node selected in a secondary group—different rules may point to different groups.

Next, click the group’s latency test or connection test and wait for the result. Avoid using a node that times out for your first verification; try another one instead. A test result is just one probe to a specific test address: low latency doesn’t mean every website will download quickly, and a successful test doesn’t guarantee that your account, target site, or entire route is working. If every test fails, check your subscription’s expiration and service status, then see node latency and timeout explained.

In everyday use, if a site doesn’t appear to use the proxy as expected, check the connection log to see which rule matched before changing your routing. Temporarily switching to Global can help with diagnosis, but switch back to Rule mode when you’re done. Global mode can’t cover apps whose traffic isn’t being routed through the client, or fix an unavailable node. For the difference between rules, policy groups, and nodes, see the glossary. This guide keeps things simple: Rule mode with one clearly selected outbound route.

At this point, the client knows which profile to use, how to handle requests, and which outbound route the main policy group should take. Next, the system or app needs to send its network requests to the client. Note your current mode and node. During testing, avoid changing the node, mode, and DNS at the same time; otherwise, even if the connection recovers, it’ll be hard to tell what fixed it.

Step 3: Start the Client and Route Traffic

Return to the client’s home page and check the core or service status. Some clients start the core as soon as they open; others require you to click “Start” or “Connect.” Confirm that it’s running and that there are no errors such as a port conflict or failed configuration load. Don’t enable the system proxy until the core is running. Otherwise, apps may be pointed at an unresponsive local port, making sites that worked before become unreachable.

On Windows, macOS, and Linux, start with the “System Proxy” option for your first desktop test. It changes the system proxy settings so browsers and apps that follow those settings send requests to the local client. After enabling it, open a new browser tab to test. If the system asks you to approve a network settings change, verify that the request comes from the client you’re using and authorize it as prompted. Disabling system protections should not be a standard installation step.

The system proxy doesn’t cover every app. Some games, command-line tools, and apps with their own proxy settings may ignore it. So if a browser works but another app doesn’t, the node may still be fine. Verify the browser first, then check whether that app needs its own proxy settings or TUN. Command-line proxy environment variables are separate from the system proxy; don’t change them just to test a browser.

On Android and iOS, tapping “Connect” usually brings up a system VPN permission prompt. Confirm the app’s identity, allow the connection, then check the client’s status. The VPN indicator means a tunnel has been established, but doesn’t prove that the node can reach a particular site. If another VPN is connected, disconnect it before testing. A work profile, device management policy, or always-on VPN setting may also prevent a new connection.

If a desktop app really does ignore the system proxy, look for “TUN,” “Virtual Network Adapter,” or a similar option in the client. TUN routes traffic through a virtual network interface and may require a service installation, routing changes, and additional permissions. Follow your client’s instructions for authorization. Don’t copy network adapter names, route commands, or DNS settings from another guide without checking that they apply to your system. Check Linux permissions, macOS network authorization, and Windows service status according to your platform.

If your network stops working after you enable TUN, turn it off first and check whether a direct connection is restored. Don’t add more DNS or routing changes on top. For help with virtual adapters, permissions, and DNS routing, see the relevant platform chapter in the complete guide. When this step is done, you should have one clear connection method: the system proxy on desktop, or VPN/TUN routing that has been authorized correctly.

Step 4: Verify the Traffic Route and Restore Your Network

Once the Connect button shows that the client is running, don’t stop at the indicator. Open a new browser tab and visit a site you expect to access through the proxy, making sure the site itself is up. Use a fresh request so a previously loaded page, offline cache, or existing connection doesn’t skew the result. Then open the client’s “Connections” page and find the domain you just visited.

Expand the connection and check the target domain, matched rule, policy group, and final outbound route. The fields shown vary by client: some display the full policy chain, while others show only the final node. If the log points to your selected proxy node and the page loads, traffic routing and the proxy route are working for that request. If it shows DIRECT, check your rules: direct access may be expected, or the routing may not match your expectations.

If the site loads but you can’t find the request in the connection list, check whether the list is filtered, paused, or limited to specific processes, then visit the page again. If the request is still missing, go back to Step 3 and check whether the app follows the system proxy or VPN/TUN is actually active. A site loading doesn’t prove the proxy is working; it may have been reachable directly.

Next, visit a familiar site that you expect to connect to directly and check its log entry too. In Rule mode, it’s normal for the two sites to use different routes. If you use an exit IP lookup site as a cross-check, first confirm whether that request is going through the proxy or connecting directly. The result applies only to that request; it doesn’t prove every app on your device uses the same route. Before sharing a screenshot, hide your IP address, subscription details, and account information.

If the log shows a proxy route but the page fails, try a different site, then a different node—changing just one thing at a time. If several sites fail and the node test also times out, check the node and service status first. If only one site fails, the issue may be related to that site’s restrictions, the node’s exit, or a rule. If the page loads but some resources fail, checking those resources’ connection logs is more useful than repeatedly switching to Global. For more help, find the matching symptom in common issues.

After testing, check that you can disconnect cleanly. On desktop, turn off the system proxy or TUN. On mobile, tap Disconnect. Then confirm that ordinary websites still load. Don’t force-quit the desktop client before restoring the system proxy setting. If your browser still can’t connect after quitting, check for a manual proxy that still points to the local client in your system network settings. Restore only the settings changed by this client, and don’t remove proxy settings required by your workplace or school.

Note the working profile name, traffic-routing method, and selected policy group so you can return to this verified setup if something goes wrong. If behavior changes after a subscription update, first check whether the active profile or group selection was reset. For automatic updates, DNS, rule sets, or platform-specific background permissions, continue with the configuration FAQ in the complete guide. There’s no need to change every advanced option during your first connection.