Clash Subscription Import and Connection Guide

Before you start: install the client and get a valid subscription

If you haven't installed a client yet, open the Windows download page and choose an installer for your system. After installation, launch the client and make sure its main window opens normally and the settings page shows no core startup errors. For your first setup, run only one proxy client at a time. Multiple clients can overwrite Windows proxy settings, making the interface show that the proxy is on while requests are actually sent to a different port.

Next, get a subscription URL from your provider or a ready-to-use Clash-compatible YAML configuration file. The client handles traffic; installing it doesn't provide a remote connection by itself. Subscriptions usually contain proxy nodes, policy groups, and routing rules. If your provider offers several formats, choose one explicitly marked for Clash or mihomo instead of copying an ordinary webpage URL.

Subscription URLs may contain account-specific parameters, so treat them as sensitive information. Don't post the full URL in public forums or upload it to an unfamiliar conversion site. If you need to share a screenshot for troubleshooting, hide identifying parameters and node credentials first. Once you're ready, make sure your current network can reach the subscription source, then start with step one.

Step 1: Import the subscription and select its configuration

In the client's sidebar, open “Subscriptions,” “Configurations,” or Profiles, then click “Add,” “Import,” or the plus button. Choose URL import, paste the full subscription URL into the address field, check for spaces or line breaks at either end, and click Import. Some clients let you name the configuration; use a clear local name to distinguish work and test setups later.

Wait for the import to finish. The page should show a configuration card with a name, update time, or source information. You may also need to click the card, an Enable button, or “Use” in the configuration menu to make it active. Downloading a subscription without switching to it can leave the Proxies page showing old content. Check the selected indicator and the proxy groups that actually loaded.

Open the Proxies page and confirm that the subscription's policy groups and selectable nodes are visible. Group names vary by subscription; they might be “Proxy Select,” PROXY, or a custom name. There's no need to rename them. If the page is empty, return to the subscription page and check that the right configuration is selected, then review the logs for parsing errors, unsupported protocols, or configuration load failures.

For a local YAML file, use the “Import file” option on the same page, select the file, and activate it. Don't paste file contents as a URL, and don't assume the contents are compatible just because the extension is YAML. If you only have a single-node share link, the client must support that import method. If it doesn't, ask your provider for a complete Clash configuration.

Subscription update failed? First check whether download or loading failed

“Download failed” usually means the client couldn't retrieve the remote content. “Parse failed” means content was received, but the client couldn't read it as a configuration. First check whether the subscription has expired and whether the URL is complete, then see if the response is a login page or an error message. Don't change every setting during your first import. Whether update requests need a proxy depends on the subscription source; adjust the update method separately if your client supports it.

Once the configuration works, set an automatic update interval based on your provider's recommendations. Updates fetch new remote content, so direct edits to a subscription file may be overwritten on the next refresh. For lasting customizations, use the client's override or merge features. For troubleshooting, see Subscription Update Failures and Automatic Updates. Once the proxy groups appear, move on to choosing a mode.

Step 2: Choose a rule mode and an exit node

Find the mode menu at the top of the client, on the Proxies page, or in the system tray. For your first setup, choose “Rule” or Rule mode. Rule mode evaluates requests against the active configuration and decides whether to connect directly, reject the request, or route it through a proxy group. It's a practical choice for everyday use because different destinations can take different routes instead of sending every connection through the same remote exit.

After selecting Rule mode, open the Proxies page, expand the main selection group, and choose a known working node or an automatic selection group provided by your subscription. There may be two levels of selection: an outer policy group can point to another group, which then selects a specific node. If changing nodes has no effect, follow the active selection chain rather than checking only whether an item in the list is highlighted.

Clash rule-based routing: start with the subscription's default rules

For your first connection, keep the subscription's default rules and confirm that they appear on the Rules page. For example, DOMAIN-SUFFIX,github.com,PROXY sends matching domain suffixes to the policy named PROXY. That policy must actually exist in the configuration. Rules are usually evaluated in order; a broad rule near the top can prevent more specific rules below it from matching, so don't casually add a rule that overrides all requests.

“Global” mode sends traffic that has already reached the core through the selected global policy, but it doesn't automatically capture traffic from every Windows app. Whether an app sends requests to the client still depends on the system proxy, the app's own proxy settings, or TUN. “Direct” mode sends traffic that reaches the client directly. To keep troubleshooting simple, this guide stays in Rule mode.

For help choosing a node based on protocol compatibility, or understanding the differences between the original core, Meta, and mihomo, see the protocol and core reference. You don't need to edit the full configuration at this stage. Choose Rule mode and a working exit node, then continue.

Step 3: Confirm the core is running and enable the system proxy

Return to the client's home or settings page and make sure the core is running. Some clients load the configuration on startup; others require you to click a Start button. If the logs show a configuration error, listener failure, or process exit, resolve that first. Otherwise, Windows may send requests to a local address that isn't serving traffic correctly, preventing your browser from connecting.

Clash port settings: note the actual mixed port

