Check the client, subscription URL, and system time
Before you begin, make sure a maintained Clash graphical client is installed on the device. Different clients may use similar configuration formats, but their interfaces are not identical: some place the subscription entry under “Configuration,” while others provide a separate “Subscription” page; some call the connection switch “System Proxy,” while mobile clients typically establish local traffic interception through the system VPN permission. These naming differences do not change the workflow described here.
Next, prepare the subscription URL supplied by your service provider. It is usually a complete link beginning with https://. Copy it exactly; do not manually remove parameters, spaces, or trailing characters. A subscription URL is a configuration credential and should not be posted in chat groups, screenshots, or public webpages. If you received YAML text or a local configuration file instead, you can use “Import File,” but this guide focuses on the more common URL subscription method.
Finally, check that the device date, time, and time zone are correct. An incorrect clock can cause HTTPS failures, preventing subscription updates, triggering certificate errors, or making every node unavailable. On Windows and macOS, enable automatic time settings; on Android and iOS, use the network-provided time. Once ready, keep a direct internet connection available before starting the first step. This separates an underlying network problem from a proxy configuration problem.
Import the subscription and confirm the configuration loaded
After opening the client, go to the “Configuration,” “Profiles,” or “Subscription” page. Common Clash for Windows interfaces provide a Profiles entry in the left navigation; Clash Verge Rev and similar clients often place subscription management at the top of the configuration page; mobile clients may use a plus button in the upper-right corner. Find an entry such as “Import from URL,” “New Subscription,” or a link-icon input, then paste the complete subscription URL you copied earlier.
Some clients ask for a configuration name. Use something easy to recognize, such as “Daily subscription” or the service name; there is no need to put every node region and expiration date in the title. If an automatic update interval is available, keep the default for now and adjust it after the basic connection works. After you click “Import,” “Save,” or “Download,” the client retrieves the configuration over the current direct connection. Do not enable the system proxy yet; wait for the download to finish.
Do not judge a successful import solely by a “Saved successfully” message. A new entry should appear in the configuration list, usually with a name, update time, or update button. After selecting it, the entry should be marked as the active configuration. Then open the “Proxy” or “Proxies” page. Under normal conditions, you should see several proxy groups, such as node selection, automatic selection, failover, or other groups defined by the rules. Once the groups appear, the YAML configuration has been parsed and loaded.
If no new entry appears after saving, check whether the pasted text contains line breaks, leading or trailing spaces, or explanatory text. Then try opening the subscription URL directly in a browser. If the browser downloads the content but the client fails, quit and restart the client and make sure the firewall is not blocking its network access. If the browser cannot open it either, the issue is usually the subscription URL, account status, or current network. Confirm with the subscription provider instead of repeatedly changing client ports.
If the configuration entry appears but the proxy page is empty, you may have imported a webpage URL, a conversion-page URL, or a configuration that contains no usable proxies or proxy groups. Delete the incorrect entry and import the correct subscription URL again. For the relationship between subscriptions, configuration files, and proxy groups, see the Glossary; complex YAML merging and local overrides are covered in Advanced usage.
Choose Rule mode and the actual exit
Once the configuration has loaded, return to the “General,” “Settings,” or mode selection area and find the three common modes: Rule, Global, and Direct. For first-time use, choose Rule mode. It reads the rule list in the configuration and routes connections to a direct connection, a proxy, or a specified proxy group based on domains, IPs, app types, or rule sets. It works well as the everyday default and prevents all local-network traffic and common services from being sent through the same proxy exit.
Global mode sends most interceptable traffic to one global proxy group. It is useful for temporarily checking whether a website works when forced through the proxy, but it is not recommended as the default. Direct mode bypasses the proxy and is useful for quickly restoring the original network, comparing results before and after connecting, or checking whether rules are causing the problem. These modes change traffic decisions, not the connection switch; selecting Rule alone does not make the browser use the proxy automatically.
After selecting Rule mode, open the “Proxy” or “Proxies” page. It usually contains a primary manual-selection proxy group, possibly named “Node Selection,” “PROXY,” or something chosen by the subscription provider. Open that group and choose a node from the next-level list. For the first test, choose a nearby node with a clear name that is not “DIRECT.” If the configuration includes an “Auto Select” group, run a latency test first and use the automatic group as the exit if appropriate.
A latency test measures only the connection time from the client to the test address. It does not equal webpage download speed and cannot by itself prove node stability. If a low-latency node cannot open pages, switch to another node in the same group and try again. If every node times out, do not jump straight to advanced options such as TUN, DNS, or rule overrides. Return to Step 1, update the subscription manually, and check the device’s direct network and system time.
Proxy groups may be nested. The first level may be “Auto Select,” with the second level choosing a node based on latency; alternatively, the first level may select a region and the second a specific route. Follow the highlighted selection one level at a time until the final exit is no longer DIRECT or REJECT. For more on traffic differences between Rule, Global, and Direct modes, see Troubleshooting. Custom proxy groups and rule sets are part of Advanced configuration; continue with Advanced usage.
Rule mode
Uses the configuration rules to decide between direct and proxied connections; recommended as the default.
Global mode
Routes traffic through a selected exit, useful for determining whether access failures are related to split-routing rules.
Direct mode
Bypasses the proxy exit to compare results or quickly rule out the proxy path.
Enable the system proxy and establish the connection
Return to the client home page or General settings. Confirm that the current configuration name, Rule mode, and selected proxy group are unchanged, then find the “System Proxy” switch. On Windows and macOS desktop apps, enabling it usually points the system proxy to Clash’s local listening port. Browsers and most desktop apps that follow system proxy settings will then send requests to the client, which uses the rules to choose an exit.
After clicking the switch, check that it stays enabled. If it immediately turns off, first quit other proxy, network-debugging, or packet-capture tools, since multiple programs may be changing the system proxy at once. On Windows, you can also open the system “Network & Internet—Proxy” page and check whether the manual proxy changes with the client status. Do not enter an unfamiliar port there yourself; when the client closes, it may leave an unusable setting behind. Let the graphical client manage the system proxy and turn it off normally before quitting.
Mobile clients typically do not show a “System Proxy” switch. Instead, tapping the connect button requests VPN permission. This is the system prompt used by Android VpnService or an iOS network extension to establish local traffic interception. After confirming that you are using the newly installed client, allow the permission; a VPN indicator usually appears in the system status bar when connected. If the system says that only one VPN can run at a time, close other VPNs or local network tools and reconnect from the client.
Some games, command-line programs, and apps with independent network stacks do not read system proxy settings. In that case, a desktop client may offer TUN mode to intercept more traffic through a virtual network interface. During initial setup, enable only the system proxy and test a browser; do not change TUN, DNS, ports, and routes at the same time. After ordinary webpages work through the proxy, enable TUN only if a specific app requires it. When the system requests administrator access, a network extension approval, or firewall access, review what is being authorized and complete the prompt, then confirm that TUN has not turned itself off.
If no webpages work after enabling the system proxy, turn it off immediately and confirm that the direct network is restored. Then check whether the current node works. Restart the client, update the subscription manually, switch to another node, and test again. Do not change a dozen settings while the network is completely down; it becomes difficult to tell which change mattered. The basic connection order is always the same: the configuration parses, a policy has an exit, the node connects, and the system proxy is enabled.
Verify the exit, routing rules, and connection logs
After connecting, do not rely only on the color of the switch. Open a regular webpage that normally works through a direct connection to confirm that the basic network is still available. Then visit a page showing your current public IP and note the exit region and network details. Temporarily disable the system proxy and refresh the same page to compare the result before and after connecting. An expected change in the two exits confirms that the browser has entered the client’s interception path.
Enable the system proxy again and keep Rule mode selected. Visit one site that should use a direct connection and another that should use the proxy. Return to the client’s “Connections” or log page and find the domain entries just generated. Each entry usually shows the matched rule, proxy group, and final exit. If the direct request shows DIRECT and the proxied request lands in the selected group, basic routing is working as expected.
If the exit does not change, check that the browser has no independent proxy extension enabled and is not bypassing the system proxy. Fully quit and reopen the browser, or test with another browser that follows system proxy settings. If the page opens but the exit region does not match the node name, switch to another node and refresh the lookup page. Node names are defined by the provider; the actual exit result is what matters.
If only one site fails, inspect the rule result in the connection log. REJECT means the configuration actively blocked the request. If the result is DIRECT but the site requires a proxy, temporarily switch to Global mode for comparison. If it works in Global but fails in Rule, the problem is usually in the rules or proxy group, not the system proxy switch. After the test, switch back to Rule instead of routing all traffic through the global exit. See Advanced usage for rule changes, rule-set subscriptions, and local overrides.
If no node can connect but the subscription updates normally, check node selection, system time, the firewall, and current network restrictions in that order. If TUN causes local devices to become unreachable, DNS resolution to fail, or apps to lose connectivity, disable TUN and verify again with only the system proxy enabled. This quickly distinguishes a basic proxy-path problem from an issue in the virtual adapter, DNS, or routing layer. The symptom-based sequence is collected in Troubleshooting; there is no need to change complex parameters during initial setup.
Basic webpage
Confirm that enabling the proxy did not interrupt the network overall.
Exit address
Compare the public exit before and after connecting to confirm the expected change.
Rule match
Use the connection log to confirm DIRECT, the proxy group, and the final exit.
Single-site retest
For a failed site only, switch the node or mode to narrow down the problem.
Keep subscriptions updated and troubleshoot in a fixed order
After completing the four steps, everyday use usually requires attention to only three places: the active configuration, the main proxy group, and the connection switch. When the provider updates nodes or rules, click Update on the configuration page and confirm that the previous proxy-group selection still works. If the client supports automatic updates, set a sensible interval, but manually update once during a network problem so you can see a clear success or failure result.
When changing network environments, such as switching from home broadband to a mobile hotspot, wait for the direct network to recover before testing the proxy. After sleep, a system update, or an unexpected client exit, if webpages stop loading, turn off the system proxy and confirm that direct access works. Then restart the client and recover in this order: update the subscription, choose a node, enable the system proxy, and verify the exit. A fixed sequence is easier to troubleshoot than changing DNS, ports, and rules simultaneously.
During basic use, you do not need to edit YAML frequently. Enter Advanced configuration only when you clearly need to address missing rules, unexpected DNS resolution, a specific app that requires TUN, or multiple subscription merging. Proxy-group types, rule-set management, DNS, Fake-IP, TUN, domain sniffing, and external control panels are covered in Advanced usage. For a specific error, first find the matching symptom category in Troubleshooting.