Import a Clash Subscription, Connect, and Verify

Import from a Subscription URL

After opening the client, look for the “Subscription,” “Configuration,” or “Profiles” page. Desktop clients usually provide an input field and import button at the top, while mobile clients may place the entry in a plus-sign menu in the upper-right corner. Paste the complete subscription URL, add a recognizable name such as “Daily Configuration” if needed, then click “Import,” “Add,” or “Download.” The client will fetch the remote content and create a new configuration entry.

After importing, do not enable the system proxy immediately. First check whether the configuration entry shows a name, update time, or proxy count, then open the proxy page and confirm that at least one proxy group appears. If the configuration page has a new entry but the proxy page is still empty, the subscription may not have parsed successfully. If the client reports a format error, verify that the copied URL is complete. Some services offer general subscriptions, Clash subscriptions, and formats for other clients; choose the one explicitly marked for Clash or mihomo.

When the configuration list contains multiple entries, select the target configuration and choose “Enable,” “Set as Active,” or a similar action. Downloading alone does not mean the client is using it. Check whether the entry has an active-state indicator, or return to the home page and see whether the current configuration name has changed. Confirm the active item before continuing so that the proxy groups and rules you see belong to the configuration just imported.

Import from a Local YAML File

For a local file, choose “Import from File” on the configuration page or drag the YAML file into the client's designated area. Android usually opens the system file picker and may ask for permission to read the selected file; macOS may request access to the Downloads or Documents folder. After a successful import, set the file as the active configuration. If the client reports a YAML parsing error, first check indentation levels, spaces after colons, and list-item formatting instead of repeatedly changing proxy modes.

Local configurations work well when you need fixed rules or maintain parameters yourself, but first-time users should not enable override scripts, global extensions, and multiple rule providers at once. The more layers a configuration has, the harder it is to identify the effective value when something goes wrong. Complete one connection with the original configuration, then add custom content one item at a time. For details on protocol fields, subscription compatibility, and configuration migration, see the subscription formats section in the protocol handbook.

Use Rule Mode First

When the configuration is ready, open the client's “Mode,” “Mode,” or proxy settings area. Common options include Rule, Global, and Direct modes. For a first setup, choose Rule mode, commonly shown as Rule. In this mode, each request is matched against the configuration's rules in order: some domains or networks connect directly, other requests go to a designated proxy group, and unmatched requests are handled by the final rule. This verifies that the subscription rules loaded correctly and follows the default design of most configurations.

Global mode typically sends most requests through one global policy. It can help briefly determine whether rules are causing connection differences, but it should not be treated as a solution to every problem. Direct mode bypasses the proxy and is mainly useful for temporary network recovery or comparison tests. If a site fails in Rule mode but opens in Global mode, inspect the matching rule and proxy group; if both modes fail, return to the configuration, proxy availability, or system integration.

Assign a Proxy to the Main Group

On the “Proxy” or “Proxies” page, you will see the proxy groups defined by the configuration. Names may include “Proxy Selection,” “Auto Select,” “Failover,” “Media,” or custom labels. Find the main group handling default traffic, open it, and choose a specific proxy entry. If the group contains DIRECT, an automatic test group, and multiple proxies, manually select a working proxy for the first verification to reduce variables caused by automatic switching.

The latency test provided by the client only shows whether the test address was reachable at that moment and roughly how long the request took to establish. It does not prove that every website and application will work. An entry with low latency may still fail in practice because of protocol parameters, network paths, or differences in the target service. Use tests to narrow your choices, but rely on the real connection log and page results in Step 4 for the final check.

If a proxy group uses url-test, fallback, or load-balance, the client may display it as “Auto Select,” “Failover,” or “Load Balance.” Their selection logic differs: auto testing usually favors the proxy with the best test result, failover focuses on switching order after the current proxy fails, and load balancing distributes connections across multiple proxies. For a first setup, just confirm that the main group has a usable selection; do not adjust test intervals, tolerance, or hash policies yet. See the protocol handbook for details.

Confirm That the Kernel Is Running

Return to the client's home or settings page and check the kernel status. Clients using mihomo may show “Running,” “Service Running,” or a start button. Some desktop clients start the kernel automatically; others require a manual click. If service mode is involved, Windows may request administrator approval, while macOS may ask for the system password to install a helper service. After authorization, wait for the status to stabilize before enabling the system proxy.

