Clash Setup Guide

Step 1: Import a Subscription and Enable the Configuration

Find the Subscription Page and Check the URL Type

Open the client and go to Subscriptions or Profiles in the sidebar. In Clash Verge Rev, you'll usually find a URL field and an import option on the Subscriptions page. Copy the URL your provider identifies as a Clash or mihomo subscription, paste it in full, and check for extra spaces, line breaks, or text added by a chat app before importing. If your provider offers several formats, choose one explicitly supported by your core—not a link to the account management page.

Wait while the client downloads the remote content. A successful import usually creates a profile card with its name and an update option. If it fails, you may see a request error, a parsing error, or a format mismatch. Read the message before trying again. For request errors, check that the URL is still valid and that your network can reach the subscription service. For parsing errors, make sure the response isn't a login page, error page, or configuration for another client. Avoid repeatedly clicking Import, which can create several similarly named profiles.

Enable the Configuration, Then Check the Proxies Page

Once the profile card appears, select or enable it. Depending on the version, you might click the card, choose Use, or select an option from its menu. Check that the card is marked as selected; a successful download alone isn't enough. Next, open the Proxies page and look for policy groups and selectable nodes. If the profile is present but the page is still empty, return to Subscriptions to confirm it's selected, then check the logs for loading or parsing errors.

For a local YAML file, use the client's file import option; don't paste a disk path into the remote subscription field. Enable the profile after importing it. A node-only subscription is different from a full configuration that includes rules, DNS, and policy groups. Some clients can generate policy groups from their own templates; others need a complete configuration. If expected routing rules are missing after import, first check what your provider included instead of rushing to fill in the entire file by hand.

You're done with this step when the subscription or configuration is enabled, the Proxies page shows the expected policy groups, and the logs have no recurring configuration errors. Keep the default DNS and port settings for now, then move on to choosing a mode. See the glossary for the difference between subscriptions and configuration files, and the protocol guide for compatibility and configuration merging. You don't need to learn it all before your first connection.

Step 2: Choose a Proxy Mode and Exit

Start with Rule Mode

Find the Rule / Global / Direct mode selector on the Proxies page or in the runtime settings. For your first setup, choose Rule. This mode uses the configuration's rules to send each connection direct, through a proxy policy group, or reject it—ideal if you already have a complete configuration. Check that Rule is shown as the active mode. If the selector is in the system tray menu, make sure its state matches the main window.

Global mode sends connections that reach the core through the global policy, but you still need to choose an exit in the relevant policy group. Direct mode sends those connections straight to their destinations. These modes only control how the core handles traffic it receives; they don't route every app's traffic to the core. Switching to Global therefore doesn't make every program on your device use a proxy, and it doesn't replace the system proxy or system VPN setup in the next step.

Select an Exit in the Policy Group

Stay in Rule mode and expand the policy group responsible for proxy traffic. Group names are set by the configuration author: one might be called “Proxy Selection,” while another may be organized by use case. Don't infer its function from its name alone. In a manual group, select a node; an automatic group usually chooses an exit based on the configuration's test criteria. If a group references another group, follow the chain until it ends at a real node—not DIRECT or REJECT by mistake.

Use the client's connection or latency test to rule out obviously unavailable options. These tests usually target a specific address, and results depend on the test target, request method, and current network conditions. A node with a low latency result may not work well for every destination, and a timeout needs to be checked against real-world access. For your first verification, stick with one node that passes a test. Avoid switching repeatedly while browsing, so you can match connections to the right settings.

At the end of this step, you should know that Rule mode is active, which policy group handles proxy traffic, and which exit is selected. There's no need to change load balancing, test intervals, or complex rules yet. If you aren't sure why a rule sends traffic direct, check the matched rule after a connection is made, then see FAQs for guidance. Keeping the original configuration intact helps separate connection issues from rule changes.

Step 3: Route Traffic from the System to the Core

On Desktop, Turn On the System Proxy First

Return to the client settings and confirm the current configuration is loaded and the core isn't reporting an error. Then turn on System Proxy. This usually points the operating system's proxy settings to a local listening port, so browsers and apps that support system proxies send requests through the client. Don't copy an example port from the settings window into another app. If you need to configure an app manually, use the address and port currently shown by the client, and confirm the corresponding listener is active.

Once the toggle is on, open a browser for the next step. Don't enable TUN at the same time or add another manual proxy in system settings. If System Proxy turns itself off soon after you enable it, or the address in system settings keeps changing, check whether another client is managing the proxy. Close conflicting tools, re-enable the setting, and see if it stays on. If your browser has a proxy extension, make sure it isn't overriding the system settings.

