Clash Subscription and Connection Guide

Before you begin: get a client and subscription ready

Install a mihomo-compatible client and get a Clash-format subscription URL or YAML configuration file from your provider. The client loads the configuration, runs the core, and routes traffic; the subscription provides proxy servers, policy groups, rules, and other settings. Installing a client alone does not give you servers to connect to, and this guide does not provide shared subscriptions. Check the subscription source, expiration date, and device limits before importing it.

For your first setup, run only one proxy client. Turn off the system proxy, TUN, or VPN connection in any other proxy tools, and keep your current network working as usual. If your device is managed by an organization, check whether its network policy allows proxy changes or virtual network adapters. Note any existing manual proxy settings so you can restore them after testing. Don't disable the system firewall to troubleshoot a connection.

The steps below establish one minimal working setup without changing complex rules. For your first connection, use the policy groups and rules included with the subscription. Adjust DNS, automatic latency testing, or rule sets only after confirming the connection works. For differences in installation permissions, service modes, and configuration directories across operating systems, see the cross-platform installation and configuration guide. This page focuses on making your first connection.

STEP 01 / PROFILE

Import a subscription and activate the configuration

Open the client's “Configuration” or “Subscription” page, then choose “New,” “Add,” or “Import from URL.” Paste the complete subscription URL and give the profile a recognizable name. Use the Clash or mihomo configuration URL provided by your service—not an account sign-in page, payment page, or arbitrary link from your browser's address bar. Check for leading or trailing spaces and line breaks, and don't remove query parameters from the URL.

Choose “Download” or “Import” and wait for the client to confirm success. A new entry should appear in the configuration list, sometimes with an update time or remote source. Then click “Use” or “Activate,” or select the profile card. Some clients activate an import automatically; others only save the file. Check which profile is marked as active and whether the proxy page shows the subscription's policy groups. A new name in the list alone doesn't confirm that the configuration is active.

If you have a local .yaml or .yml file, choose “Import from file” and select it. Don't paste the file contents into the subscription URL field. A local configuration may not update automatically; if it references remote proxy or rule sets, the client may still need to download those resources at runtime. Being able to select the file only confirms that you used the right import option—the core must still parse and load it successfully.

After activating the configuration, open the “Proxy” page and check that its policy groups or nodes appear. Names depend on the subscription author; common examples include “Node Selection,” “Proxy,” and PROXY. If the page is empty, return to the configuration page and make sure the imported profile is selected, then check the logs for download or parsing errors. A downloaded web page, an incompatible configuration format, or incorrect indentation can leave an entry in the list that the core can't use.

If the first download fails, check that your device is online, then ask your provider to confirm that the subscription is active and the URL is complete. Don't keep trying different configuration formats, and don't immediately enable global mode to mask a download problem. Once it's fixed, manually update the profile in the configuration list. Continue only after the update succeeds and the profile is active. If node names change after a later subscription update, check the current selection in your policy groups again.

STEP 02 / ROUTING

Choose a rule mode and an outbound node

Find “Mode” on the client home screen, at the top of the proxy page, or in settings. Choose Rule (often labeled “Rule” or “Rules” in English). In rule mode, the configuration's match order determines whether traffic goes direct, through a proxy, or to another outbound policy. It's a good starting point for everyday use. Keep the subscription's existing rules; you don't need to write a full set of rules just to get connected.

Mode and traffic routing are separate settings. Rule mode determines how traffic is handled after it enters the core; system proxy or TUN determines which traffic can enter the core. Switching to global mode won't automatically route command-line programs that ignore the system proxy through the client. Likewise, enabling TUN doesn't mean every destination will use a proxy—the active mode and rules still decide where traffic goes.

Next, open the “Proxy” page and expand the main policy group. If it contains a manual list, select a node provided by your subscription. If it contains nested groups such as “Auto Select,” check the selection in those groups too. Don't just check whether a node is highlighted; confirm that the rule for your target site refers to that policy group. An option named DIRECT means direct connection and won't use a remote proxy server.

Look for “Latency Test,” “Speed Test,” or a similar button and run a test. A result means the node responded under the test conditions; it doesn't guarantee that every website, UDP request, or long download will work. A timeout may also be caused by the test URL or your current network. For your first setup, pick a node that passes the test instead of chasing the lowest number. Verify real access and connection logs in step four.

By the end of this step, you should know two things: rule mode is active, and the main proxy policy group has a node or auto-select group chosen. If you're unsure which group handles traffic to a particular site, keep the subscription's default selection and check the matched rule after connecting. For details on rule priority, nested policy groups, and auto-selection settings, see the configuration guide. You don't need to review everything before your first connection.

STEP 03 / TRAFFIC CAPTURE

Start the core and route traffic through the client

Return to the client's home screen and confirm that the core is running. Some clients start it automatically; others require you to click “Start” or a connect button. If the configuration fails to load, go back to step one and fix the error before changing traffic-routing settings. Once the client shows “Running,” enable one routing method for your platform. For your first test, don't change system proxy, TUN, and DNS settings at the same time; doing so makes failures harder to diagnose.

Desktop: test the system proxy first

