Clash Tutorial

Before you begin, prepare two things: a Clash GUI client for your operating system and either the subscription URL provided by your service or a local YAML configuration file. A subscription URL is usually a link beginning with https://; it lets the client fetch proxy nodes, proxy groups, and routing rules. A local profile uses the .yaml or .yml extension. Choose one source—there is no need to import both.

Start the client and check that the main interface loads completely. Desktop clients usually list Home, Proxies, Profiles, Connections, and Settings in a sidebar; mobile clients may place these entries in bottom navigation or a side drawer. Do not enable the system proxy yet. Without a usable profile, the client may be running but still lack the information needed to decide which proxy group should handle traffic.

If the client asks you to choose a core or download runtime components on first launch, wait until the status shows that it is ready before opening the profile page. Clients built on the mihomo core can usually read common Clash configurations, but support for overrides, scripts, external rule sets, and TUN parameters varies. The goal of the first setup is simply to establish a verifiable connection, so keep the default settings and avoid changing DNS, ports, and routing at the same time.

Finally, make sure the system time and time zone are reasonably accurate. Certificate connections, subscription requests, and some authentication flows rely on the system clock; a large time difference can look like a failed subscription update or an interrupted node connection. Once ready, open the client’s profile page and begin step one.

Find Profiles, Subscription, or Configuration in the client’s sidebar or bottom navigation. The page usually includes a URL field and an Import, Download, or Update button. Copy the complete subscription URL, paste it into the field, check that there are no extra spaces at either end, and import it. Desktop clients may ask for a profile name; this is only for local identification. Use a name such as “Daily Rules” or “Mobile Network”—it does not change the subscription.

After you click Import, the client requests the subscription and parses the YAML. Normally, a new item appears in the profile list with its name, update time, or update interval. Do not stop at a “Download complete” message. Click the new profile and confirm that it is marked as active. Some clients select the imported item automatically; others only save it and require you to click Use, Activate, or the selection marker. Only after the active profile changes will the proxy page show the groups from that profile.

For a local YAML file, choose Import from file, Open profile, or the folder button, then select the file in the system picker. Set it as the active profile after importing. Do not casually edit indentation in a text editor: YAML uses spaces to express hierarchy, and shifting list markers, the space after a colon, or field levels can cause parsing errors. To understand the structure, see the YAML manual’s structure overview.

If no new profile appears after importing, first check that the subscription URL is complete. Line breaks added by chat apps, an incomplete copy, or a truncated link can all make the request fail. Copy it again and paste it into a plain-text field to inspect it. If the client reports a timeout, confirm that ordinary websites open on the current network before retrying the update. A format error may mean you received a webpage URL, a login page, or a profile format unsupported by the client; check the source of the profile for the correct entry point.

After a successful subscription update, keep the provider’s original profile for now and avoid creating multiple layers of overrides. During the first connection, minimize variables: one active profile, one clear mode, and one selected strategy are enough to assess the basic path. Now open the proxy page, check the groups, and choose a running mode.

Open the Proxies, Proxy, or Mode page. Common Clash modes include Rule, Global, and Direct. For first-time use, choose Rule mode. Rule mode checks requests against the configuration’s rules from top to bottom: some domains go to proxy strategies, others stay direct, and a final fallback handles requests that matched nothing earlier. This best fits everyday use and makes it easier to see which rule matched each request in the connection log.

Global mode sends most traffic through one global strategy. It is useful for temporarily ruling out rule-matching problems, but it should not replace a long-term rule configuration. Direct mode connects to destinations without a proxy and is useful for pausing the proxy or comparing network behavior. Depending on the client, the mode selector may be at the top of the home page, in the upper-right corner of Proxies, or in Settings. Find Mode, Proxy mode, or Running mode, and select Rule.

Once the mode is set, inspect the proxy groups. A proxy group is not a node; it is a selection layer that organizes multiple nodes or child strategies. Common types include manual selection, latency-based selection, fallback, and load balancing. The page may show names such as Node Select, Proxy, Non-Mainland Traffic, or Auto Select. These names come from the provider and are not consistent across subscriptions. Open the main group and select a clearly usable node, or choose the automatic strategy already configured in the profile.

For the first test, manually selecting one node is usually easier to troubleshoot because the result maps to a single target. With an automatic strategy, the client may switch nodes based on test results; when network performance changes, you must evaluate both the automatic test and the real connection. After the basic connection is confirmed, switch back to Auto Select if that suits your normal use.

After selecting a node, check whether the current choice appears beside the group name. Some clients offer latency tests in the node list, but a test only shows whether the client completed that probe; it does not guarantee that every website or app will work. Do not judge the final state by one number. Confirm it in step four using both browser requests and connection logs.

If every proxy group is empty, only DIRECT appears, or the proxy page is unchanged from before the import, the new profile probably is not active. Return to Profiles, select the item you just imported, and then revisit Proxies. If the client reports that certain fields cannot be parsed, check the proxy group fields section. You do not need to manually rewrite the entire profile for a first setup.

