Before You Start: Get a Client and Compatible Subscription
Install a client that matches your operating system and processor architecture. Make sure your device can access the internet with the proxy off. Still need to download a client? Choose a platform on the Clash client downloads page. Installation permissions, service modes, and package formats for each operating system are covered in the cross-platform installation and setup guide. This guide starts once the client opens.
Next, get the subscription URL from your provider and make sure it uses a Clash- or mihomo-compatible format. A purchase history page or account sign-in URL is not the same as a subscription URL. A subscription usually returns a configuration containing proxies, proxy groups, and rules—not a webpage for signing in through your browser. If you only have individual node links, first check whether your client supports importing them directly. Don't assume every link can be pasted into the subscription field and recognized automatically.
A subscription URL usually contains account credentials, so treat it like a password. Don't post it in public comments, send screenshots showing the full URL to strangers, or upload it to an online converter without good reason. If you need to convert a subscription, first read the subscription notes in Frequently Asked Questions to understand configuration compatibility and the risk of exposing the URL. Before setup, quit other proxy or VPN clients to reduce conflicts between system proxy settings, virtual adapters, and DNS routing.
Step 1: Import a Subscription and Activate the Configuration
Open “Subscriptions” or “Configurations” in the client's sidebar and look for “Add,” “Import,” or a plus button. If you see “Import from URL” and “Import from file,” choose URL for a subscription link. Choose file only if your provider gave you a YAML file. Give the configuration a recognizable local name, then paste the full URL into the subscription field. Check for spaces or line breaks at either end before confirming.
Wait for the import to finish before turning on any other settings. Normally, the configuration list will show a new entry and its latest update status; some clients also show the number of proxies or a completion message. Open the configuration or go to the Proxies page to check that its proxy groups and options are present. If the page is still empty, return to the configuration list and confirm the import succeeded—you may have saved an address without fetching its contents.
If the import fails, check the error for that update. A timeout usually means the subscription service is temporarily unreachable or there's a network path issue. Responses such as 401 or 403 mean you should check the URL and access permissions with your provider. A parsing error may indicate an incompatible format or a login page returned by the server. Don't assume every error means a “bad node”: you haven't reached the node connection stage yet. Note the key error message, and redact URLs and credentials before sharing logs.
Once the configuration appears in the list, click “Use” or “Activate,” or select it as the current configuration. Some clients mark the active entry with a border or selection indicator. If you have multiple subscriptions, make sure the one you just imported is selected, then open the Proxies page to check its groups. A successful download doesn't mean the core has loaded the configuration. Changing settings for a while only to realize another configuration is active is a common first-time detour.
You can refresh a subscription later with “Update”; for now, leave the default update behavior in place. Don't overwrite the remote configuration just to change a proxy group—your edits may be replaced the next time it updates. For persistent rule additions or field changes, see the cross-platform guide for overrides and local configuration. Once the groups appear without loading errors, choose a running mode.
Step 2: Choose a Rule Mode and Proxy Group
Open the Proxies page and find the mode selector for Rule, Global, or Direct. For your first setup, choose Rule. In Rule mode, requests are routed according to the rules in the active configuration; not every site uses the same proxy connection. Global mode sends requests handled by the core through the global policy, while Direct mode bypasses proxy nodes. These modes control how the core handles traffic; they don't make apps send traffic to the core automatically.
Next, expand the main proxy selection group. Its name comes from the subscription configuration and might be “Node Selection,” “Proxy,” or something else; there isn't one label shared by every client. Select an available node in the group. If you selected another group, expand it and make sure the final choice is an actual node, not DIRECT. An auto-select group uses the checks and selection logic defined in the configuration, so you may not be able to pin a specific member.
If the client has a connectivity test, run it to rule out obviously unavailable options. A response from the test address only confirms that this particular test path returned a result; it doesn't guarantee the target site will load, and a lower number alone doesn't mean a better overall experience. Choose a node that passes the test, then verify it with a real site request. If every test fails, return to step one to check whether the subscription has expired and its options are complete, then look into your network environment.
If some sites work while others don't, switch briefly to Global mode and select a node in the global policy for comparison. If the same site works in Global but fails in Rule mode, check the matched rule and proxy group first. If both modes fail, investigate the node or how traffic is being routed to the client. Switch back to Rule mode when you're done; don't let a quick test become a permanent setting by accident.
mode: ruleThe example above shows only the mode field to illustrate the “Rule” setting in the interface; it isn't a complete configuration you can run on its own. You don't need to edit YAML manually for this guide—make the selection in the interface. If you're unsure how policy groups, rules, and nodes fit together, read the glossary, then return to this step. You should now have an active configuration, a selected mode, and a usable proxy option.
Step 3: Connect and Grant System Permissions
On desktop, first make sure the client core is running, then enable “System Proxy.” This typically points the operating system's HTTP and HTTPS proxy settings to a local listening address. Browsers and apps that use the system proxy will then send requests through the client. For your first test, don't also change browser extensions, environment variables, or multiple network tools. Keep the path simple so it's easier to identify any problem.
If the system proxy is on but your browser can't load any pages, check the listening port in the client settings and compare the address and port with the system's network proxy settings. A common local address is 127.0.0.1; use the port shown in your current configuration. Don't overwrite an existing value just because 7890 is common in tutorials. Requests can end up nowhere if the client isn't listening, another program has taken the port, or the system still points to a previous client.
On Android and iOS, tap “Connect” or the start button on the main screen. The system will then prompt you to approve a VPN configuration or connection. Make sure the request comes from the client you're using, then allow it as prompted. Return to the client and check that it shows as connected; the system may also display a VPN status indicator. This VPN is a system-provided way to route traffic—it doesn't mean every app labeled VPN uses the same protocol or server.
If another VPN, corporate network tunnel, or similar proxy tool is already running, check whether they can be used together. Mobile operating systems usually limit multiple VPN services running at once, and starting another may replace the existing one. If your network is managed by your employer or school, don't change its policies without permission. Check the network requirements before testing. If the Connect button keeps switching back off, check whether authorization is complete, background activity is restricted, or the client reports a configuration loading error.
TUN routes traffic from more apps, including those that don't follow the system proxy, but you usually don't need it to get a browser working for the first time. Desktop clients may require a service installation, administrator permission, or approval to use a virtual network adapter. Follow the documentation for your client; system proxy and TUN aren't two lights that must always be on together. If enabling TUN disrupts basic connectivity, turn it off and confirm the system proxy works first. Then see the cross-platform guide for routing, DNS, and permissions.
Step 4: Verify Requests, Rules, and Your Exit IP
A connected status is just the starting point; what matters is whether real requests work. First open a site that should be accessible on your regular network to make sure the setup hasn't disrupted it. Then open a new tab and visit the site you want to access through the proxy. To avoid interference from cached pages or existing long-lived connections, use a new private window or fully reload the page. Once the site loads, check the client's Connections or Logs page rather than judging by the toggle color alone.
Find the request for your target domain in the connection list and check the matched rule, policy group, and final node. If a request that should be proxied shows DIRECT, return to step two and check the mode and group. If the request isn't listed at all, check whether the browser uses the system proxy, a proxy extension overrides its settings, or the current window is reusing an old connection. Some clients show only active requests, so an entry disappearing after a page loads isn't necessarily a problem. Watch the list while refreshing the page.
Next, use a trusted exit IP lookup service and compare the results with the proxy off and on. In Rule mode, the lookup site itself may use a direct connection, so an unchanged IP doesn't automatically mean the proxy failed; check the request's match record too. For a clear comparison, briefly switch to Global mode with a node selected, run the lookup again, then return to Rule mode. A changed exit IP only confirms that this request took a different path—it doesn't prove that every app on the device is routed through the client.
To distinguish more precisely between “the core can proxy” and “the browser is routed through it,” you can send an explicit request to the local HTTP proxy from a desktop terminal. The command below applies only if the current HTTP or mixed listening port is 7890; replace it first if your port is different. The example domain tests an HTTP response and doesn't indicate whether a particular region can reach it.
curl -I --proxy http://127.0.0.1:7890 https://example.comOn Windows, if the terminal resolves curl to another command, use curl.exe. An HTTP response means the request got a response through the specified local proxy, but check the logs to see whether it went direct or through a node. If the connection is refused, check the port and whether the core is running. If it times out, check the node and route to the target site. This test doesn't change the system proxy or replace a browser test; treat them as separate paths.
Finally, check how DNS resolution behaves. A site loading doesn't by itself prove DNS is being handled as expected, and the resolver location shown by a DNS test isn't enough to establish a leak. Keep a working configuration while you get started. If domains won't resolve, only some sites fail, or you need to check for a Clash DNS leak, troubleshoot by symptom in Frequently Asked Questions. For DNS fields and network stack concepts, see the glossary. Don't change every DNS setting at once before confirming that requests are reaching the core.
After Setup: Save Your Settings and Disconnect Safely
Your first setup is complete when the target site loads, connection records match the expected policy, and your regular network still works. Note the configuration name, running mode, and selected proxy group; there's no need to save a screenshot containing the full subscription URL. Next, test your everyday apps one at a time. If the browser works but a particular app doesn't, check that app's proxy support before replacing the entire subscription.
When you're done, turn off the system proxy on desktop or use the client's normal exit option to restore settings before quitting. On mobile, tap Disconnect and confirm the system VPN has stopped. If your browser can't load pages after the client exits unexpectedly, check whether the system proxy still points to a local port that is no longer listening. Restoring normal network settings is more direct than reinstalling everything, and there's no need to delete all your configuration files.
Use the same order every time you troubleshoot: confirm the subscription loaded, check the mode and policy group, make sure the app's request reaches the core, then verify the rule and exit route. Change one setting at a time, test, and decide what to do next. For platform installation, TUN, and persistent configuration overrides, read the cross-platform guide. Search Frequently Asked Questions for specific errors. First establish a connection path you can reliably test, then add complexity.