If the kernel will not start, first check port usage and error logs. A common cause is another proxy client still running in the background, or an old process occupying the configured mixed-port, HTTP port, or SOCKS port. Close other clients and start again; this is easier to diagnose than changing several ports at once. If the log says that a configuration field is unrecognized, the kernel may not support the configuration's capabilities. Update the client or choose a compatible format.

Enable the System Proxy on Desktop

After the kernel is running, Windows and macOS users should enable “System Proxy,” “System Proxy,” or “Set as System Proxy.” This writes the proxy address to the operating system's network settings, allowing browsers and applications that follow the system proxy to send requests to Clash. Do not quit the client immediately after enabling it: the system proxy only directs traffic to a local listening port, while the running kernel handles the actual connections.

Some browsers use their own proxy settings, and some command-line tools do not automatically read the system proxy. For the first test, use the system browser or a common desktop browser instead of an application with unusual networking behavior. After the browser works, check the target application's network settings to decide whether to enter an HTTP or SOCKS address separately, or use TUN mode for broader coverage.

Allow a System Connection on Mobile

Android and iOS clients usually take over traffic through the system VPN interface. After you tap Connect, the system displays a network connection permission prompt; once approved, the status bar shows the connection indicator. This permission allows the client to create a local network tunnel, but does not mean that the correct proxy has been selected, so keep the proxy group choice from Step 2. If the system reports that another VPN is already running, disconnect it before starting the Clash client again.

When to Consider TUN Mode

The system proxy works well for browsers and desktop apps that follow system settings, with a short setup path and clearer first-time troubleshooting. TUN mode uses a virtual network interface to cover more traffic, which helps with applications that ignore the system proxy, some command-line programs, or setups that require unified DNS handling. TUN may require administrator permissions, a helper service, or additional network components. This guide recommends verifying a browser with the system proxy first, then enabling TUN if needed.

After switching to TUN, avoid letting other network tools modify routes or DNS at the same time. If the connection changes, disable TUN first and confirm that the system proxy path still works, then inspect the TUN stack, DNS hijacking, and route exclusions. For a complete explanation of system proxy, TUN, DNS modes, and permissions across operating systems, see the network and system section of the protocol handbook.

Start with a New Browser Request

Keep the client running in the foreground or background, close any test page already open in the browser, and visit a stable site in a new tab. Reopening the page is more reliable than refreshing an old one because browser caches, existing connections, and DNS caches may prevent a complete new request. A loaded page is only the first result; return to the client and confirm that the corresponding domain appears in the connection list.

Open the “Connections” or “Logs” page and find the domain you just visited. Normally you can see the request target, matched rule, proxy group, and final proxy or DIRECT. If the site is expected to use a proxy, the log should show the corresponding policy chain; if a site that should connect directly shows DIRECT, that also confirms Rule mode is working. The goal is not for every request to follow the same path, but for the result to match the rule design.

Distinguish Browser Success from System-Wide Success

Once the browser works, test an application you actually need and watch the connection list at the same time. If the browser has entries but the target application creates no new connection, it may not read the system proxy or may use its own network stack. Check the application's proxy settings; on desktop, you can also test TUN mode after understanding its permission requirements. If the connection list shows requests that time out, traffic has reached Clash and the more likely causes are the proxy entry, protocol parameters, DNS, or the target network path.

Command-line tools require separate checking. Some read system environment variables, some use their own proxy parameters, and others are intercepted only in TUN mode. Do not use a single command-line request to dismiss the system proxy status. Establish a baseline with the browser and the client's connection log, then configure the proxy address for the specific tool to separate system integration issues from application settings.

Check Whether Mode Switching Behaves as Expected

To confirm the effect of the rules, compare the same website while keeping the proxy entry unchanged: switch briefly to Global mode and reopen the page, then switch back to Rule mode. If Global works but Rule fails, check which proxy group the request matched and whether that group accidentally selected Direct or an unavailable entry. If both modes fail, check the active configuration, main proxy group, and proxy itself. Restore Rule mode after the comparison so later requests do not continue using the global policy.

You can also run a recovery test: disable the system proxy or disconnect the mobile connection, confirm that the client status and system connection indicator change together, then reconnect. This checks whether permissions and switches work repeatedly. If a desktop browser still points to the local port after the system proxy is disabled, inspect the system network settings for a leftover proxy entry. If the mobile icon remains after disconnecting, check whether another VPN app has taken over the connection.