Clash Quick Start: From Subscription Import to Connection Verification

Before You Begin: Confirm the Client and Subscription URL

Before starting the initial setup, select a graphical client that matches your operating system from the client page. Windows and macOS users generally benefit from clients with a visual interface. Android users should confirm that the system allows the app to establish a VPN connection. iOS users need an available client from the App Store and should be ready to authorize the proxy. Linux users can choose a GUI client suited to their desktop environment, while server and router users can refer directly to the Mihomo core documentation. Client versions, menu names, and permission prompts vary by platform, but the basic logic for importing a configuration and verifying the proxy remains the same.

You also need a valid subscription URL. Service providers usually generate one on the account page. It may be a long URL beginning with https://, or the address associated with a button for copying a subscription link. Copy the complete value—do not copy only the truncated text shown in the browser’s address bar, and do not mistake the web login URL for a subscription URL. If multiple formats are offered, choose the configuration link explicitly labeled Clash, Clash Meta, or Mihomo. Subscription content usually includes proxy nodes, proxy groups, and rules; the client simply reads and applies this configuration.

When using a public computer or someone else’s device, do not post the subscription URL in group chats, screenshots, or public documents. The URL is an account configuration entry point, and disclosure may allow others to use your traffic allowance. This guide does not require an account password. Once the client is installed and the subscription URL is copied, continue to the next step. If the URL comes from an unknown source or contains spaces after copying, return to the provider’s page and copy it again before troubleshooting the client.

After preparation is complete, leave the client’s proxy disabled. This makes it easier to distinguish between importing the configuration and activating the system proxy. Next, save the subscription in the client, confirm that the file can be read, and then choose a mode and node.

Step 1: Import the Subscription Configuration

Open the client’s main window and find a page named “Configuration,” “Subscription Manager,” “Profiles,” or something similar. Desktop clients usually place it in the left navigation bar, while mobile clients may put it in a configuration card on the home screen or in the top-right menu. First check whether configuration files already exist. If the list contains an old configuration, do not overwrite the one currently in use. Create a new subscription entry instead, so the working configuration remains available if the update fails.

Paste the complete URL into the subscription field, then click “Add,” “Save,” “Import,” or “Download Configuration.” Some clients split this into two actions: save the subscription URL first, then click the update button beside the entry. Wait for the network request to finish until the list shows a configuration name, update time, or selectable status. The provider may determine the name, or the client may show a domain name or date by default. As long as the entry can be selected, its name does not affect proxy functionality.

If the client asks for a name, use a short, recognizable label such as “Main Subscription” or “Daily Configuration.” Avoid including the full subscription URL in the name. After saving, open the configuration details and confirm that the file is not empty and contains fields related to proxy groups, nodes, or rules. A graphical client may not display the entire raw YAML, but it usually shows the node count, proxy group names, or the latest update time on the configuration card. The goal is to confirm that the client received the configuration, not merely saved a URL.

After the subscription update finishes, make the newly imported configuration active. Some clients switch configurations by clicking the card; others use an “Enable” or “Use” button. Return to the main screen and check whether the proxy group list has changed. If it still says “No configuration selected,” “No proxies,” or shows an empty list, do not enable the system proxy yet. Check the subscription URL, network connectivity, and client logs first. Common causes of update failures include an incomplete URL, a network that cannot reach the subscription service, an obviously incorrect system clock, or temporary request limits imposed by the provider. See the FAQ troubleshooting section for a more detailed sequence.

The import stage is complete once the configuration is active, proxy groups expand, and at least one node appears. The client now has executable routing rules, but it has not yet determined which requests should use the proxy or received system-level proxy permission. Next, choose a suitable operating mode and then select a specific node.

Step 2: Choose a Proxy Mode and Node

Find “Mode,” “Run Mode,” or a similar setting on the main screen. Most Clash clients offer three common modes: Rule, Global, and Direct. For first-time use, Rule mode is usually the best starting point. The client uses domain, IP, and process rules from the configuration to determine the route. Requests matching proxy rules enter a proxy group, which suits everyday browsing; unmatched requests follow the configuration’s fallback rules. The actual result depends on the subscription, and rule coverage varies between providers.

Global mode routes most requests through the currently selected proxy group. It is useful for quickly checking whether a node connects or for short tests when the rules are incomplete. Because it can change the access path for more applications, avoid using it long term unless you understand the configuration. Direct mode sends requests straight to their destinations and is useful for determining whether a problem comes from the proxy path. Changing modes does not alter the subscription or delete nodes; it only changes how the client handles requests.

After choosing a mode, open “Proxy,” “Proxies,” or the proxy group page. You may see groups such as automatic selection, fallback, region-based groups, or manual selection. Open the top-level proxy group first and confirm that selectable nodes are present. If it shows “Not selected” or only empty entries, return to the configuration page and update the subscription again. When choosing a node, prioritize consistent availability rather than a single test result. Region, route, and multiplier details in node names are provider labels; actual usability still requires a real connection test.

If the client offers “Speed Test,” “Latency Test,” or “URL Test,” run one to help filter the nodes. Remember that the latency value represents only the specified test URL and the route conditions at that moment. After testing, choose a node with a healthy status and relatively stable latency. Do not switch repeatedly just to chase the lowest number: packet loss, exit region, target-site response, and local network quality also matter. For the difference between test results and real-world performance, read How Clash Latency Tests Work.

After selecting the mode and node, return to the main screen and confirm that the configuration name, operating mode, and proxy group state are saved. Some clients reset the proxy group selection after a configuration switch, so you may need to select the node again. If the node you chose is no longer selected, choose it again before enabling the system connection. This prevents a situation where the client says it is running but requests have no defined exit path.

