Clash Quick Start: From Subscription Import to Connection Verification

Prepare the client, subscription URL, and system permissions

Before you begin, install a Clash client compatible with your system and prepare a working subscription URL. Usually provided by your service provider, the URL contains nodes, policy groups, and routing rules. It is not a single node name or a client download link. When copying it, select everything from the first character to the last, without extra spaces, line breaks, or Chinese punctuation.

If you have not installed a client yet, visit the client download page, then choose the Windows, macOS, Android, iOS, or Linux tab. Desktop clients usually call the configuration area “Profiles,” “Config,” or “Subscription.” Mobile clients may place it behind an add button in the top-right corner, on the configuration page, or in subscription management. Names vary, but all require three things: enter the subscription URL, download the configuration, and set the downloaded configuration as active.

The first time you enable the system proxy or TUN, the system may request administrator access, VPN configuration permission, or network-extension permission. Approve the request in the system dialog; otherwise, the client may appear to be running while traffic from other apps remains unmanaged. Company devices, school devices, and managed phones may restrict these permissions. Check the device policy before continuing.

This guide assumes a graphical client. If you use the mihomo core directly, a container, or a systemd service, configuration paths, startup arguments, and control interfaces may differ; see the Advanced Configuration Guide. Once ready, keep the client open and go to the configuration or subscription page.

Import a Clash Subscription and Set It as Active

Copy the complete subscription URL, then open the client’s “Config,” “Profiles,” or “Subscription Management” page. Look for an option such as “Import from URL,” “New Subscription,” or “Download from URL.” Some clients show a plus button first, which reveals the URL field; others also ask for a name. The name is only for local identification, so you can use a service name or purpose such as “Daily Config.” It does not affect the subscription content.

Paste the address into the URL field, then click “Import,” “Download,” or “Save.” The client will request the remote configuration and parse its YAML content. Normally, a new entry appears in the configuration list after a few seconds, often with an update time, refresh button, or enabled indicator. Do not leave immediately; first check for format errors, network timeouts, or download-failure messages.

Once the configuration appears, click its name, radio button, or “Set Active” control to make it current. Downloading without enabling it is the most common first-time setup mistake: the subscription is saved in the client, but the core is still reading the default or previously used configuration. After activation, the Proxies page usually shows groups such as “Node Selection,” “Auto Select,” or “Fallback.” If it remains empty, return to the configuration list and confirm that the current entry is selected.

Next, perform a manual update. Find the refresh button beside the configuration or choose “Update Subscription,” then wait for it to finish. This confirms that the URL still works and helps you find the update control for later use. Do not click repeatedly during the update; repeated requests can make the interface appear stuck or overwrite the latest status message.

If the subscription download fails, paste the URL into a browser address bar to check whether it returns a response, then make sure a chat app did not truncate it. If it downloads but reports a YAML format error, the subscription provider usually needs to fix the content; repeatedly retrying in the client will not help. For more error mappings, see Installation, Configuration, and Troubleshooting in the FAQ. Once the configuration is active, continue to proxy mode settings.

Choose a Proxy Mode, Policy Group, and Node

Open the client’s “Mode,” “Mode,” or “Operating Mode” settings. Clash commonly offers Rule, Global, and Direct modes. For first-time use, choose Rule mode: the client evaluates each request against the configuration rules to decide whether it should connect directly, be rejected, or be sent to a policy group. This preserves direct connections for local services while routing proxy-dependent destinations through the proxy chain.

Global mode sends most manageable traffic through the global policy and is useful for temporarily ruling out rule-matching problems, but it is not ideal as a permanent setting when you do not understand the configuration. Direct mode connects to destinations without a proxy and is useful for pausing proxying or running comparison tests. Depending on the client, the mode may be in a home-screen dropdown, tray menu, or settings page. After selection, the current mode name should change immediately.

With the mode set, open “Proxies,” “Proxies,” or “Policy Groups.” This is not simply a list of nodes; it contains policy groups organized by the configuration author. A group named “Node Selection,” “Proxy,” or “Manual Selection” may contain multiple nodes, latency-test groups, and fallback groups. Open the main policy group first, then choose a clearly available node. If the configuration provides an “Auto Select” option or a url-test group, you can use it to let the client select from the group’s candidates.

After choosing, watch the policy-group page: the active node usually has a checkmark, highlight, or status label. Some clients provide a latency-test button that checks candidate reachability. The latency only indicates whether the test target was reachable at that moment and gives a rough round-trip time; it does not represent the actual speed of every website. For the first connection, simply confirm that the node is not timing out—there is no need to chase the lowest number.

If the page contains groups for different purposes, such as streaming, messaging, downloads, or unmatched traffic, keep the subscription’s default selections at first and adjust only the primary manual-selection group. Changing too many groups at once makes later verification difficult. Policy-group types, rule order, and the differences between url-test, fallback, and load-balance belong to advanced configuration; read the Policy Groups Configuration section after this connection works.

