Follow four steps in order: import a working configuration, choose Rule mode, connect a proxy-group node, and confirm that traffic is handled as expected. This guide covers only what you need for first use; protocol and core selection are explained on a separate reference page.
Before you start, prepare a Clash GUI client for your operating system and a subscription URL that is still valid. Service providers typically generate subscriptions containing nodes, proxy groups, DNS settings, and routing rules. The client reads and applies this configuration; it does not create usable proxy nodes on its own.
When copying a subscription, include every character from the beginning of the URL to the end. Do not copy truncated display text or add spaces, Chinese punctuation, or notes around the URL. If your provider offers both a “Universal subscription” and a “Clash subscription,” choose the one explicitly marked for Clash or mihomo.
The first time you enable the system proxy, a VPN configuration, or TUN mode, the operating system may request administrator or network permissions. When a system prompt appears, verify the application name before approving it. If you only want to test browser traffic, start with the system proxy; there is no need to change every advanced setting at once.
Setup requires access to the subscription server and node testing, so first confirm that the device can access the internet with Clash disabled. If the local network is already offline, subscription updates and latency tests will fail, making a basic network issue look like a client failure.
Configuration Source
Open the installed Clash client and find the “Configuration,” “Subscription,” or “Profiles” page. It usually shows a local profile list and a field for a subscription URL. Paste in the complete link from your service provider, check that there are no extra spaces at either end, and click “Import,” “Download,” or “Update.” If a name is required, use a short descriptive name such as “Daily profile.” The name itself does not change the subscription contents.
Do not go straight to the proxy page after submitting the URL. Wait for the download and parsing to finish, then check whether a new entry appears in the profile list. Normally, the entry shows its latest update time; some clients also display an automatic update interval. Select the newly imported profile to make it active. Then open the “Proxy” or “Proxies” page and check for proxy groups and nodes. Seeing groups such as “Node selection,” “Auto,” or provider-defined groups indicates that the main configuration loaded successfully.
If a format error appears immediately after pasting, return to the subscription source and copy the URL again instead of editing it manually. Opening a subscription URL directly in a browser may download a YAML file or display encoded text; either response can be normal, as long as the client can recognize it. If the browser shows a login page, expiration notice, or blank response, refresh the subscription from your provider’s website first rather than repeatedly clicking Update in the client.
Some clients offer both “Import from URL” and “Import from file.” Use URL import for a regular subscription so the client can request the same address for future updates. File import is better for a YAML configuration already saved locally, but the file will not follow remote changes automatically. For first-time setup, URL subscriptions are recommended so node and rule changes can be applied with an update.
Traffic Routing
After confirming that the profile loaded, open “Settings,” “General,” or the client home page and find “Outbound mode,” “Proxy mode,” or “Mode.” Common options are Rule, Global, and Direct. For a first connection, choose “Rule.” Rule mode checks the configuration from top to bottom and uses domain, IP address, application, or geographic data to decide whether traffic should use a proxy or connect directly. This sends proxy-bound requests to a proxy group while keeping suitable traffic on its normal direct path.
Global mode sends most matching traffic through the currently selected proxy policy. It is useful for temporarily checking whether an access problem is caused by routing rules, but it should not be the long-term default when you do not understand the configuration. Direct mode bypasses the proxy and is mainly useful for pausing proxying or running comparison tests. If access works in Direct mode but fails in Rule mode, check rule matches, proxy-group selection, and DNS settings instead of repeatedly reinstalling the client.
After choosing Rule mode, leave advanced options such as Fake-IP, DNS overrides, rule providers, and scripts unchanged. Most subscriptions include defaults that work out of the box, and changing several options at once makes problems harder to isolate. The first goal is a verifiable connection; once it is stable, investigate DNS modes, TUN routing, and custom rules based on application compatibility.
The mode only determines how traffic is matched; it does not connect you to a node. After selecting a mode, open the proxy page and assign an available node or an auto-select group to the main proxy group. If group names are provider-defined, look for the primary group near the top with selectable entries. Which group the rules ultimately target depends on the subscription, so its name may not exactly match the examples.
Uses the configuration rules to decide between proxying and direct connection. This is the usual starting point for everyday use and makes it easier to see which rule matched a request.
Sends the main traffic through the selected proxy policy. Useful for comparison with Rule mode, but it bypasses the existing fine-grained routing logic.
Sends traffic directly through the current network connection. Useful for restoring the original network path or checking whether a problem is related to the proxy route.
If terms such as Fake-IP, rule sets, GEOIP, and MATCH are unfamiliar, see Concepts at a Glance. Connection behavior, resource usage, and core compatibility for different protocols are covered in Protocol and Core Reference. You do not need to understand these topics before making your first connection.
Nodes and System Access
Open the “Proxy,” “Policy,” or “Proxies” page and open the main proxy group. When selecting a node manually, start with the client’s latency test. The result reflects the response from the current device to the test address through the node; it is only a reference for availability and relative latency, not actual download speed. Choose a node that completes the test with reasonably stable results rather than repeatedly chasing the smallest number.
If the configuration provides a url-test auto-select group, select it and let the core choose a better-performing node according to the configured test URL and interval. A fallback group usually checks availability in configuration order and switches when the previous node is unavailable. First-time users do not need to rewrite proxy groups; just confirm that the main policy ultimately points to a node or an auto-select group.
After choosing a node, return to the general settings and enable “System Proxy,” “Set as system proxy,” or a similarly named switch. This directs browsers and applications that support system proxy settings to Clash’s local listening port. Keep the client running in the background; the system proxy only tells applications to send requests to the local port, while the running Clash core handles the actual forwarding.
On Windows and macOS, most browsers read the system proxy settings, so you can proceed to verification after enabling the switch. Some applications have their own proxy settings or do not read the system proxy at all, so their traffic may not appear in the client’s connections panel. Android and iOS clients typically use the system VPN interface to capture traffic and show a system authorization prompt the first time; verify the app name and connection request, then allow it. On Linux, automatic use of the system proxy depends on the distribution, desktop environment, and application. If necessary, enter the local proxy address in the application itself.
TUN mode captures more traffic that does not follow system proxy settings, but it involves a virtual network interface, routing, and system permissions. For the first connection, use the system proxy to verify a browser. Consider TUN only if the browser works but a specific application still bypasses the proxy. This confirms the node, subscription, and basic proxy path first, keeping permission, routing, and DNS issues separate.
Confirm the Result
Keep the Clash client running and confirm that the system proxy or system VPN is still enabled. Open a new browser window, visit a familiar IP lookup page, and note the external address and region shown. Then temporarily disable the system proxy and refresh the same page for comparison. If the exit address differs between the two states and the page loads normally with the proxy enabled, browser traffic is going through Clash.
An IP lookup page alone cannot confirm that routing rules behave as expected, so also open the client’s “Connections,” “Logs,” or similarly named page. Keep it visible and open a new website in the browser. Normally, the connection list will show a new domain, destination address, matched rule, or policy. If search is supported, search for the domain you just visited to see whether it ultimately used a proxy, a direct connection, or another policy.
In Rule mode, not every request will appear as proxied; that is normal. The configuration may send local services, LAN addresses, or specific sites directly. The key checks are whether proxy-required destinations use the expected policy, whether the client records the corresponding connection, and whether pages load reliably. Do not use “all traffic goes through the same node” as the success criterion for Rule mode.
If the external address is unchanged but the connections panel shows browser requests, first check which rule matched the request. A DIRECT match means the configuration chose a direct connection; temporarily switch to Global mode for comparison. If the address changes in Global mode, the node and local proxy path are working, so inspect the subscription rules instead of changing system networking. Switch back to Rule mode after the comparison.
If the external address is unchanged and the connections panel shows no new requests, the browser is usually not using Clash’s local proxy. Recheck the system proxy switch, restart the browser, and look for a browser extension or in-app proxy overriding the system settings. Corporate networks, other VPN software, and security tools can also rewrite proxy settings; during troubleshooting, keep only one traffic-capture tool enabled at a time.
Browser requests are leaving through a different network exit. Continue by checking which specific rules matched.
The request reached the Clash core. Use the policy and rule fields to determine its final route.
The system proxy switch can change the browser’s route, so the basic configuration is complete.
Basic Troubleshooting
When something goes wrong, do not change the client, subscription, DNS, and system network all at once. A fixed troubleshooting order makes the cause easier to identify. First disable the proxy to confirm the local network works, then update the subscription to confirm the profile is readable, test multiple nodes, and finally check whether the system proxy is actually enabled. Until one layer passes, results from later checks are usually inconclusive.
| Symptom | Check First | Next Step |
|---|---|---|
| Subscription Cannot Be Imported | Whether the URL is complete, still valid, and returns content compatible with Clash | Copy the subscription again and check the provider’s service status |
| Every Node Test Times Out | The basic network, subscription update time, firewall, and system clock | Try another network and confirm that the protocol is supported by the current client |
| No Browser Connections Appear | The system proxy, browser-specific proxy, and other network tools | Restart the browser and keep only one proxy entry point enabled |
| Connections Appear but Pages Do Not Load | The matched rule, current policy, node availability, and DNS | Temporarily compare with Global mode, then switch back to Rule mode |
| The Browser Works but an Application Does Not | Whether the application reads the system proxy | Check the application’s proxy settings, then consider TUN mode if necessary |
You can keep the client logs open while troubleshooting, but do not treat every warning as a failure. Network changes, closed connections, and rule updates can all create normal status entries. Focus on errors that coincide with the failure, repeated connection timeouts, DNS resolution failures, or profile parsing messages. For detailed help with subscription failures, node timeouts, and system proxy issues, see Frequently Asked Questions.