Step 1: Import a Subscription and Enable the Configuration
Before you start, make sure the client opens correctly and your subscription is still active. A Clash client reads the configuration and routes traffic; installing the client does not provide proxy nodes. Your provider usually supplies the subscription link, which may contain account identifiers. Treat it as private: don't post the full link in public forums or submit it to unfamiliar online conversion tools.
Import a Subscription in Clash Verge Rev
Open Clash Verge Rev and select Subscriptions in the sidebar. Some versions may call this Profiles. Find the subscription URL field, paste the address your provider identifies as compatible with Clash or mihomo, and click Import. If a new-profile dialog appears, choose Remote and enter a short, recognizable name. The name is only for local organization; it doesn't change the subscription. Confirm and wait for the download to finish. Don't repeatedly import the same URL.
After a successful import, you should see a profile card or entry in the list. Select it, confirm it's active, then open Proxy and check for policy groups and available nodes. Some clients enable imported profiles automatically; others only save them. Confirm both that the subscription appears in the list and that the core is using it. If the old and new profiles differ, switching profiles should also change what's shown on the Proxy page.
On Android and iOS, subscription or profile pages usually have a plus button for importing from a link. Paste the address, save it, then return to the profile list and enable it. The system share menu may also let you send a subscription link to the client, but always return to the client to check which profile is active. Before importing from a QR code, confirm it came from your provider. A QR code that opens an ordinary webpage doesn't mean you've imported a usable configuration.
Local Files and the First Update
If you have a YAML file, use Import File or Local Profile to select it; don't paste its contents into the subscription URL field. Whether a local file can be updated depends on its contents and the client, so don't assume it can refresh like a remote subscription. Nodes, policy groups, and rules in a configuration each serve a purpose. Leave them unchanged for your first setup. To understand how they fit together, see the glossary; there's no need to edit the file by hand at this stage.
If importing fails, first check that the URL is complete, especially for stray spaces or line breaks added when copying it from a messaging app. Then check the client's error: a download failure means the content wasn't retrieved, while a parsing failure means the content isn't valid in the selected configuration format. Login pages, error pages, and formats intended for other clients can all cause parsing errors. Confirm the subscription type with your provider instead of repeatedly changing rules. Continue to mode selection only after the Proxy page shows policy groups.
Step 2: Choose a Mode and Outbound Node
Once the configuration is enabled, find Outbound Mode on the client's home, Proxy, or Settings page. The usual options are Rule, Global, and Direct. For your first connection, choose Rule mode. It uses the configuration's rules to decide which policy group or direct route each connection takes. This mode controls how traffic is handled after it reaches the core; it doesn't send browser or app traffic to the core in the first place. That's covered in Step 3.
| Mode | How It Handles Connections | When to Use It First |
|---|---|---|
| Rule | Routes traffic according to the active configuration's rules | A good everyday starting point; check the connection log to confirm rule matches |
| Global | Applies the selected global policy to connections entering the core | Use briefly for comparison; you still need to select an available outbound |
| Direct | Sends connections entering the core directly to their destinations | Use for a direct-connection comparison; it doesn't confirm that proxying works |
Next, open Proxy and find the main outbound policy group. Its name comes from the subscription and might be “Node Selection,” “Proxy,” or something else—not necessarily PROXY. Expand the group and select an available node. Check that the selection indicator moves. If the group contains other policy groups, follow the selected entry until you can tell whether the final outbound is a specific node or a direct route.
Some configurations have separate policy groups for video, code hosting, or chat apps. Selecting a node in the main group doesn't automatically override those groups. For your first check, confirm the group used by the site you're testing. If you're not sure which group that is, connect anyway and use the connection log to find the actual route. Don't assume a site uses a node just because of its name; the rules and policy-group references determine the outbound.
Test Clash Node Latency
Click the test button next to a policy group, or use the client's latency test, and wait for the results. The test shows how the client reaches a test address through that outbound; its meaning depends on the client and test method. It doesn't measure download bandwidth or guarantee access to every site. If a node times out, try another in the same group. A lower reading on one test doesn't mean a node is best for every app.
After the test, check the selected entry again. Some buttons only test connectivity and don't change the current node in a manual-selection group; an automatic-selection group switches according to its own configuration. For your first setup, keep a node that reliably opens the target page and avoid repeated tests that interrupt troubleshooting. For more on selection groups, automatic selection, and failover, see the Advanced Policy Groups guide.
To compare results with Clash Global mode, switch modes and check the global policy's current outbound. Global mode doesn't route all device traffic automatically or fix an unavailable node. When you're done testing, switch back to Rule mode so later checks follow the route expected by your configuration. See Outbound Modes for details.
Step 3: Connect and Route Traffic Through the Client
Your configuration and outbound are set. Now make sure the apps you use send traffic through the client. On desktop, start with the system proxy—it's easier to verify. On mobile, use the VPN connection flow. If another proxy tool or VPN is running, disconnect it first so you have only one test variable. Change one traffic-routing method at a time; that makes it easier to identify what caused a problem.
Set Up the System Proxy on Desktop
In Clash Verge Rev, open Settings and enable System Proxy. Then open the operating system's network proxy settings and confirm the status has changed. The client usually points the system proxy to a local listening address and port. Use the values shown in the client; don't force your device to use port 7890 just because it's common in examples. Custom configurations and other apps may use a different port.
Browsers that use the system proxy should route new connections through it. Check for browser proxy extensions or custom proxy settings that might override it. Browsers such as Firefox may have separate network settings; make sure they use the system proxy or configure them with the listener details shown by the client. After making changes, open a new window before testing so you don't reuse an existing connection. Command-line tools and some apps may ignore the system proxy, so don't use them as the only measure of whether your first setup works.
Changing network settings on macOS may trigger a permission prompt. Clients that install a service or helper component may request additional permissions. Check the app name in the prompt before approving, then return to the client and confirm the switch is still on. On Linux, if the desktop network settings don't update, set the proxy explicitly in the app to test it. Don't repeatedly change system network options without noting their original values.
Connect on Mobile and Approve VPN Access
On Android and iOS, return to the client's home screen and tap the connect switch. The first connection usually prompts you to approve a system VPN configuration or connection request. Approve it, wait for the client to show Connected, then check that the system shows the corresponding VPN status. This confirms the system has established the traffic-routing tunnel the client needs; it doesn't prove the remote node works, so complete Step 4 as well.
If the switch turns off immediately, check whether the system denied permission or another VPN is still connected. On Android, also check Always-on VPN, per-app routing, and battery management settings to ensure another app isn't restricting the connection. On iOS, check in Settings that the active VPN configuration belongs to the client you're using. Don't rapidly toggle the switch before the connection prompt is complete; repeated start-and-stop attempts make the status harder to diagnose.
When to Switch to TUN
Consider TUN if a browser follows the rules but an app that ignores the system proxy still connects directly. Enable TUN in Settings, then install the required service or grant administrator permissions as requested by the client. Keep the default stack for your first test. Verify that it works before changing DNS, routes, or the protocol stack. The virtual interface, routing, and app exclusions can all affect the result; a colored switch alone doesn't confirm that traffic is being routed.
If enabling TUN cuts off internet access across the device, turn TUN off and return to the system proxy route you already verified. Once access is restored, check the logs; don't reset all your settings right away. TUN, Fake-IP, and DNS combinations are later optimizations, not requirements for your first connection. Start with the traffic routing and DNS glossary to learn more.
Step 4: Verify Your Connection
Open the client's Connections page and leave it visible. In a new browser window, visit a familiar HTTPS site with stable content. Check whether the client logs the domain or destination address, then inspect the matched rule and outbound route. Some clients hide these fields until you expand the connection details. Short-lived connections may disappear quickly, so open the log before refreshing the page.
If the page loads and the log shows the expected policy group and node, the request reached the core and followed that route. Next, visit a page you expect to connect to directly and check whether the log shows DIRECT. Some direct connections are normal in Rule mode and don't mean proxying has failed. If the configuration uses a bypass mechanism, some direct traffic may not appear in the core's logs, so check your traffic-routing settings too.
You can also check a trusted IP lookup page, but first confirm which rule routes that page. It shows the exit address observed for that request, not the route used by every app or domain. Browser caching, reused connections, and different address families can also affect results. Compare the page's result with its connection log; don't judge by the taskbar icon or VPN indicator alone.
Troubleshoot in the Same Order
If the client shows no test request at all, return to Step 3 and check the system proxy, browser-specific proxy settings, or mobile VPN status. If a request appears but uses DIRECT when you expected a proxy, check the rules and policy-group selection before switching nodes. If the log confirms traffic went through a proxy node but timed out, try another node in the same group. These cases point to traffic routing, rule selection, and outbound connectivity, respectively. Troubleshoot them separately instead of changing multiple settings at once.
If the logs show a DNS or parsing error, keep the original configuration intact. Check whether direct access can resolve names and open common sites, then see whether the issue affects only specific domains. Don't copy a full DNS configuration from the internet over your subscription, or change system DNS, client DNS, and browser encrypted DNS all at once. When reporting an issue, note the client, operating system, steps to reproduce, and exact error text. Before sharing logs, remove subscription URLs, account identifiers, and other sensitive information.
After a successful check, note the active configuration, mode, and policy-group selection. If anything changes after refreshing the subscription, first confirm that the original configuration is still active and that the policy group retained its selection. When you're finished, turn off the system proxy or disconnect the VPN in the client before quitting. If your browser loses access after you exit, check system network settings for a manual proxy still pointing to localhost.