The configuration is now loaded, and the operating mode and node are selected. The next step is to start the core and send system traffic through the client.

Start the Client and Enable System Proxy or TUN

Return to the client home screen and confirm that the core is running. Clients may use a “Start,” “Start,” or “Run” switch, or start the core automatically when the app opens. When running successfully, the home screen usually shows connected, running, or the current port. If it quickly returns to stopped, check the logs for startup errors. Common causes include an unparseable configuration, a port already in use, or insufficient system permissions.

Once the core is running, desktop users can enable “System Proxy,” “Set as System Proxy,” or an equivalent switch. It writes the proxy address to the operating system settings, so browsers and apps that read the system proxy usually start using it immediately. macOS may request the system password the first time network proxy settings change; Windows may take a moment to update already-open apps. After enabling it, close and reopen the browser window used for testing so it does not reuse an old connection.

Android and iOS clients generally use the system VPN interface to handle traffic. After you tap the connect button, the system displays a VPN configuration confirmation. Approve it, and a VPN indicator usually appears in the status bar. The indicator means the system has handed traffic to the client; it does not mean every destination must use a proxy node. Clash rules and policy groups still determine whether traffic goes direct or through a proxy.

If you also need to handle traffic from desktop terminals, games, virtual machines, or apps that ignore the system proxy, consider enabling TUN mode. TUN creates a virtual network interface and handles traffic at a lower level, usually covering more applications than the system proxy. It requires additional permissions and is more vulnerable to interference from other VPNs, virtual adapters, and security software. For first use, verify the browser with the system proxy first; switch to TUN only when you confirm that the target app does not read the system proxy.

System proxy and TUN usually should not both be used for the first test. Start with the simpler system proxy to reduce permission, routing, and DNS variables. Once the basic path works, decide whether TUN is needed based on application coverage. If TUN is required, enable it, grant administrator or network-extension permission when prompted, and wait for the status to stabilize. Do not switch it repeatedly while starting.

The client should now be ready to handle traffic, but an enabled switch is not the final confirmation. The next step is to use real requests, connection records, and logs together to confirm that the rules are actually taking effect.

Send a Test Request and Verify the Proxy

Open a new browser window and visit a destination that normally uses the proxy policy. A page loading is only a first-level result: browser cache, existing connections, or a destination that is directly reachable can affect the outcome. A more reliable method is to open the client’s “Connections,” “Connections,” or “Logs” page at the same time, refresh the test site, and watch for its domain.

Find the request you just made in the connection records and inspect its matched rule, policy group, and final route. If the domain entered the expected policy group and that group used the node you selected, the path from rule evaluation to node connection is working. If the record shows DIRECT, the current rule classified it as a direct connection; that is not necessarily a fault, so consider the destination and subscription rules. If it shows rejected or timed out, check the destination address and error type in the logs.

Next, test two types of destinations separately: a local service that should normally connect directly and an external service expected to use the proxy. In Rule mode, both can work normally while appearing differently in the connection records. This comparison is more useful than checking only the exit address because it confirms that rules are not mistakenly sending all traffic through one path.

If the browser works but the terminal, game, or another app produces no connection records, that app probably does not read the system proxy. Terminal tools may require separate proxy environment variables, and some apps use their own network stack or may need TUN for interception. Do not immediately delete the subscription or reinstall the client. First identify whether the issue is in the subscription configuration, client core, system traffic interception, or the individual app’s settings.

If no app can connect, check in reverse order: close the test page and confirm that the core is still running; check for the system-proxy or VPN indicator; make sure the mode is not Direct; choose another reachable node in the main policy group; then manually update the subscription. Change one item at a time and send a new request after each change so the connection records reveal what changed.

Common log messages such as dial tcp timeout, connection refused, and dns resolve failed point to different stages and should not be handled the same way. If changing nodes does not help, or nodes remain unchanged after a subscription update, visit the Troubleshooting FAQ and continue based on the observed symptoms. For DNS, Fake-IP, TUN routing, and domain sniffing, move on to the advanced documentation.

Keep a Stable Configuration, Then Explore Advanced Features

Once the basic connection works, keep the current mode, main policy group, and traffic-interception method unchanged rather than enabling every advanced switch at once. For daily use, update the subscription periodically, change the main policy group when a node becomes unreachable, and watch the client logs for persistent errors. Record any local overrides before updating the subscription so a remote update does not make you think your settings were lost.

If you need terminal, virtual-machine, or game traffic to enter the client reliably, learn more about TUN and system proxy differences. For domain-resolution problems, study DNS, Fake-IP, and fallback resolution. To route different websites through different policies, understand rule order, rule sets, and policy-group types. These topics are related, but you do not need to change them all during first-time setup.

The Advanced Configuration Guide organizes policy groups, rule sets, DNS, TUN, domain sniffing, local overrides, and external control panels into separate sections for reference after basic connectivity is working. If you are dealing with one specific issue—such as a failed subscription update, an inactive system proxy, or repeated node timeouts—go directly to the FAQ.