Step 3: Enable the System Proxy and Establish a Connection

Return to the client’s home screen and find the “System Proxy,” “Start,” or power-style switch. Desktop clients usually place this control at the top of the home screen or in the status bar. When enabled, the system forwards requests from apps that support system proxy settings to Clash’s listening port. Windows and macOS may request administrator authorization; Android usually shows a VPN connection prompt; iOS may ask for permission to add a VPN configuration. Follow the system prompts, then return to the client and wait for the status to change to “Running,” “Started,” or a similar state.

The system proxy and the client process are separate layers. A running status only means that the core has started. Whether a browser or another app uses it also depends on the system proxy switch, the app’s own proxy settings, and system permissions. During first-time setup, disable browser proxy extensions, other VPN software, and third-party network accelerators to prevent multiple programs from changing the system proxy at once. If Android has battery restrictions enabled, the system may pause the VPN service in the background. Keep the client in the foreground during verification, then add it to the device maker’s list of apps allowed to run in the background.

After enabling the system proxy, watch the client’s status information and log area. Normally, logs show connection records after the browser sends requests. Records may include the destination domain, matched policy group, and connection result. Do not copy subscription content, account information, or complete URLs from the logs to public locations. If the system switch cannot be enabled, check that another VPN is not using the permission. If it turns off immediately, check whether the system denied permission, whether battery controls paused the client, and whether the current configuration can start normally.

On desktop systems, test with just one browser window while keeping other applications closed. This makes it easier to match new log entries to the page you just opened. On Android and iOS, begin by visiting an ordinary website that normally loads reliably, then check the client status. Avoid starting with a complex site that depends on special DNS behavior, login verification, or extensive scripts. Once the connection is established, the final step confirms it through the page result, client logs, and proxy settings.

If you need TUN mode to take over apps that do not follow the system proxy, complete the basic verification in this guide first, then read the TUN section of the user guide. TUN involves system permissions, routing tables, and DNS handling. Enabling it during initial setup adds variables and is not the best first step for diagnosing subscription or node problems.

Step 4: Verify That the Proxy Is Really Working

Open a familiar browser page and visit a website that normally loads reliably. A page loading successfully only shows that the basic connection is not blocked; it does not by itself prove that the request passed through the expected node. Switch back to the Clash client and inspect the logs or connection list for the domain request generated by that page. Confirm that a rule matched it and that the final policy group is the one you selected, rather than Direct or Reject. If the client supports viewing rule matches by domain, open the corresponding record for more specific details.

Next, check the system proxy status. On Windows, confirm in the system network proxy settings that the client wrote the manual proxy settings. On macOS, check the proxy entries for the current network service. On Android and iOS, look for the VPN icon or the client’s connection status. Display details vary by system, but the essential checks are the same: the client is running, system permission has been granted, browser requests appear in the logs, and the policy result matches the selected mode. Only when all four are true can the basic proxy path be considered established.

If the page loads but the corresponding request is missing from the logs, the browser may be using its own proxy settings, QUIC, or another independent network path. The system proxy may also not be active. Disable any proxy extension configured inside the browser, then reopen the page. If requests appear in the logs but all show Direct, check whether the client is still in Direct mode or whether the rules matched the domain to DIRECT. If a request shows a proxy but the page does not load, test another node and inspect the error type in the logs. Connection timeouts, TLS errors, and DNS resolution failures require different troubleshooting approaches.

If only some websites behave incorrectly, do not reinstall the client immediately. In Rule mode, different domains may enter different policy groups. Check the relevant group on the proxy page and confirm the domain match on the rules page. If no domains are accessible, focus on the node, subscription update time, system clock, and network permissions. If only one app bypasses the proxy, first confirm whether it follows the system proxy. If it does not, consider TUN or app-level proxy settings. For Fake-IP, DNS and Routing, or LAN access, read the DNS and Routing section directly instead of changing parameters on multiple settings pages at once.

After verification, keep the current configuration, mode, and node selection, disable unnecessary debug logging, and record the name of the node that worked. When connection problems occur later, repeat the same four checks: was the configuration updated, is the mode correct, is the system proxy enabled, and do the logs show requests? Following this order usually locates the cause faster than repeatedly changing clients or deleting every configuration. If subscription updates fail, permission prompts keep reappearing, or the system proxy is continually overwritten, visit the FAQ. To understand rule order, policy groups, and core parameters, continue with the complete user guide.

Four Checks After Setup

When first-time setup is complete, use this order for a quick review. First, the current configuration list contains the newly updated subscription and it is enabled. Second, the operating mode matches your needs; for everyday use, start with Rule mode. Third, a healthy node is selected in the proxy group. Fourth, the system proxy or VPN permission is enabled and browser requests can be found in the client logs. When all four checks pass, the basic setup is complete.

• Subscription has content: Proxy groups, nodes, or rules display normally, and the update date is not obviously outdated.
• Mode confirmed: The client is not accidentally left in Direct mode, and you remembered to switch back to Rule mode after testing.
• Node selectable: The current policy group is not empty, and the selected node is not continuously reporting errors or timing out immediately.
• Requests traceable: When the test page opens, the client logs show the corresponding request and a reasonable policy result.

These four checks cover only the basic connection. They do not mean that every app follows the system proxy or that every rule behaves as expected. To proxy games, command-line tools, virtual machines, or LAN devices, first confirm that the basic path is stable and then handle each case separately. For deeper configuration, start with the complete guide from beginner to advanced. For a single specific issue, the troubleshooting page is usually faster.