Clash subscription and connection setup

Step 1: Import a subscription and activate the configuration

Open your service provider's subscription page and find an entry labeled as compatible with Clash, Clash Meta, or mihomo. Use the page's copy button to copy the full URL. A subscription URL is usually an HTTPS link with a path or query parameters, not an account sign-in page. Don't remove any parameters or submit the URL to a public forum or online converter; anyone with the link may be able to access the subscription contents.

Return to Clash Verge Rev and click “Subscriptions” in the sidebar. Paste the URL into the subscription field, check for extra line breaks, spaces, or quotation marks, then click “Import.” Some clients require you to click Add first, choose Import from URL, then enter a name and URL. The name only helps you identify the configuration; use a short label that tells you where it came from. Don't change the URL itself.

Keep your internet connection active while importing, and wait for the configuration to appear as a card or list item. When the download finishes, select the configuration and set it as the active one. Clients may show this with a check mark, highlighted border, or “Use” button. Seeing a configuration in the list doesn't necessarily mean it's active. Open the “Proxies” page and confirm that its proxy groups and available servers are listed.

If your service provider supplies a local YAML file, choose “Import File” on the Subscriptions or Configuration page, then select the file. A valid file extension doesn't guarantee compatible contents: a page saved from a browser, account details in a text file, or a standalone server share link cannot be used as a complete configuration. For a single share link, first check whether the client supports that import method. Don't paste it directly into the subscription URL field.

If parsing fails, check that you haven't copied a dashboard URL, a web sharing link, or an expired URL by mistake. An error saying the response is HTML usually means the request returned a sign-in page, error page, or verification page instead of a configuration. Return to your provider's site and get a compatible subscription URL. If the request times out, try again on your current connection. Before the first connection is established, don't enable “Update through proxy”—the update would depend on a proxy route that isn't working yet.

Servers and rules in a subscription may change over time. After the first successful import, run one manual update from the configuration menu to learn where the update control is, then enable automatic updates if needed. Use the client's override or merge feature for custom settings you want to keep; edits to files generated from a remote subscription may be overwritten during the next update. For update intervals and format compatibility, see the Help Center. For now, keep the defaults and choose a proxy mode.

Step 2: Choose rule mode and a proxy server

Once the configuration is active, open the “Proxies” page and look for the “Rule / Global / Direct” mode selector. Clash Verge Rev may also offer the same control in Settings or on the home screen. For your first setup, choose “Rule.” The client will use the active configuration's rules to decide whether each request connects directly, goes to a proxy group, or is blocked. Rule mode isn't a fixed list of websites; its behavior depends on the configuration's rules and their order.

Next, check the proxy groups. Group names are set by the configuration author and may be in Chinese, English, or named for their purpose; they don't have to match the names in this guide. Find the selection group used for regular proxy traffic, expand it, and choose an available server. If the group contains other groups, check the next level until the selection resolves to a server or a clear auto-select policy. If the group selects DIRECT, that route connects directly rather than using a remote proxy.

If the client offers a connectivity test, you can run it here as a reference when choosing an egress. A successful test only shows that the test destination was reachable at that moment; it doesn't guarantee access to every site. A failed test may be caused by the test destination itself. Start with the egress recommended by your service provider, then use real requests and the connection log in Step 4 to check it. There's no need to repeatedly adjust every proxy group during your first setup.

“Global” mode sends regular requests handled by the core to the selected global group instead of routing them individually by the usual rules. After switching to Global, check what the global group actually selects; it doesn't automatically reuse the selections from all rule-based groups. Global mode is useful for temporarily checking whether a routing rule is causing an access problem, or for tasks that genuinely require a single egress. When you're done testing, switch back to Rule mode and make a new request to verify the result.

“Direct” mode sends regular requests handled by the core straight to their destinations. You can use it for comparison tests, but it doesn't shut down the client or clear the operating system's proxy settings. Turn off the system proxy before quitting the app. TUN is a separate setting: Rule, Global, and Direct determine how requests are handled after they reach the core; the system proxy and TUN determine how requests get to the core.

Stay in Rule mode and note the proxy group and server you selected. You don't need to switch to Global just to get online or turn on every network option at once. If a site later uses an unexpected route, check the connection log to see which rule matched. For rule syntax and advanced routing, see the Troubleshooting Guide. For your first setup, keep to this minimal working path.

Step 3: Enable the system proxy or connect to the VPN

Go back to “Settings” in the desktop client, find “System Proxy,” and turn it on. This points the operating system's proxy settings to the local client, allowing browsers and other apps that follow the system proxy to send requests through it. If the client has a separate button to start its core, make sure the core is running first. If the app window is open but the core failed to start, the system proxy switch may be on, but requests still won't be routed.

In Clash Verge Rev, you can also check the “Mixed Port” setting. A common value is 7897, but use the value shown in your client. The mixed port accepts HTTP and SOCKS requests; the external controller address is used to manage the core and isn't a browser proxy port. You don't need to change the port just to match another guide. Simply check that there are no port conflict errors.

