Clash Setup Guide

Step 1: Import a Subscription and Enable the Config

Start with a subscription URL or local YAML file provided by your config source. The client reads the config, runs the core, and routes traffic; installing the client alone does not provide usable proxy nodes. A subscription URL is not the source website’s homepage: it should return config content the client can parse. If the source offers multiple formats, choose one explicitly supported by your Clash client or the mihomo core. Don’t rename raw text intended for other software and import it as a config.

Open the client and go to “Config” or “Subscription.” Look for “Add,” “Import,” or a plus button. Choose URL import and paste the complete address into the subscription link field. The name is for local reference, so use a short label that helps identify the source. Check for spaces, line breaks, or punctuation added by a chat app, then click Download or Save. Wait for the import to finish; don’t submit repeatedly, or you may end up with several hard-to-distinguish configs.

After a successful download, the config list will usually show a new entry. Select it, or use the adjacent “Enable” or “Use” option to make it the active config. Some clients enable imported configs automatically; others only save the file. Check which entry is selected rather than relying on a “Download complete” message. Then open the “Proxy” page and confirm that the config’s strategy groups are listed. If you see a file entry but none of the expected groups, return to the config page and check the active selection and any error messages.

To import a local file, choose “Import from file” on the same page, locate the saved .yaml or .yml file, and open it. File import usually saves a local copy; it does not set up remote updates. If the source changes its nodes, import the file again or use the subscription option provided by the source. Don’t treat a single node section in a file as a complete config; for first-time setup, use a complete compatible config from the source.

Import failed? Check the response first

If the download times out, the format is invalid, or loading fails, note the exact error message. Check whether the device can connect to the internet with the proxy off, then confirm the subscription URL hasn’t expired and copy it again from the source page if needed. A login page, error page, or unsupported format can all cause a parsing failure. If the client offers a “Update via proxy” option but no working connection is set up yet, use a direct update if your network allows it. That way, the update request won’t depend on a proxy that isn’t running.

Subscription links may contain account identifiers, so protect them like login credentials. Don’t post a full URL, QR code, or complete config in public comments when troubleshooting. If you need to document an error, share only its type and a screenshot with sensitive details hidden. For subscription formats and update issues, see the FAQ. For now, continue with the connection setup.

Make sure updates won’t overwrite local changes

After the first import, you can run “Update” once to confirm the source is reachable. For now, avoid making extensive edits to the downloaded config itself, since a later update may replace them. If you need to change DNS, rules, or ports, first learn how your client handles overrides; see the mihomo advanced config guide. For this setup, just confirm the config is enabled and its strategy groups are visible, then choose a mode.

Step 2: Choose a Proxy Mode and Strategy Group

Once the config has loaded, return to the client’s home screen or proxy settings and find the mode selector. Common labels are “Rule,” “Global,” and “Direct,” corresponding to rule, global, and direct in the core. For your first setup, choose rule mode so the config’s rules determine which strategy handles each request. Don’t turn on multiple network switches just to make the connection seem more comprehensive: mode controls how traffic is handled after it enters the core, not whether apps send traffic to it.

In rule mode, requests are matched against the config’s rules in order, and the first match determines the strategy. For example, one domain might use a proxy strategy group while other requests use DIRECT. The routing depends on your current config; not all subscriptions use the same rules. After choosing rule mode, open “Proxy” or “Strategy Groups” and check where the main groups used by the rules are pointed.

In a manual selection group, choose an available node provided by the source, or select the config’s automatic selection group. Group names are defined by the config and might be “Proxy,” “Node Selection,” or something else; there’s no single name to look for. If a group lists other groups, check the selection in the lower-level group too. If the parent group points to direct, changing a node in a different, unused group won’t change the request’s actual route.

If the client offers a connectivity test, run it to help choose a node. A successful test means a connection could be established under that test’s conditions; it doesn’t guarantee that every website or protocol will work. A timeout might also be caused by the test endpoint. Start with a node that can handle basic access, then verify the actual requests in Step 4 rather than relying only on a test result or latency number.

Use global mode for comparison, not as a substitute for traffic routing

If a site fails in rule mode, temporarily switch to global mode, check which node the global strategy actually selects, and try the request again. If global works but rule mode doesn’t, check the matched rule and strategy group instead of immediately changing DNS. Switch back to rule mode after testing so requests that should connect directly don’t go through the proxy.

Global mode does not mean that all traffic on your device is being proxied. Apps that ignore the system proxy may still bypass the core; consider TUN only if you need broader traffic routing. Likewise, direct mode doesn’t close the client: system proxy or VPN routing may still be enabled. With that distinction in mind, keep rule mode and your selected strategy, then focus on how to route app requests into the core. For more on rules and group types, see the strategy group configuration section.

Step 3: Enable the System Proxy or Mobile VPN

First, make sure the client has no config loading errors and that the home screen shows the core running or the connection button ready to start. An enabled config, a running core, and traffic routing are separate steps: without a running core, requests can’t be handled; without traffic routing, your browser may continue using its regular connection. Don’t enable the system proxy, TUN, and another VPN all at once. Starting with one routing method makes it easier to see what’s working.

