Step 1: Import a Subscription and Enable the Configuration
Before you begin, find the full subscription URL provided by your service and make sure it is still valid and supports the Clash configuration format used by your client. The client reads the configuration and handles connections; installing it does not provide a working proxy route by itself. If you only have an account, purchase receipt, or web address, return to your service’s account page and look for an option such as “Subscription URL” or “Clash subscription.” Don’t use the login page address as a configuration.
Open the Config Page and Add a Remote Subscription
Open the client and select Config, Profiles, or Subscription in the sidebar or bottom navigation. Look for Add, Import, or a plus button, then choose an option such as Import from URL or Remote configuration. Paste the complete URL and check that there are no extra spaces, line breaks, or punctuation added by a messaging app at either end. Give it a recognizable name, such as “Daily setup,” then select Save, Import, or Download and wait for the client to finish fetching it.
Some clients provide a text field directly on the Config page; paste the URL and tap Import. Others first save a configuration card, then fetch the contents when you tap its Update button. Either way, the result should be a readable configuration, not just a saved URL. Check the card for its name and an update result or configuration details. Clients show different information, so don’t expect every field to appear in every interface.
For a local .yaml or .yml file, choose “Import from file” and open it in the file picker. Don’t enter a file path in the subscription URL field. Local files usually don’t fetch updates automatically like remote subscriptions, so you’ll need to reimport them or maintain them manually. For the initial setup, use one clear import method rather than creating several configurations with the same name.
Check the Import, Then Set It as the Active Configuration
Once the download is complete, tap the configuration card or open its menu and select Use, Activate, or Set as current. Check for a selected indicator, then open Proxies and look for the proxy groups. You should see the groups and available routes defined by the configuration. If the configuration list shows the new card but Proxies still shows old content, go back and confirm that the new configuration is actually active. Saving and enabling a configuration are separate actions.
If the download times out, first make sure your device has an internet connection, then try updating once more. If you see a parsing error, check with your subscription provider that the URL is intended for Clash. A subscription URL opening in a browser doesn’t mean it returned a configuration: it may have returned a login-expired page, an access-denied message, or an ordinary web page. Don’t keep changing proxy modes to fix a format error; a mode setting can’t turn a web page into YAML.
You’re done with this step when the configuration is active and the expected proxy groups appear on the Proxies page. An import success message alone doesn’t mean your traffic is using a proxy. Next, choose how traffic is routed and select an exit. For more on subscription updates and local files, see Chapter 4 of the full handbook: Subscriptions and Configurations.
Step 2: Choose a Rule Mode and Proxy Route
Return to the client’s Overview, Home, or Proxies page and find the operating mode. Common options are Rule, Global, and Direct. For your first setup, choose Rule so the configuration’s existing rules determine where each request goes. Don’t turn on every switch just because a page won’t load. Set the mode first so it’s easier to identify which setting affects the result.
Select Rule, Then Check the Proxy Groups
Select Rule, then open the proxy group list. Group names depend on the configuration author; a group might be called “Select Node” or “Proxy Selection,” not necessarily PROXY. Open the group used for proxied traffic and choose an available route you’re authorized to use. If the selected option points to another group, open that group too and confirm the final route isn’t Direct when you intend to use a proxy.
Some groups choose a route automatically, with labels such as Auto, Failover, or URL Test. If your configuration already uses an automatic group, you can leave it as is; there’s no need to switch to manual selection. If the client offers a test button, use it as a quick check. A successful test only means that a specific probe received a response; it doesn’t guarantee access to every site or confirm that the app you’re testing has sent traffic through the client.
| Mode | What it does | For this setup |
|---|---|---|
| Rule | Routes requests according to the configuration’s rules, which may select a proxy, Direct, or another policy. | Use for the initial connection, then check which rules actually match. |
| Global | Applies the global policy group to requests handled by the core. | Switch to this temporarily only when you have a specific troubleshooting goal. |
| Direct | Sends requests handled by the core through the Direct policy. | Don’t use this to test whether a proxy route works. |
Rule Mode and Traffic Capture Are Different
Rule mode answers “Where does a request go after it reaches the core?” The system proxy or mobile VPN answers “How does the request reach the client?” Selecting Rule doesn’t connect you, and Global mode doesn’t mean every app on the device is being routed through the client. Desktop apps that ignore the system proxy may bypass it.
Before moving on, check two things: the mode is Rule, and the proxy group you plan to use has a suitable route selected. Don’t edit rules, change DNS, or remove proxy groups from the configuration yet. For a deeper explanation of policies, see Chapter 5 of the full handbook: Proxy Modes. To change how certain sites are routed, see Chapter 6: Rule-Based Routing. Next, enable the system-level connection.
Step 3: Connect and Route Traffic Through the System
Keep the active configuration and proxy group selection as they are, and return to the client’s home page. First check whether the core is running. Some desktop clients start it automatically; others require you to press a start button. If the client reports a configuration load error or the core won’t start, fix that first. Turning on the system proxy alone won’t help if apps are pointed at a local port that isn’t working.
Desktop: Enable the System Proxy
In the Windows, macOS, or Linux GUI client, find and enable System Proxy, Set as system proxy, or a similarly named switch. It may be on the home page, in Settings, or in the context menu for the tray or menu bar icon. Confirm the client shows it as enabled. If needed, check your operating system’s network proxy settings to make sure the address points to your device and the port matches the one shown in the client. Don’t manually enter a fixed port based on a screenshot from another guide.
If another proxy or VPN app is also changing your network settings, stop it from routing traffic before testing this client. Browser proxy extensions can override the system proxy, too; for the first test, configure your browser to use the system settings. On a work-managed device, don’t override network policies set by your organization. Follow your device management requirements if you don’t have permission to change them.
The system proxy isn’t a universal switch that covers every app. For your first test, use a browser that follows the system proxy. If the browser works but a standalone app doesn’t, check the app’s own proxy settings. Set up TUN only if you need to route more traffic. For permissions and routing, see Chapter 7 of the full handbook: TUN Mode; there’s no need to change it yet.
Mobile: Connect and Approve the VPN Request
On the Android or iOS client’s home page, tap Connect, the start icon, or the connection switch. The first time you connect, the system may ask to set up a VPN configuration. Make sure the request comes from the client you just opened, then approve it and complete any authentication required by your device. Return to the client and wait for it to show Connected. The system may also show VPN status in the status bar or Settings, depending on your OS version.
If the switch turns off immediately after you approve the request, check the earliest error in the client logs and see if another VPN connection is already using the tunnel. Don’t tap Connect repeatedly in quick succession. If Android later disconnects after the screen locks, check battery and background activity restrictions after your initial test. For now, keep the client and browser in the foreground to reduce variables.
At this point, the desktop client should have its core running and system proxy enabled; on mobile, the client should show Connected and the system VPN request should be approved. This confirms the traffic entry point is ready, but doesn’t prove that requests are using the right route. Leave the settings as they are and test with a real request.
Step 4: Verify That Requests Follow the Expected Route
Open a browser and visit a page you know and are authorized to access. Confirm it loads, then open a page that should use a proxy under your current configuration. Don’t rely only on the client’s connection switch or assume that a page loading proves it used a proxy: in Rule mode, that page may be expected to connect directly. Check both the page and the client’s connection logs.
Find a New Request in the Connection Logs
Switch back to the client and open Connections, Connection, or Logs. If search is available, enter the domain you just visited. Then reload the page or make a new request in another tab. Existing connections may continue using an old route, and a cached page may not make a new network request, so revisit the site after changing settings. If needed, close and reopen the page. Clear existing connections in the client only if you’re sure doing so won’t interrupt a download or other work.
Find the request and check its domain, matched rule, policy group, and final route. Some clients show only some of these details; open the connection details for more. A request that should use a proxy should match the selected proxy group and its route. Seeing DIRECT for a request expected to connect directly may be completely normal. A page load can make requests to several domains, so don’t mistake the route for an image or analytics request for the main page’s route.
If you use a public IP lookup service as an additional check, remember that it shows the route for that particular lookup request only. Rules may send the lookup domain directly, so an unchanged result doesn’t prove the client is broken. Even if the result changes, that doesn’t mean every app on the device uses the same route. Trust the target app’s actual request and its matching connection log. Never enter subscription or account details on an IP lookup page.
If the Result Isn’t What You Expected, Check the Entry Point, Rule, and Route
If you can’t find a new request at all, check the entry point first. Make sure the same configuration is still active, the desktop system proxy is enabled, the browser isn’t using its own proxy, and the mobile VPN is still connected. If the Connections page shows only active sessions, a short-lived request may have disappeared. Watch the log while reloading, or check the logs instead. Changing proxy nodes repeatedly won’t help if the request never reached the client.
If the request appears but shows Direct, check the rule. First confirm whether the configuration is supposed to send that domain directly, then check the matched rule and policy group. To compare, you can temporarily switch to Global mode, select a known proxy route, and make the request again. Switch back to Rule as soon as you’re done. If Global works but Rule doesn’t behave as expected, troubleshoot the rules and policy groups; there’s no need to reinstall the client.
If the log shows a proxy route but the page still times out, check the route last. Choose another available route in the same proxy group and make a new request. If only one site is affected, the target service, account status, or access restrictions may be the cause. Change one variable at a time and note the error and conditions. A failed subscription download and a failed request to a website happen at different stages; don’t treat them as the same problem.
When you’re done, turn off the desktop system proxy before closing the client. On mobile, disconnect the VPN in the client. This prevents apps from continuing to connect to a local proxy that has stopped running. When you change subscriptions later, return to Step 1 and confirm that the configuration is active; there’s no need to reinstall the client.
For update schedules, logs, and backups, continue to Chapter 8 of the full handbook: Routine Maintenance. Once you’ve verified the basics and are ready to change your configuration structure, see Chapter 9: Advanced Setup. Keep the configuration you’ve verified as a working baseline, and change one thing at a time so you always have a clear starting point when troubleshooting.