Import a Subscription and Enable the Configuration
Before you start, get a subscription URL compatible with your client or a local YAML configuration file. The client reads the configuration and forwards requests; installing it alone doesn’t provide a working proxy. Get a subscription from a service you’re authorized to use, or from a service you run yourself. This guide doesn’t provide subscription URLs. A URL may contain access credentials, so don’t post it in public comments or upload screenshots showing the full URL to public sites.
Open the client and go to “Configuration,” “Subscription,” or “Profiles.” Look for “New,” “Add,” or “Import from URL.” Choose the remote URL option, paste the full address, give the configuration a recognizable name, and click Save or Import. If the client saves the URL before downloading, click the Update button on the configuration card as well. Wait for loading to finish, then check for an update time, configuration name, or successful parsing message. The exact details vary by client.
When pasting the URL, make sure it doesn’t include extra spaces, line breaks, or punctuation added by a messaging app. Opening a URL in a browser only shows that the request received a response; it doesn’t guarantee the response is in a valid Clash configuration format. If parsing fails, ask your subscription provider which client format to use. Don’t try to fix a format error by repeatedly changing local ports or DNS settings—they’re unrelated to parsing the subscription content.
For a local file, choose “Import from file” and select the .yaml or .yml file. Keep a copy of the original before importing. Some clients also let you paste configuration text, but don’t paste a full YAML document into a subscription URL field. A file containing only proxy nodes serves a different purpose from a complete configuration with rules, DNS, and proxy groups. Whether it works on its own depends on whether the client fills in the missing configuration.
After importing, click “Enable,” “Use,” or the selection button on the new configuration. Seeing its card doesn’t mean it’s active. Go back to the Proxy page and check that the configuration’s proxy groups or nodes are listed. If the page is still empty, return to the configuration page and check which configuration is selected and whether any errors are shown. If the client stores multiple configurations, make sure it hasn’t kept using an old test configuration.
For your first setup, update the subscription once manually. After confirming it works, set an automatic update interval based on your provider’s recommendations; updates that are too frequent may trigger request limits. A remote update may overwrite edits made directly to a downloaded configuration, so avoid combining subscription updates with extensive manual changes during initial setup. Once the configuration is imported and enabled, decide how requests should be routed in the next step.
Choose Rule Mode and a Proxy Group
Open the mode selector on the client’s home screen, in settings, or in the tray menu. For your first setup, choose “Rule” (sometimes labeled “Rule” in the English interface). Rule mode uses the matching order in the active configuration to decide how each request is handled—for example, connect directly, use a proxy group, or reject the connection. This controls how traffic is routed; it doesn’t enable the system proxy. Even with Rule mode selected, app traffic may not yet be reaching the client.
The other common modes are “Global” and “Direct.” Global mode typically sends regular requests that reach the core through the global proxy group. It can be useful for a quick comparison, but doesn’t mean all apps are being routed through the client. Direct mode connects requests reaching the core directly. For everyday use, start with the rule mode provided by your subscription to avoid changing routing behavior before you can tell whether a problem is in the configuration or traffic routing.
After choosing Rule mode, open the Proxy page and find the selection group provided by the active configuration. It might be called “Proxy,” “Select Node,” or something else entirely; don’t assume its name makes it the master switch. Check the configuration documentation to see which group the rules actually reference, then choose an available exit in that group. Selecting a group doesn’t mean every rule uses it—other rules may point to different groups.
If the selected group points to another group, such as “Auto Select,” check the nested group’s current selection and test status too. A manual selection group usually keeps the option you choose, while an automatic group picks an exit based on the configured health checks. For initial troubleshooting, temporarily choose a specific node to reduce uncertainty from nested groups. Switching a group that no rules reference may have no effect on your traffic.
Use the client’s connection or latency test to check for timeouts and connection failures. Results depend on the test URL, protocol, and current network, so they only describe one particular request—not whether every website will work. Open a website even if the test succeeds. If the test times out, check the logs before assuming the entire subscription is unusable.
At this point, you should know which configuration is active, which mode is running, and what exit the target proxy group has selected. For details on protocol differences, core compatibility, and choices on mobile devices, see the protocol and core reference. Keep the configuration’s existing DNS and rules for your first connection. The next step is to route system traffic through the client.
Enable the System Proxy or VPN Connection
On desktop, check the client’s home screen or status bar to make sure the core is running. Some clients start the core automatically; others require you to click Start. If the configuration failed to load, go back and fix that first. An open application window doesn’t prove the core responsible for forwarding requests is working. Once the core is running, enable “System Proxy” so apps that follow system proxy settings send requests to the local listening port.
After enabling the system proxy, check the operating system’s network proxy settings to confirm the address and port point to the current client. Use the port shown in the client instead of copying a number from another guide. A mixed port may accept both HTTP and SOCKS requests, but some clients provide separate ports. You don’t need to change the listening address for your first setup, and you shouldn’t enable LAN access just to connect a browser on the same computer.
If another proxy tool is running on Windows or macOS, turn off its system proxy before enabling the current client’s. Two programs writing to the same system setting can make one interface show “On” while the actual port points to the other program. If your browser has a separate proxy extension, set it to follow system settings so it doesn’t override the system proxy.
On Android, tap the start button on the home screen to create a local VPN connection. The first time you do this, the system displays a VPN connection request. Confirm which app is requesting access before allowing it. Once connected, Android usually shows a VPN status icon, and the client should indicate that it’s running. Disconnect any other VPN first. On some devices, an always-on VPN or lockdown setting may prevent the new connection from taking over.
The first time an iOS client connects, follow the prompts to add a VPN configuration and complete any device authentication required by iOS. Return to the client and check that the connection is established. If multiple VPN configurations are saved in Settings, make sure you know which one is active. Allowing a configuration to be added is only a setup step; check the client and iOS VPN status to confirm it’s connected. Don’t skip verification just because you tapped Allow.
Desktop TUN is another way to route traffic. It often requires a service component, administrator privileges, or system authorization, and routes traffic differently from the system proxy. For your first connection, use the system proxy to test a browser. Look into TUN only if an app ignores the system proxy or you need broader traffic routing. Android clients may already use a virtual network interface internally, so don’t expect a switch with the same name as the desktop option.
Verify Traffic Routing and Rule Matches
Keep the client running, open a new browser tab, and visit a site you’re authorized to access that should use the proxy under your current rules. Start with a simple page to distinguish slow site loading from a connection issue. For your first check, don’t just refresh an existing page—browser caches, reused connections, or site caching can make results seem unrelated to your current settings.
While the page loads, open the client’s “Connections,” “Activity,” or “Logs” view and look for the domain you visited. Connection details often show the destination, matched rule, and proxy chain; logs may show connection or DNS errors. The available information varies by client, but at a minimum, confirm that the request reached the core. If the page loads but the client shows no request, that doesn’t prove the proxy is working—the browser may have reached it through its existing direct connection.
Once you find the request, check that its routing method matches what you expected. A DIRECT match means the configuration routed that request directly; it doesn’t prove that the proxy failed to start. If the request used a proxy group, check which exit the proxy chain ultimately selected. Pages often load resources from multiple domains, so don’t judge the route for an entire page based on a single static resource request.
Next, visit a site that should connect directly according to your configuration and check which rule it matches. These two checks verify both the proxy route and the direct route, helping you avoid mistaking “everything uses the same exit” for correct rule-based routing. An external IP lookup site can provide a useful additional check, but it only shows the exit for that particular request. It can’t tell you whether all apps, domains, or IPv6 traffic use the same route.
If a request doesn’t reach the client, first make sure the system proxy or VPN connection is still enabled. Then check whether the browser uses a separate proxy and whether the system port matches the client. If the request reaches the core but fails to connect, check the selected proxy group and try another available exit in the same configuration. If the logs show a DNS resolution error, check the configuration’s DNS settings. Don’t replace the entire configuration without a reason.
Change one setting at a time, then repeat the same test. Check in this order: “configuration enabled → proxy group selected → core running → traffic routing enabled → rules and DNS logs.” When sharing an error, include the error type and relevant field names, but hide subscription URLs, proxy credentials, and unrelated connection details. For a more detailed walkthrough, see the Clash Connected but No Internet: Troubleshooting Checklist.
Once everything checks out, enable automatic updates, automatic selection, or TUN settings one at a time, repeating the checks after each change. Finally, test disconnecting cleanly: on desktop, turn off the system proxy before quitting the client; on mobile, use the client’s Stop button and make sure the VPN disconnects. This prevents the system from sending requests to a local port that is no longer listening after the client closes.
A complete initial setup should give you four verifiable results: the subscription loads, a proxy group has a clear selection, system traffic reaches the client, and requests use the expected exit. If you change subscriptions or devices later, revisit Import a subscription. For differences in protocol support and core configuration, see the protocol guide. There’s no need to adjust every advanced setting before your first connection.