To check the operating system settings after enabling the proxy, open “Settings → Network & Internet → Proxy” in Windows, or “System Settings → Network → Current Network Service → Details → Proxies” in macOS. The labels may vary by OS version. For local use, the address should usually be the loopback address 127.0.0.1 and the port the client is actually listening on. Don't copy a LAN address from a screenshot onto your device.

Android and iOS use a different flow: after setting up the configuration and choosing a proxy group, return to the client's home screen and tap “Start” or “Connect.” The first time, the system will usually ask to add a VPN configuration or approve a VPN connection. Check which app is requesting access, then allow it. A VPN indicator means the tunnel is up; it doesn't guarantee that every subscription egress works. If another VPN is already running, disconnect it before starting this client.

Get the browser working before enabling TUN

The system proxy is usually enough to test browser access, but some command-line tools, games, and other apps don't follow it. To route those apps, open “Settings → TUN Mode.” Desktop clients may first ask you to install a service, grant administrator permissions, or configure network permissions on Linux. Follow the client's instructions before enabling TUN. For your first test, keep defaults such as the stack setting and don't change routing or DNS options at the same time.

Enabling TUN doesn't guarantee that every connection will be captured; coverage also depends on routing, exclusions, and the active configuration. If you're only using a regular browser, keep the system proxy on and TUN off until the Step 4 checks pass. When testing TUN for the first time, consider turning off the system proxy to reduce the number of variables. If you need both, configure them according to the client's recommendations and the needs of your apps.

You don't need to enable “Allow LAN” for local use. This setting lets other devices access the proxy port on your computer and involves the listen address, firewall, and access scope. It's not required for your first connection. Set the client to launch at startup later if needed; while troubleshooting, starting it manually makes it easier to confirm which client is running. When you're done, turn off the system proxy or stop the VPN before quitting the app to avoid leaving system settings pointed at a stopped port.

Step 4: Verify access and matched rules

Leave the client running and open a new browser tab. First visit a site you can normally reach directly, then open the target site you want to access through the proxy. Don't just refresh a page that's already loaded; cached content may mean no new request is sent. If your browser has an extension that manages proxies separately, turn off its proxy feature so this test uses the operating system's proxy settings.

Next, open the client's “Connections” page and revisit the target site in your browser. Check for a new connection to the corresponding domain. Expand its details to see the destination, matched rule, and proxy chain; field names vary by client. In Rule mode, it's normal for a directly accessible site to show DIRECT. A site that should use the proxy should route through the expected proxy group and server. Check the actual route—not whether every connection goes through the proxy.

A webpage often requests images, scripts, and other domains, so the connection list may show several destinations. Look for the main site's domain first, then compare it with what you see in the browser. If a request finishes too quickly to appear in the list, watch the connections while reopening the page or briefly check the connection details in the logs. You don't need to leave verbose logging enabled. Before sharing screenshots, hide subscription URLs, account details, and other sensitive information.

Optional: Test the local port with an explicit proxy

If you're comfortable using a terminal, run the command below to test the mixed port directly. It explicitly uses the local proxy, so it doesn't depend on whether the terminal follows the system proxy. Replace 7897 with the actual value shown in the client. On Windows, use curl.exe to avoid differences with the command of the same name in older PowerShell versions. This is an optional diagnostic, not a required step.

curl --head --proxy http://127.0.0.1:7897 https://example.com

If the command returns HTTP response headers, the request received a response. Check the client's connection log to see whether it used a direct route or a proxy egress. If it can't connect to the local address, check the core and port first. If the browser works but a terminal command without proxy arguments fails, that doesn't necessarily mean the client is broken: many terminal tools don't automatically follow the system proxy and need app-specific settings, environment variables, or TUN support.

If verification fails, use the symptoms to narrow down the cause. If there's no matching browser connection, check whether the system proxy is active and whether the browser uses its own proxy. If there's a connection but it routes to DIRECT, check the matched rule and proxy group. If it reaches the expected server but still fails, check the server and target site. Investigate DNS only if some domains fail to resolve; don't replace the entire DNS configuration as a first step.

As a temporary test, switch to Global mode, select a global egress, and send a new request to the same destination. If Global works but Rule doesn't, focus on the routing rules. If both fail, check the connection, egress, and DNS. This comparison is only useful if both modes use the same server; otherwise, you've changed both the mode and the egress, making the cause harder to identify. Change one setting at a time and note the result.

When you're done, switch back to your usual Rule mode and confirm that one direct destination and one proxied destination behave as expected. Your subscription, proxy group, traffic entry point, and actual requests now form a complete route. If access breaks after a subscription update or network change, check these same steps in order. For general questions, visit the Help Center. For persistent connection failures, subscription errors, DNS issues, or mobile background interruptions, continue with the Troubleshooting Guide.