Clash Tutorial

After opening the client, look for the “Subscription,” “Configuration,” or “Profiles” page. It usually lists local and remote profiles and offers buttons for adding, pasting, importing from a URL, or creating a subscription. Choose Import from URL and paste the complete subscription address you copied. If a name is required, use the service name or purpose, such as “Daily profile,” to distinguish multiple subscriptions later. The name is only for local identification and does not change the subscription content.

Confirm the address, then click “Import,” “Add,” or “Download.” The client fetches the remote configuration and passes it to the core for parsing. Normally, a new record appears in the profile list with an update time, file size, or status. Some clients do not enable an imported profile automatically; click it once more or choose “Set as current profile” from its menu. Then open the proxy page, where you should see several policy groups and node names within them.

Seeing a node list does not mean a connection has been established; it only shows that the client has read the configuration. Run one manual update now by clicking the refresh button beside the profile or choosing “Update subscription,” then wait for it to finish. This confirms that the URL still works and prevents cached content from being mistaken for a fresh import. If automatic update intervals are available, configure them after the basic connection succeeds. For the first setup, keep the default to reduce variables.

If no entry appears after importing, paste the URL into a plain-text editor and check that its beginning, ending, and parameters are intact, then retry in the client. Errors such as “format not supported,” “parsing failed,” or YAML-related messages usually mean the response is not a readable client configuration or contains fields unsupported by the current core. Do not switch repeatedly between clients to hide the problem; first confirm the format in the subscription management page. For configuration structure, subscription conversion, and multi-subscription merging, see the advanced configuration guide.

After the subscription loads, open the “Proxy,” “Proxies,” or “Mode” page. Clash commonly offers three operating modes: Rule, Global, and Direct. For initial setup, choose Rule mode: the client follows the configuration’s rules to decide whether each request uses a proxy, connects directly, or goes to a policy group. Rule mode preserves direct access for local websites and LAN addresses while sending requests that match proxy rules to the selected node, making it a practical daily starting point.

Global mode sends most eligible traffic to the selected global policy. It is useful for briefly checking whether a node connects or whether a problem comes from rule matching, but it is not ideal as a long-term default when you do not know where traffic will go. Direct mode bypasses proxy nodes and is useful for pausing the proxy or comparing network behavior. Switching modes changes traffic decisions; it does not replace the system proxy or TUN switch. After choosing a mode, complete the connection step.

After selecting Rule, review the policy groups on the page. They may appear as a dropdown, horizontal tabs, or an expandable node list. Find the group responsible for choosing the main traffic route; it is usually near the top and may be called “Node Select,” “PROXY,” “Manual Select,” or a provider-defined name. Open it and choose a specific node, or select a configured sub-policy such as “Auto Select” or “Failover.” If the client offers latency testing, run one test for reference. Test results represent the response from this device to the target at that moment, not the actual speed of every website.

The configuration may also contain policy groups for streaming media, messaging, ad rules, and “final” traffic. During initial use, leave these defaults unchanged and only confirm that the main policy is not DIRECT or REJECT. Changing too many policies makes troubleshooting difficult: when a request fails, it becomes unclear whether the node is unavailable, another group matched the rule, or a sub-policy selected a direct route. After choosing the main policy, stay on the page for a few seconds and confirm there are no repeated connection-test errors before continuing.

Return to the client home or settings page and check the core status first. Clients may label the control “Start,” “Service Mode,” “Core,” “Mihomo,” or show a power-style button. After startup, the status area should indicate that the core is running, and a local port should begin listening. If logs are available, open them and confirm there are no repeated errors such as configuration-load failures, port conflicts, or insufficient permissions. The system proxy and TUN can forward traffic only when the core is running normally.

Next, enable “System Proxy” or “Set as system proxy.” This points the operating system’s HTTP and HTTPS proxy settings to the local port monitored by the client. Most browsers and desktop apps that follow system network settings will then use Clash. Windows and macOS clients can generally toggle the system proxy directly; Android and iOS clients usually capture traffic through system VPN authorization, and the first activation shows a confirmation dialog. After approval, a VPN indicator appears in the status bar. Linux desktop support depends on the distribution and application; some command-line tools still require separate environment variables.

After enabling the system proxy, do not immediately change DNS, ports, or rules. Keep the client in the foreground for several seconds while existing browser connections close or reconnect. Then open a new browser window for testing so an old tab does not reuse a connection created before the proxy was enabled. A browser extension or manual proxy setting can override the system proxy; for the first test, use only one capture method to avoid port and proxy-chain conflicts.

When to Use TUN Mode

Some applications do not read system proxy settings, including certain command-line tools, game launchers, and software with an independent network stack. These cases may require TUN mode, which uses a virtual network interface to capture a broader range of TCP, UDP, and DNS traffic. TUN involves system permissions, routing tables, DNS interception, and interface selection, so its troubleshooting scope is much larger than that of a system proxy. This tutorial does not treat TUN as necessary for the first connection: verify the node, subscription, and rules with the system proxy first, then enable TUN so any new issue can be attributed to the capture layer.

If TUN is genuinely required, disable other VPNs and similar network tools, follow the client’s instructions to install its service component or grant permissions, and then enable TUN. Revisit the test websites and check the connection log. If LAN devices become unreachable, DNS behavior changes, or the network breaks after sleep and wake, see the TUN and Fake-IP section of the advanced guide for a systematic explanation of routes, interfaces, and DNS.

Once connected, use a newly opened browser window to visit a regular website that normally works directly, followed by a destination that requires a proxy. This checks both direct and proxy rules. Testing only one website can mislead you because the page may be cached or the site itself may be down. Test at least two different sites and create fresh requests by refreshing or opening new pages.

Then return to the client’s “Connections” or logs page. Normally, each new request appears in the connection list with its domain, destination, matched rule, policy group, and actual node. If the regular site shows DIRECT while the target shows a proxy policy and node, Rule mode is routing traffic as expected. If the browser can open pages but the connection list has no new entries, the browser is probably bypassing the current client. Check the system proxy, any browser-specific proxy, and whether the client is still running.

You can also compare Direct and Rule. Record the result in Rule mode, switch briefly to Direct, and reopen the target page; restore Rule immediately afterward. If both modes produce identical results and connection records, check whether system capture is actually active. If Global works but Rule does not, the node is usually reachable; the issue is more likely rule matching, policy-group selection, or DNS resolution, so reinstalling the client repeatedly is unnecessary.

After verification, keep the working configuration as a baseline. Do not immediately enable TUN, custom DNS, script overrides, and multiple-subscription merging at once. Change one thing at a time and rerun the three checks—regular website, target website, and connection record—after each change. If a later change causes trouble, you can revert the latest change quickly instead of reinstalling the client or clearing every profile.