Clash Verge Rev separates the profile you import from the proxy group and node you choose for traffic. A subscription URL usually points to a remote configuration or node list supplied by a provider. Adding it creates a profile in the client; updating it fetches the provider’s latest version; selecting it makes that profile available to the running core. These are separate actions, so a profile can appear in the list without being active, or be active while its nodes are not yet selected in the relevant proxy group.
This walkthrough covers importing a subscription, checking that it loaded correctly, refreshing it, and switching profiles. Menu labels can differ between Clash Verge Rev releases and operating systems, but the workflow is broadly the same on Windows, macOS, and Linux. Clash Verge Rev is the graphical client; the core it runs, often mihomo, is responsible for parsing the configuration and handling connections.
Clash Verge Rev Subscription Setup: How to Add and Update Profiles
Before importing: check the link and the profile type
Start with the exact subscription address provided by your service. Copy the complete URL, including its protocol and any query string, rather than retyping it. Long subscription links may contain account-specific tokens after a question mark; losing even one character can cause an authorization error. If the provider gives separate links for Clash, mihomo, or another client format, choose the one intended for Clash-compatible clients.
A subscription endpoint does not always return the same kind of content. It may provide a complete Clash-compatible configuration, a list of proxy nodes, or content that depends on the client’s request headers. Clash Verge Rev and its selected core must be able to interpret the returned format. If the provider supplies a client-specific link, import that link rather than a browser or dashboard address. A web page that opens successfully in a browser is not necessarily a valid subscription URL.
| Profile source | What it represents | How it changes | Typical check |
|---|---|---|---|
| Remote subscription | A URL that retrieves provider-managed configuration or proxy data | Use the profile’s update action to fetch the current response | Check the last update result and whether expected nodes appear |
| Local configuration | A file stored on the computer, commonly a YAML file | Replace or edit the file, then reload it in the client | Check the file path, syntax, and core compatibility |
| Active profile | The profile currently selected for use by the client | Select another available profile in the profile list | Confirm the active indicator and inspect the proxy groups |
Before you begin, make sure the computer can reach the provider’s service. If the subscription is accessible only through an existing network route, you may need to establish that route first. Also check whether the provider requires a valid account, has a device limit, or has an expiry date. These conditions are outside the client’s control: changing a Clash setting will not restore an expired or revoked link.
If you already have a working profile, leave it in place while testing the new one. Keeping a known-good configuration gives you a recovery path if the new URL is mistyped, the server is temporarily unavailable, or the returned configuration does not parse.
Add a subscription profile in Clash Verge Rev
Open Clash Verge Rev and go to the page or sidebar section named Profiles. In many builds, the add-profile control is shown as a plus sign, a download/import control, or an option to add a remote profile. Select the remote or URL-based option. If the dialog offers both a URL field and a local file picker, use the URL field for a subscription link; selecting a local file does not register a remote subscription.
Enter a recognizable profile name, such as the provider name and the device or purpose. A useful name is short but specific: “Travel laptop” is easier to identify than “New profile 2.” Then paste the full subscription URL into the URL field and save or confirm. Do not add extra spaces, quote marks, or explanatory text around the address. If the client offers an option to test or fetch the URL during import, allow the request to complete before closing the dialog.
After saving, look for the new entry in the profile list. The first import may take longer than a later refresh because the client needs to retrieve and parse the response. A successful import should generally leave an entry that can be selected and show configuration data such as proxy groups or nodes. An entry appearing in the list alone is not proof that the core can use it.
Now select the profile if you intend to use it. Depending on the build, selection may use a check mark, a highlighted row, a play or enable control, or a separate action. Avoid deleting the previous profile until you have confirmed that the new one works. If the client asks whether to start or reload the core after switching, allow it to do so and wait for the status to settle before testing traffic.
- Open Profiles and choose the remote-profile option.
- Enter a name and paste the complete provider URL without modifying it.
- Save the entry and wait for the initial download and parsing to finish.
- Select the new profile, then confirm that it is marked as active.
- Open the proxy or groups page and check for the groups and nodes expected from the provider.
Verify the imported profile before relying on it
Once the profile is active, check the client’s status and logs before changing several settings at once. A healthy start usually means the core accepted the configuration and its proxy groups are visible. If you see a parse error, a missing configuration, or an empty list, the failure may have occurred during download or while the core interpreted the response. The client’s error message and log are more useful than repeatedly clicking the import control.
Check groups, nodes, and the selected route
Open the Proxies page or its equivalent. A provider may return multiple groups—for example, a region selector, an automatic selection group, and a group used by rules. Expand nested groups if necessary and confirm that the expected nodes are present. Then choose an available node in the group used for your test destination. Selecting a node in an unrelated group may not affect that destination.
For a controlled check, use one site or application and note which proxy group its request should match. If the client has a Connections page, open it after making a new request and inspect the matched rule and route. The connection may show a group name and a final node, or it may show DIRECT. That evidence helps distinguish a profile problem from a rule or traffic-capture problem.
A successful node delay test is only evidence that a particular test request received a response. It does not prove that every website will use that node, that system proxy settings are enabled, or that TUN is capturing all applications. Test with a new connection after switching profiles or nodes: existing connections can continue using their original route until they close.
Understand what a remote update can replace
A remote profile is generated from the provider’s response. If you edit its downloaded configuration directly, a later update may replace those edits. Keep a copy of any local configuration you maintain, and use a supported override, merge, or patch mechanism if the client and profile type provide one. Do not assume that changes made in one configuration will be copied into another profile automatically.
Also distinguish provider data from client preferences. A provider can change nodes, group names, rules, or other configuration content in a new response. Your selected profile and some client-side choices may be stored separately, but the exact behavior depends on the client version and configuration structure. After an update, recheck the groups you rely on instead of assuming every prior selection is unchanged.
Update subscriptions and switch between profiles
To refresh a remote profile, return to Profiles, select the profile you want to refresh, and use its update or refresh action. Some builds show the action in the profile row; others place it in a context menu or detail panel. Wait for the request to finish, then check the reported result or timestamp. A successful refresh means the client obtained and accepted a response; it does not necessarily mean the provider changed the available nodes.
For a manual refresh, keep the profile selected unless you have a reason to switch. If the provider has just changed a node or fixed an issue, updating the active profile and then checking the proxy list is a straightforward verification. If you want to test an alternative configuration, switch to that profile explicitly and confirm that the active indicator changes. Do not infer the active profile from the order of entries in the list.
If an automatic update interval is available, set it according to the provider’s guidance and your needs. A shorter interval does not make the connection faster; it only causes the client to request profile data more often. Frequent requests can create unnecessary network traffic or reach a provider’s request limit. If the profile includes a provider-specified update interval, avoid overriding it without a reason.
When switching profiles, allow the core to reload and check its status before testing. Compare the proxy groups afterward: two profiles may have similar names but contain different rules, nodes, or group structures. If a website still appears to use the old route, close its existing connection or start a fresh request, then inspect the connection details. Switching a profile is not the same as changing the selected node within a profile.
A practical maintenance routine is to update only when needed or at the interval recommended by the provider, verify the result, and keep the last-known-good profile until the replacement works. If you manage several profiles, record a clear name and purpose for each one. Avoid making multiple changes—such as changing the core, DNS mode, proxy mode, and profile URL—at the same time, because it becomes harder to identify which change caused a new symptom.
Troubleshoot failed imports and updates
Start by identifying where the operation failed: saving the URL, downloading the response, parsing the configuration, starting the core, or routing a test connection. These stages have different causes. A red error message in the profile list, a parser error in the log, and a working profile with no traffic are not the same problem. Record the exact message, the time of the attempt, the profile name, and whether another profile still works. Redact the subscription URL and account tokens before sharing any diagnostic information.
| Symptom | Likely causes | Safe checks |
|---|---|---|
| Import says the URL is invalid | Incomplete copy, extra spaces, wrong link type, or an expired URL | Copy the provider’s Clash-compatible link again and check account status |
| Update times out or returns an HTTP error | Network interruption, provider outage, access restrictions, or rate limits | Retry once on a stable connection and check the provider’s status or guidance |
| Profile downloads but the core reports a parse error | Unsupported format, malformed YAML, or core-feature incompatibility | Read the first useful log error and confirm the provider’s intended client format |
| Profile loads but has no expected nodes | Empty provider response, account limits, filtering, or a different profile type | Check the provider dashboard and compare with its documented subscription format |
| Profile is active but an app does not use it | Rule route, proxy-group choice, system proxy, TUN, or an existing connection | Inspect a new connection and verify the matched rule and final route |
If the URL is rejected, copy it again from the provider’s account page and check for accidental line breaks or spaces at either end. Do not manually remove query parameters that look unfamiliar; they may be required for authorization. If the provider has multiple formats, confirm that the selected one targets Clash or mihomo rather than another client. If the link previously worked but now fails, check whether it expired, was reset, or reached an account or device limit.
If the request times out, first confirm that the computer’s internet connection is stable. Retry once after a short wait and check whether the provider reports an outage or maintenance. A proxy may be required to reach the provider’s endpoint, but avoid changing several routing settings just to make a single update work. If the endpoint returns an HTTP status, keep the status code and time for support; it can help distinguish access denial, rate limiting, and a temporary server error.
If the download completes but the core reports a parse error, check the log for the first meaningful error rather than the last line of a long startup sequence. A format intended for a different client, unsupported fields, or YAML indentation problems can prevent a configuration from loading. If the provider manages the content, do not edit the remote profile as the first fix. Ask for a compatible link or an updated configuration, and confirm which core versions the provider supports.
If the profile loads but a particular application cannot connect, verify that the profile is active, the relevant proxy group contains usable nodes, and the destination’s connection is routed as expected. System Proxy affects applications that honor the operating system proxy setting; TUN can capture a broader set of traffic but depends on client, core, permissions, and routing configuration. Neither setting repairs an invalid subscription. Check the client’s logs and connection details before changing DNS or resetting the entire configuration.
If an update fails once but the current profile still works, avoid deleting it or importing the same URL repeatedly. Keep the working profile, save the sanitized error details, and retry after confirming the URL and provider status. Once a replacement profile has loaded, the core has started, and a new test connection follows the intended group and node, you can decide whether the older profile is still needed.