Starting with a blank client, complete subscription import, proxy mode selection, connection startup, and result verification in sequence. This page covers only the main first-use workflow; configuration syntax, DNS paths, and system-level troubleshooting are covered in dedicated documentation.
Make sure the client starts normally, the subscription source is available, and note the current system proxy status. This makes it easier to identify which layer is failing. Avoid changing the proxy, DNS, and TUN settings at the same time.
After the first launch, you should see a configuration, proxy, or settings page. If the system blocks the app, complete the security confirmation and grant the required permissions first. Do not change the proxy, DNS, and TUN settings simultaneously.
Keep every character in the URL when copying it. Chat apps and webpages may collapse long URLs, so use the copy function to obtain the original address instead of manually transcribing truncated text.
Disable any old proxy and test a regular webpage before importing. If the underlying network is already unavailable, the client cannot update the subscription, and you cannot use that result to judge whether a proxy node works.
The configuration entry is usually under “Subscriptions,” “Config,” or Profiles in the sidebar. During connection setup, enable the system proxy first. Enter service mode or TUN settings only when you need to intercept apps that do not follow the system proxy. The first authorization may trigger a system confirmation dialog.
The client may run in the menu bar or use a standalone window. Subscription import is usually found in configuration management. When enabling the system proxy or network extension, macOS may ask for your account password or confirmation to allow the network extension.
On mobile, open the configuration page to import the subscription, then return to the main screen and tap the connection button. Android will show a VPN connection request; this is the standard authorization step that lets the client handle app traffic.
After importing the configuration, the first connection attempt will request permission to add a VPN configuration. Complete the system verification, return to the client, confirm that the active configuration and policy groups are selected, and then start the connection.
The desktop workflow is similar to Windows. Support for system proxies varies by desktop environment. If command-line programs outside the browser do not use the proxy, set proxy environment variables separately or configure TUN as needed.
The goal is for the client to obtain a configuration that can be parsed, updated, and selected. Seeing only a subscription name is not enough; the configuration should also contain policy groups, rules, and node information.
After starting the client, find “Config,” “Subscriptions,” “Profiles,” or “Configuration” in the sidebar, bottom navigation, or menu bar. You will usually find a remote subscription input field, a local-file import button, and any saved configurations. An empty list is normal on first use.
Choose the option to add a remote configuration by URL and paste the full subscription URL into the input field. If a name is required, use something recognizable, such as the service name or intended use; it affects only the local label, not the subscription contents. Then click “Import,” “Download,” “Add,” or “Update.”
The client first requests the subscription URL and then parses the returned configuration. Wait for the operation to finish instead of clicking repeatedly during the download. On success, the list usually shows the configuration name, update time, or node count. If the client reports a parsing error, resolve it before proceeding to the connection step.
A successful import does not necessarily mean the configuration is enabled. Some clients select the new configuration automatically, while others keep the previous one active. Click “Use,” “Select,” or the radio control for the new configuration and confirm that it is active. Then open the proxy page and check for groups such as “Auto,” “Node Selection,” or “Failover,” along with selectable nodes inside them.
If you see only the configuration name and no policy groups or nodes, run a manual update first. If it is still empty, check whether the subscription response is valid, the URL is complete, and the client log reports a YAML parsing error. For details on configuration fields and rule syntax, see the glossary; system troubleshooting for abnormal responses, parsing failures, and update timeouts is covered in the troubleshooting manual.
The mode determines how requests match rules. For first-time setup, use Rule mode and select nodes for the main policy groups so mode issues and node issues do not get mixed together.
Open the client’s “Mode,” “Running Mode,” or Mode settings. You will usually see Rule, Global, and Direct. Choose “Rule” or Rule for first use. This mode evaluates domains, IPs, processes, or rule sets in the configured order and sends each connection to the corresponding policy group. Common websites can connect directly, while requests that need a proxy enter the proxy policy, making everyday use more stable.
Global mode sends most requests to one proxy policy. It can help determine briefly whether a site is inaccessible because no rule matched, but it is not recommended as a long-term first-time setting. Direct mode bypasses the proxy and is mainly useful for pausing proxying or running comparison tests. After switching modes, you do not need to re-import the subscription, but start a new test request so an old connection is not mistaken for the result of the new mode.
After choosing a mode, open the “Proxy,” “Policy Groups,” or Proxies page. Find the group handling most proxy traffic; it may be called “Node Selection,” “Proxy,” “Manual Selection,” or a custom name supplied by the configuration provider. Expand the group and choose a node with a normal status. If the configuration includes an Auto group, you can use it first, but confirm that at least one node in the group can pass a test.
Policy groups may reference one another. For example, a “Foreign Sites” group may reference “Node Selection,” which then points to specific nodes. Changing only the outermost policy may not change the actual exit. Open each lower-level group until you see a specific node name, and confirm that the selection indicator has updated. Terminology for policy groups, rule matching, and fallback relationships is available in the glossary.
Rule, Global, and Direct determine how the core routes traffic; the system proxy and TUN determine which traffic reaches the core. For first-time setup, keep Rule mode and enable the system proxy in the next step. Consider TUN only when the target app ignores the system proxy, more apps need to be intercepted, or a specific DNS path must be handled. Changing both at once makes troubleshooting harder.
This stage sends system or app traffic to the client. Desktop clients usually enable the system proxy first, while mobile clients establish a connection through the system VPN interface.
Return to the client’s main screen and find the “System Proxy,” “Set as system proxy,” or System Proxy switch. Click it and wait for the status to change, confirming that it stays enabled instead of immediately reverting. Some Windows clients require the core service to start first, while some macOS clients request permission to modify network settings. Follow the system prompts, then return to the client and check the status.
Once the system proxy is enabled, browsers and desktop apps that follow the operating system proxy settings send requests to Clash’s HTTP or mixed port. Do not enable TUN or manually change the system proxy address yet. Complete the browser test first to reduce the chance of port-entry errors and conflicts between interception methods.
Android and iOS clients usually provide a connection button on the main screen. After you tap it, the system displays a VPN configuration or connection request. Once authorized, a VPN indicator usually appears in the status bar, and the client changes from disconnected to connected. The indicator only confirms that the system tunnel exists; test access and review logs to determine whether the node actually works.
If no authorization dialog appears, open the system VPN settings and check whether another similar connection is active. Mobile operating systems typically allow only one primary VPN tunnel at a time, and other network tools may prevent a new connection. Disable the conflicting connection and retry in the Clash client.
If the browser works through the system proxy but games, command-line tools, or specific desktop apps do not reach the client, evaluate TUN next. Enabling TUN on desktop may require administrator permission, a service component, or approval for a network extension. After enabling it, keep the existing Rule mode unchanged and observe whether the interception scope improves.
TUN involves a virtual network adapter, routing, and DNS paths, so it is not a general fix to apply immediately when the first connection fails. For the operating boundaries, permissions, and conflict troubleshooting of the system proxy and TUN, continue with the system interception chapter in the troubleshooting manual.
Do not judge success by the connection button alone. Check webpage access, connection records, rule matches, and node results together to confirm that requests followed the expected path.
Keep the client connected. Open a website that is normally accessible directly to confirm that the basic network remains available with the proxy enabled. Then visit a target expected to be handled by the proxy policy. Use a new browser tab and refresh once to avoid cached content, old connections, or a Service Worker making the result appear unchanged.
If both the regular and target websites open normally, review the client’s connection records. If the regular site works but the target fails, focus on the node and rule policy. If every site fails, check the system proxy port, active configuration, core status, and local DNS before repeatedly changing subscriptions.
Open the “Connections,” “Sessions,” “Logs,” or Connections page, then refresh the test page. The list should show a new domain, destination address, rule name, and policy chain. Find the request and confirm that it matched the expected rule and ultimately used the node you selected. If the record shows DIRECT, the direct-connection rule handled it; if it shows REJECT, a reject rule in the configuration took effect.
If no new requests appear in the connection records, the app’s traffic usually has not entered Clash. On desktop, check that the system proxy is still enabled; for command-line programs, check whether they read system proxy settings. On mobile, check that the VPN is active. If records appear but repeatedly time out, the interception path is established, so check node connectivity, network restrictions, or DNS resolution next.
The client’s latency test can help narrow down nodes, but a successful test does not mean every target is accessible. After choosing a node that passes the test, make a real webpage request and rely on the connection log’s establishment result. If every node times out, confirm that the subscription update succeeded, then compare with a different underlying network.
After testing, keep Rule mode and the currently working node. Basic setup is now complete. For later DNS changes, refined rules, startup configuration, or app-specific handling, change one item at a time and repeat the access and log checks in this section after each change.
This section covers the most common startup problems. For complex DNS, TUN, system service, and mobile issues, continue with the troubleshooting manual.
Disable the system proxy first and confirm that the underlying network can open a regular webpage. Then copy the complete subscription URL again and check for spaces at either end. If opening the URL in a browser also returns no configuration content, the problem is with the subscription response or current network, not the proxy mode. If the browser gets a response but the client fails, review the connection error in the log and confirm that the system time is accurate.
Confirm that the new configuration is active, then run an update once more. Check the log for configuration parsing errors, invalid field formats, or broken rule references. A subscription name with no policy groups usually means the response is incomplete or parsing failed. Repeatedly restarting the system proxy will not fix a configuration-layer problem.
Disable the system proxy to restore basic connectivity, then check that the client core is running, the active configuration is selected, and the primary policy group has a node. Re-enable it and review the connection records: no requests means traffic has not entered the client; requests that all time out point to the node; DNS errors should be investigated in the DNS chapter of the troubleshooting manual.
The app usually is not reading the system proxy; this does not mean Rule mode has failed. Check whether the app provides its own proxy settings. For command-line tools, configure an HTTP or SOCKS proxy according to their documentation. If more apps need unified interception, evaluate TUN and confirm the traffic path through the connection records after enabling it.