Desktop: Start with the System Proxy

In your Windows, macOS, or Linux client, find and enable “System Proxy.” Some clients ask for system permission first; follow the prompt and then check that the switch stays on. You usually don’t need to enter a proxy server address in your browser: the system proxy points to the core’s local listening port, and the core selects a remote exit based on the config.

To check the system settings, make sure the system proxy address and port match the client. A common local address is 127.0.0.1; this site’s example uses mixed-port: 7890, but your client may use a different port. Follow the settings currently in use. If you have a browser proxy extension, set the browser to use the system proxy so the extension doesn’t keep sending requests to an old port. You don’t need to enable LAN access for this first test.

If a port is already in use or the core won’t start, don’t keep toggling the system proxy. First close other proxy clients that may be listening on the same port, then try again. If you change the listening port, update the system proxy port to match. System proxy support varies across Linux desktop environments and apps; a working browser alongside a non-working terminal doesn’t necessarily mean the core is faulty. For this test, use a browser with clear system proxy support.

Mobile: Check VPN Permission and Connection Status

On the Android or iOS client’s home screen, tap “Connect” or the start button. The first time the system asks to add a VPN configuration or establish a VPN connection, make sure the request is from the client you’re using and approve it as prompted. Your device may need to be unlocked. Return to the client, wait for the connection status to update, and check the system’s VPN status. Granting permission only allows the client to route traffic; you still need to verify that the node works with an actual request.

If another VPN is already connected on your device, disconnect it before starting this client to avoid confusion if the system replaces the connection. If your Android client uses per-app proxy settings or a bypass list, make sure the test browser is included in the routed apps. For an initial test, use the client’s default scope and narrow it down after confirming the connection works. Don’t exclude apps in bulk unless you understand what the list does.

After these steps, leave the client running and open a new browser tab. Don’t rely only on “Connected” on the client’s home screen: that confirms the routing path is enabled, but the next step checks which rule and exit handle your requests.

Step 4: Verify Routing in the Connection Logs

Choose two familiar sites you can use for testing: one that your config should send direct and another it should send through a proxy. Open each in a new browser tab, then check the client’s “Connections,” “Active Connections,” or log page. Look for the destination domain or address, matched rule, strategy chain, and final exit. Client interfaces show different fields, but the goal is to match each browser request to the way the core handled it.

If the site opens and you can find the corresponding connection, check that it used the expected strategy. A DIRECT entry means the core chose a direct connection; it doesn’t mean the client isn’t working. If the entry points to a proxy group, expand it or check the final node before drawing a conclusion based only on the parent group’s name. To test a proxy rule, use a domain that should match that rule; opening an arbitrary webpage doesn’t prove that traffic used the proxy exit.

Next, visit a site expected to connect directly and confirm that rule mode handles both types of requests as expected. An optional exit IP lookup can provide supporting evidence, but the lookup site may itself match a direct rule, and browser caching or old connections can affect what you see. After changing nodes, start a new request; if needed, close only the relevant active connection and retry. Don’t export your browsing history or publicly share your connection list just to verify routing.

If results don’t match, troubleshoot in order

If the browser makes a request but the client shows no corresponding connection, check traffic routing first: is the system proxy enabled, does its address and port match, is a browser extension overriding the setting, or is the browser excluded from mobile routing? Some clients show only active connections, so a short request may disappear quickly; check the logs as well. Changing nodes or routing rules won’t usually help if the request never reached the core.

If you can see the connection but it uses the wrong strategy, go back to Step 2 and check the current mode, parent group selection, and matched rule. If the request reached the expected node but still failed, try another available node in the same config and compare the specific errors. Check DNS only if you see signs such as domain resolution failures. Don’t change the mode, node, DNS, and TUN all at once; change one thing at a time and retry the same destination to see what made a difference.

If only one app fails while your browser can connect using the rules, check whether the app follows the system proxy, has its own proxy settings, or falls outside the current routing scope. You don’t need to learn every detail of DNS and Fake-IP for your first connection; see the Fake-IP configuration section if you run into a related issue. For more symptoms and troubleshooting steps, visit the FAQ.

Stop the Client and Restore Your Network

After verification, if you’re done using the client, turn off the system proxy in the desktop client before closing it. On mobile, disconnect the client and make sure the system VPN is no longer active. If you close the process but leave the system proxy pointed at a local port, your browser may keep sending requests to a listener that no longer exists. If webpages stop loading after you exit, check the proxy status in your system network settings and restore the settings you noted earlier. Follow your organization’s policies on managed devices.

Next time you start the client, quickly check in this order: current config → rule mode and strategy → routing switch → actual request. It’s also a good idea to verify the connection after updating a subscription, since the source may change group names or routing rules. That completes the basic workflow from importing a config to checking connection logs. For rulesets, local overrides, or an external controller, go through the advanced guide and configure only what you need; there’s no need to enable everything on your first run.