Find “System Proxy” in settings or on the home screen and enable it. The client usually points the system's HTTP and HTTPS proxy settings to a local listening port. Don't copy port numbers from another guide; use the port configured in your client. Leave the client running and make a new request in a browser that normally follows the system proxy. Browser extensions, custom proxy settings, or managed policies can override system settings, so check those separately if something goes wrong.

Command-line tools don't always use the system proxy. If your browser works but your terminal doesn't, that doesn't mean the node is down. You can configure a tool that supports proxy options to connect to the local port, or try TUN later. The exact environment variable syntax depends on your terminal and the tool, so see how to troubleshoot browsers and terminals separately. Verify the browser first, then test other apps to keep troubleshooting focused.

Mobile: approve the system VPN permission

Tap Connect or Start in your mobile client. The first time it runs, the system will usually prompt you to add a VPN configuration. Check which app is requesting access, approve it, then return to the client and check the connection status. A VPN indicator means the traffic-routing tunnel is up; it doesn't guarantee that the remote servers in your subscription are reachable. If you were connected to another VPN, disconnect it first to avoid mistaking a single active system tunnel for the wrong connection.

For broader traffic routing: test TUN separately

Try TUN if the browser works but games, some command-line programs, or other apps aren't routed through the client. First note the system proxy settings, then turn off the system proxy to test TUN on its own. Install the required service or grant network permissions as directed by the client, then enable TUN. Virtual adapters, routing, and DNS requirements vary by operating system. If you see a permission error, follow the client's instructions instead of repeatedly toggling the setting.

After enabling TUN, check the client logs to confirm that the virtual adapter and routes were set up successfully. If your network immediately stops working, disable TUN and check whether the connection returns, then go back to the system proxy setup you already verified. Don't stack other VPNs, packet capture tools, or routing changes on top. For more on how system proxy and TUN work and when to use each, see system proxy vs. TUN: how traffic routing works. For now, keep just one method that works.

STEP 04 / VERIFICATION

Verify that the proxy and rules are working

Keep the client running and confirm that the configuration, rule mode, and traffic-routing setting are still as expected. Open a site that should use the proxy in a new browser tab and make a fresh request; don't treat an already-open page or cached content as proof of a successful connection. A page that loads is a useful first sign, but doesn't prove which outbound route it used—the site may also be reachable directly.

Open the client's “Connections” or “Request Log” page and revisit the target in your browser. Find the entry for its domain and check three things: the destination, the matched rule, and the final policy or node used. If the log shows a direct rule, a loaded page doesn't prove the proxy is working. If the request went through a policy group, check the final node as well, not just the top-level group name. Some clients remove connections as soon as a request ends; enable connection history or watch the log while making the request.

Cross-check the result with a trusted exit IP lookup and compare it with a direct connection. IP geolocation is only a clue: databases can be out of date, and IPv4 and IPv6 may take different routes. Don't rely on a location label alone. A stronger check is to confirm that a new request appears in the client, matches the expected proxy policy, reaches its destination, and shows an exit IP consistent with the selected outbound.

Finally, visit a destination that should connect directly according to your configuration and check that it matches the expected rule. Different destinations showing different exit IPs in rule mode is normal; there's no need to stay in global mode just to make every lookup show the same result. For a brief comparison, note the current settings, switch to global mode, explicitly select a node, make a new request, then switch back to rule mode. Existing long-lived connections may continue using their previous route.

When you're done, stop the client normally and check that the system proxy has been restored. Restart the client and repeat a quick access test to confirm the settings work after a restart. If you've closed a desktop client but the system still points to its local proxy port, your browser may lose internet access. Restore the system proxy settings instead of cycling through nodes. Configure launch at startup and automatic subscription updates only after the first connection has been verified.

Troubleshoot in connection order

If step four fails, check the chain in order: subscription download → core configuration → node outbound → traffic routing → rules and DNS. Change one setting at a time and retry the same destination. This helps pinpoint the failing step instead of relying on random toggles that may only provide a temporary fix.

1. Configuration download failed: Check that your basic connection works, the subscription is active, and the URL is a configuration link. Check the HTTP status or parsing error. If the download is a sign-in page, ask your provider for the correct URL.
2. Configuration failed to load: Check the logs for YAML parsing errors, missing policy group references, or failures to download external resources. Try downloading the original subscription again. Don't rewrite large parts of the configuration before you know what caused the error.
3. Node test timed out: Choose another node in the same policy group and retry with the same destination. If they all fail, check your subscription account and network restrictions. A successful test still needs to be followed by a real access check.
4. No browser request in the log: Confirm that the core is running and that the system proxy or VPN routing is enabled. Check for browser proxy extensions too. First make sure the request reaches the client; then troubleshoot the rules.
5. Request logged, but connection failed: Check the final outbound and the specific error. For a domain resolution error, check DNS first. For a refused or timed-out connection, check the selected node and destination; don't change all your DNS settings based on a single log entry.

If you need to report the issue, include your operating system, client name, whether you're using the system proxy or TUN, the destination that failed, and the relevant error text. Redact your subscription URL and account details before sharing any log excerpts. Reproducible steps are more useful than a full-page screenshot or a vague “no internet” report.

Once the basic connection works, continue with the cross-platform installation and configuration guide for rule sets, DNS and fake-ip, service permissions, and platform-specific issues. After each subscription update or change to traffic routing, repeat the real-request check in step four to confirm that everything works as expected.