Clash Setup Guide: From Importing a Subscription to Verifying It Works

First, one concept worth clarifying: a subscription link isn't a node itself — it's a URL generated by your provider that, once opened by the client, downloads a full profile containing a node list, proxy groups, and routing rules. A client can store several profiles at once, but only one is active at a time. The internal structure of a profile has its own section in the full manual; this step is just about getting it in.

Using Clash Verge Rev as the example: open the client, click "Profiles" in the left nav to reach the profile management page, and there's an empty input box near the top. Paste the subscription link in completely — when copying from your provider's dashboard, make sure you don't drop the trailing parameters — then click "Import" on the right. Within seconds, a profile card named after the subscription appears below, often showing data usage and expiry date too (depending on whether the provider includes that in the response headers). Click the card to select it; a highlighted border appears, marking it as the active profile. This step is often skipped: importing without selecting leaves the client running on the old or an empty profile.

Where to find this in other clients: in FlClash, go to the "Profiles" page, tap the plus button in the bottom right, choose "URL," paste, and save; in Clash Meta for Android, tap "Profiles" on the home screen, tap the plus icon top-right, choose "Import from URL," save, then return to the list and select the profile; Clash Plus has an "Add Subscription" entry right on the home screen — paste and confirm. Every client follows the same flow: import → appears in the list → select to activate.

After a successful import, it's worth doing one more thing: find "Update" in the profile card's context menu (long-press or the card's menu button on mobile) and confirm it refreshes correctly; then set an auto-update interval in the edit options (e.g. 1440 minutes) so the client syncs automatically whenever the provider updates its nodes, without needing a manual refresh each time.

Once the profile is active, the next thing to decide is which traffic gets proxied. Every Clash client offers three outbound modes, usually shown as a toggle group on the home or settings page:

• Rule — traffic is matched against the rules in the profile: anything matching a direct rule bypasses the proxy, anything matching a proxy rule goes through your chosen node. Keep this mode for everyday use — it's what every subscription is designed to expect.
• Global — all traffic goes through the proxy node regardless of rules. Only use this briefly when troubleshooting whether a rule failed to match; leaving it on long-term wastes bandwidth on traffic that never needed a proxy.
• Direct — no traffic is proxied at all; the core is running but idle. Useful for comparison testing.

With mode set to Rule, click "Proxies" in the left nav to open the node page. Nodes here are organized into groups defined by the profile — most commonly a manual group like "Proxy Select" and an auto-testing group like "Auto Select." Click a node inside the manual group to mark it as the active outbound. Before choosing, you can hit the latency test button (usually a lightning icon) to test the whole group at once: the number reflects how long a handshake to that node takes, not download speed — for a deeper look at picking nodes by latency, multiplier, and region, see this node-selection guide.

Mobile placement differs slightly: Clash Meta for Android requires starting the core first (see next step) before you can switch nodes on the Proxies page; FlClash puts the mode toggle at the top of the home screen with node groups under the "Proxies" tab — the logic is the same.

With a node chosen, the core is already listening on a local port — but the OS and your apps don't know to hand traffic to it yet. This "Connect" step closes that last gap. Desktop and mobile handle it differently, so we'll cover each.

Windows / macOS / Linux desktop: go back to the "Settings" page in Clash Verge Rev and turn on the "System Proxy" switch. This registers a local proxy server with the OS — by default at 127.0.0.1 on a mixed port (Verge Rev defaults to 7897, accepting both HTTP and SOCKS), after which apps that respect the system proxy setting, like browsers, automatically route through the core. Once enabled, the tray icon's state changes, and hovering over it shows the current mode. On macOS, the first time you enable this, the system will prompt for authorization to change network settings — click Allow and verify once; it won't ask again.

Android: mobile doesn't use a system proxy — instead it establishes a local VPN tunnel through the system's VpnService interface to intercept traffic. Open Clash Meta for Android or FlClash and tap the start button in the center of the home screen; the system will show a prompt like "XX wants to set up a VPN connection" — this is Android's standard prompt for all VPN-type apps. Tap "OK," and a key (or VPN) icon appears in the status bar, confirming the tunnel is up. If the client keeps disconnecting after running in the background for a while, that's usually the system's battery-saving mechanism killing it — see this Android usage guide for how to handle it.

There's also a more advanced desktop connection method called TUN mode: it intercepts traffic at the system level through a virtual network adapter, covering apps that ignore the system proxy setting (command-line tools, some game clients, etc.), but it requires administrator privileges or a system service. For first-time setup, it's best to get the system proxy working end-to-end first; TUN's requirements and caveats are fully covered in the TUN section of the full manual.

Flipping a switch doesn't guarantee traffic is actually being proxied. Spend two minutes verifying it — the same method also helps troubleshoot future issues.

First check — does it actually work: open a browser and visit a site that was previously unreachable; if it loads, that's a good sign. Then visit any IP lookup page and confirm the reported location matches the node you picked in step two. If it still shows your local location, traffic isn't going through the node — keep troubleshooting below.

Second check — is traffic passing through the core: go back to the client and open the "Connections" panel in the left nav. Refresh your browser page, and you should see new connection entries scrolling in live, each labeled with the target domain, the matched rule, and the proxy group actually used. Seeing entries appear confirms the chain app → core → node is working. For a lower-level view, set the log level to info on the "Logs" page to see each connection's rule-matching result.

If the first check fails, work through the following list in order — most issues get resolved in the first three steps:

1. Go back to the Proxies page and run a latency test on the current node; if it times out, switch to another one — a single bad node is the most common cause.
2. Confirm the "System Proxy" switch (or the VPN key icon on Android) is genuinely still on — in some cases other software can flip it back off.
3. Check whether another proxy application is running at the same time; two apps fighting over the system proxy setting will override each other, so quit the extra one.
4. If your browser has a proxy-management extension installed, it takes priority over the system proxy — switch it to "follow system" or disable it and retry.
5. If only a specific site fails while everything else works fine: it's likely being matched to a direct rule under Rule mode — switch to Global mode briefly to confirm, then adjust the rules as a long-term fix.

These five steps cover most first-time setup issues. For more systematic troubleshooting (DNS pollution, port conflicts, TUN-related issues), see the maintenance and troubleshooting section of the full manual.