On Mobile, Authorize the Connection When Prompted

Android and iOS clients usually have a Connect or Start button. After selecting a subscription and policy, tap Connect and review the system prompt to add a VPN configuration or authorize the connection. Once authorized, return to the client and check its connection status. The status bar or system settings may also show the VPN state. This means the app is using the system network interface to route traffic; the icon alone doesn't confirm that a request used the expected node.

If the system says another VPN connection is active, decide whether to disconnect it before continuing. Some Android clients offer per-app routing, so excluded apps may bypass the proxy. For your first test, use a browser that isn't excluded. If you cancel the authorization prompt, a brief change in the client button doesn't mean routing is active. Start the connection again and check the authorization result.

Use TUN Only If You Need to Route More Apps

TUN routes traffic through a virtual network interface and can handle apps that don't follow system proxy settings. It may require a service installation, administrator privileges, and routing or DNS changes. After confirming basic browser access, enable TUN according to the client's instructions if an app still bypasses the system proxy. Review permission prompts carefully, then check for errors initializing the virtual interface or routes; don't rely on the toggle's color alone.

During initial troubleshooting, change one routing option at a time and note the status before and after. Whether you should enable System Proxy and TUN together depends on the client and your needs; turning on both isn't a universal fix. See the protocol guide for details on network stacks and DNS routing. For now, establish one traceable traffic path and verify it with a real request.

Step 4: Verify Access, Rules, and Exit

Check Connection Logs for a New Request

Leave the client running, open a new browser tab, and visit a familiar site with stable content. A page loading confirms access, but you still need to check how the request was routed. Switch to the client's Connections page and look for the domain or address you just visited. Check the matched rule, policy group, and exit chain. The fields vary by client, but the checks are the same: Did the client receive the request? Which policy handled it? What exit did it use?

Browser caches, background requests, and reused long-lived connections can make results harder to read. If you can't find a record after opening a page, refresh it, visit another page on the site, or open a private window to create a new connection. Some clients show only active connections, so short requests may disappear; check the logs as well. Before sharing troubleshooting screenshots, hide subscription URLs, credentials, and any destinations you don't want to disclose.

To check the exit IP, compare the public IP shown for a direct connection and the expected proxy route under the same network conditions, and check the client logs at the same time. In Rule mode, the IP lookup site itself may go direct, so an unchanged IP doesn't by itself mean the proxy failed. First check which rule matched the lookup request, then interpret the result. Don't switch to permanent Global mode just to make one lookup page show a different IP.

Narrow Down the Problem by Where It Appears

If a page won't load and the client has no matching request, check the routing setup from step 3 first: Is System Proxy still on? Is the browser using system settings? Is the mobile VPN still connected? Was the app excluded by per-app routing? Switching nodes repeatedly won't help if traffic never reaches the core. If browsing works but a particular app has no connection record, check that app's proxy settings or routing method first.

If a request appears in the logs but the connection fails, check the selected policy group and final node. Try another exit for the same destination. If only one exit fails, focus on that exit's service status. If multiple exits fail, read the error logs and distinguish DNS resolution, connection timeouts, authentication failures, and certificate errors. Don't disable certificate validation, change DNS, and rewrite rules all at once; even if that fixes the issue, you won't know why.

If only a few sites are affected, check whether they matched a direct, reject, or dedicated policy, then look for app-specific DNS, browser Secure DNS, or stale connection caches. There's no need to rewrite all your DNS settings based on one failed request during initial setup. For a step-by-step guide, see Troubleshooting FAQs. Check the glossary for terms such as Fake-IP and rule providers.

Keep the Working Setup, Then Finish Testing

Once everything works, note the configuration name, mode, and policy group selection. Keep this working setup as a reference before making changes. Remote subscription updates may overwrite the subscription's contents. For changes that need to persist, use the client's supported override or merge feature instead of editing a file that updates will replace. Learn more after your first connection in the protocol and core reference.

When you're done, turn off System Proxy on desktop before quitting the client. If TUN is enabled, stop it using the client's shutdown procedure. On mobile, tap Disconnect and confirm the system VPN has ended. If regular internet access fails after quitting, first check whether the system still has a manual proxy pointing to your local machine rather than deleting all your settings. Keep a record of the steps that worked; next time, check configuration, mode, routing, and verification in order.