In Settings, look for “Mixed Port” or mixed-port and note its current value. 7890 is a common example, not a required port for every client. If your client uses a different port, keep that value. A mixed port usually accepts both HTTP and SOCKS connections; local apps commonly connect through the loopback address 127.0.0.1.

Next, turn on “System Proxy” in the client. On Windows, open “Settings → Network & Internet → Proxy” and check that the manual proxy address and port match the client. Windows versions display these settings slightly differently. If the client manages the proxy, use its toggle to update the settings rather than changing them manually in multiple places. On managed devices, check your organization's proxy policy first.

After enabling the system proxy, leave TUN off and don't change DNS, LAN sharing, or ports at the same time. Most browsers that follow the Windows system proxy can use it directly. An app with its own proxy settings, or one that ignores the system proxy, may continue using its existing route. That doesn't necessarily mean the node is broken; check the connection log in the next step.

If startup reports that a port is already in use, don't terminate an unfamiliar system process. First close any duplicate proxy clients. If the conflict remains, switch to an unused port and reapply the system proxy. Then confirm that Windows points to the new port. For details, see How to Fix a Port 7890 Conflict and Change mixed-port.

Step 4: Verify the connection in the logs

Leave the client running, reopen your browser, and visit a site that should use the proxy under your current rules. If the browser has a proxy extension, make sure it isn't overriding the system settings. Open a new tab for the test and, if needed, restart the browser so existing long-lived connections don't keep using the previous route. A lit client toggle alone doesn't prove that requests are going through the proxy.

Next, open the client's “Connections” page and find the domain you just visited. Check the matched rule, policy group, and final node. The fields vary by client, and some require you to click a connection row to see its details. A DIRECT result is expected if the configuration calls for a direct connection. To verify the proxy route, choose a site that should match a proxy rule.

If the browser request doesn't appear in the connection log, first confirm you're using the right client, then check the system proxy address and port, browser extensions, and the app's own proxy settings. Entries may disappear when a connection ends, so watch the log while refreshing the page. If the client supports request logging, you can temporarily increase the log level, then restore the usual setting to avoid collecting excessive detail.

If the connection appears in the log but the page times out, traffic has at least reached the client. Now check whether the selected node is available, the policy group points to the expected exit, and DNS is working. Try a known working node, reload the same page, then compare the logs. Change one thing at a time so you can tell what fixed the connection.

Clash node latency tests: use results as a guide

On the Proxies page, click the latency test button for a group and wait for the results. Then select a node that passed and test it again. A latency test measures one request from the client to a specific test address; it doesn't measure actual download speed or guarantee that every website will work. The test URL, timeout, and target service status all affect the result, so don't focus only on the lowest number.

A timeout doesn't necessarily mean your whole computer is offline. First confirm that the basic network works over a direct connection, then check that the subscription is valid and node credentials are up to date. If only one app has a problem while the browser and other requests work, focus on that app's proxy settings. Once the site loads and the connection log matches the expected rule, the basic setup is complete.

Next-level setup: enable TUN only when needed

Consider TUN only if the browser works through the system proxy but games, command-line tools, or some desktop apps still don't reach the client. TUN uses a virtual network adapter and routing to capture more IP traffic, making it useful for apps that ignore the system proxy. It works alongside Rule mode: once traffic reaches the client, rules still determine how it's routed. TUN doesn't mean every connection has to use a remote proxy.

In the client settings, find “Service Mode” or the related service installation option and grant the required system permissions as prompted. Confirm the service is available before enabling TUN, then check the logs for errors related to the virtual adapter, routes, or DNS. Permission requirements vary by client, so follow its prompts. You don't need to run the entire interface as an administrator for regular system-proxy use.

After enabling TUN, retry an app that previously bypassed the client, then check the Connections page for its destination and matched rule. Other VPNs, virtual network adapter tools, or corporate network software can cause routing or DNS conflicts. If you lose connectivity, turn off the newly enabled TUN first and restore the system-proxy setup you already verified. Troubleshoot one setting at a time instead of piling on more network changes.

For the full service installation, DNS capture, and rollback process, see How to Enable Clash TUN Mode. If the issue affects only Windows Store apps, see How to Fix UWP App Loopback Restrictions. Identify the cause before choosing a connection method.

Everyday use: update subscriptions and turn off the proxy when done

For routine use, start the client, confirm the active configuration, and enable the connection method you need. If a node stops working or your provider changes its service, update the subscription manually and check that the policy group still points to an available option. Updates may change node names and groups, so your previous selection might not carry over. After updating, briefly verify a website and its connection log again.

When you're done, turn off the system proxy before quitting the client. If the client offers a “Clear system proxy on exit” option, enable it if you prefer and verify that it works. If the app exits unexpectedly and your browser can't connect, check Windows proxy settings to see whether they still point to a local listening port. Before clearing a leftover proxy setting, make sure it isn't required by your organization or another running app.

To revisit a step, save a link to the subscription import, rule-based routing, port settings, or node latency section. For background on protocol differences, core compatibility, and subscription formats, see the protocol guide. Before switching clients, check the client comparison so you don't mistake a configuration issue for a reason to reinstall.