After confirming the active profile, Rule mode, and main proxy group, return to the client’s home page. On desktop, enable System Proxy, System Proxy, or Set as system proxy. This points the operating system’s HTTP or SOCKS proxy to the local port Clash is listening on. Once enabled, browsers and apps that follow system proxy settings send requests to the client, which then uses rules and proxy groups to determine where they go.

Windows clients usually change the system proxy directly; macOS may ask you to confirm network service permissions; on Linux, automatic system proxy setup depends on the distribution, desktop environment, and client. If a Linux client does not configure it automatically, enter the listening address and port shown by the client in the system network settings. The common address is 127.0.0.1; use the mixed-port, HTTP, or SOCKS port shown in the client’s Settings rather than copying a number from another tutorial.

Android and iOS clients usually take over traffic through the network connection interface provided by the operating system. On first connection, the system displays a permission prompt; after approval, a network connection indicator may appear in the status bar. If permission is denied, the client’s button may look enabled even though the system has not created a connection. Allow it again in system settings or start the connection request once more in the client. After granting mobile permission, keep the default routing and DNS settings and continue with the basic verification.

After enabling the switch, check whether the client shows Connected or Running, and see whether requests begin appearing in Connections. A running client process, an enabled system proxy, and a valid profile are separate layers: an open client window only means the program started; an enabled system proxy means the operating system points to the local listening port; forwarding still depends on the profile, strategies, and node status. Check each layer in order instead of attributing every symptom to the node.

If the system proxy switches off immediately, the client may lack permission to change system settings or the local listening port may not have started. Open Settings and check the port status and logs. If another program occupies the port, close that program or change Clash’s listening port; then make sure the system proxy points to the same new port. For process identification and field changes, see How to resolve a Clash listening port conflict.

Once connected, do not immediately change nodes, DNS, and rules in bulk. Keep the current state, open a new browser tab, and move to the next step. Verification checks webpage access, connection logs, and rule matches together to confirm that requests actually use the strategy you selected.

Open an ordinary website that normally works in your browser to confirm that basic connectivity remains intact with the proxy enabled. Then open a destination that should use a proxy strategy. A loaded page is only the first signal; return to the client’s Connections, connection log, or Logs page and find the domain request just created. Normally, the entry includes the destination domain, matched rule, proxy group, and final node or DIRECT result.

When reviewing rule matches, confirm two things: whether the request entered the expected proxy group and whether that group used the node you selected. If the log shows DIRECT, a direct rule matched the request. If it shows a proxy strategy but the page still fails, check the node connection, DNS resolution, or destination service. Separating “how the rule routes traffic” from “whether the node can connect” prevents endless profile switching without addressing the cause.

You can also use a browser-based network egress check as supporting evidence. Record the egress information before enabling the proxy, then connect, refresh the page, and compare the result. Rule mode may keep some test sites on a direct route, so an unchanged egress does not necessarily mean the client failed. Use the connection log as the authority: if the lookup domain matched DIRECT, temporarily switch to Global mode for comparison and return to Rule mode afterward.

After basic verification passes, perform a short restart test. Disable the system proxy or disconnect on mobile, then exit the client. Restart it, confirm that the active profile, Rule mode, and strategy selection were retained, and reconnect. Some clients offer Start on boot and Restore system proxy on startup. Enable them only if they fit your workflow. With automatic restoration enabled, check that the client is running whenever the network fails; otherwise the system may still point to a local port with no listener.

The first-connection workflow is now complete. In daily use, check whether proxy groups change after a subscription update. When switching networks, compare mobile data and Wi-Fi by reconnecting and reviewing the logs instead of reinstalling the client. For DNS, rule sets, overrides, merges, or node fields, open the Clash YAML configuration manual. Adjust these items one at a time after the basic path is confirmed.

If verification fails, keep the current profile unchanged and check the following in order. First, check the profile state: return to Profiles, confirm the subscription update completed without errors, and verify that the imported item is active. Second, check the strategy state: open Proxies, confirm Rule mode is selected, make sure the main group is not empty, and verify that a current node is selected. Third, check traffic takeover: on desktop, confirm System Proxy is enabled; on mobile, confirm that system connection permission was granted.

Once the first three checks pass, inspect the local listener. Open Settings and note the mixed-port, HTTP port, or SOCKS port. The system proxy address should normally point to the local machine, and its port must match the value the client is actually listening on. If you changed the port but the system proxy still uses the old value, the browser sends requests to an inactive port and every page fails after proxy activation. Align the two ports, then disable and re-enable the system proxy.

If the connection log contains no browser requests at all, the issue is usually in the system proxy, the app’s own proxy settings, or the TUN takeover layer. If requests appear but all match an unsuitable strategy, inspect rule order. If requests reach the expected proxy group but connections fail, test another node in the same group. This sequence checks the path from entry to exit, and changing one condition at a time preserves a clear comparison.