How profiles, subscription links, and YAML files relate

A profile is a config entry managed by the client—not a proxy node or the subscription link itself. It typically stores a name, source, last-updated time, and the associated YAML content. Selecting a profile tells the client to generate or load runtime settings from that config; the proxy groups in it determine which nodes are used.

Clients such as Clash Verge Rev usually call this section “Profiles” or “Config.” Profile formats aren't consistent across clients, and supported YAML fields can vary by core. Configs supported by the original Clash aren't necessarily interchangeable with Mihomo's extended config format, especially when using newer protocols, rule providers, or specific DNS fields.

ItemWhat it doesWhat to manage
Subscription linkAddress used to retrieve a remote config or node dataCheck the format, expiration, and access permissions
Local YAMLConfig file saved on your deviceBack up changes; check indentation and field compatibility
ProfileProfileConfig entry you can select, update, or delete in the client
Runtime configConfig the client actually passes to the coreAccount for overrides, merges, and client settings

A remote profile typically works like this: the subscription URL returns content, the client saves a local copy, and the selected profile is passed to the core. Whether it can still load offline depends on whether the client keeps a usable copy. Whether the nodes in that copy can connect is a separate question. A profile still appearing in the list doesn't prove that its subscription is active.

Import a subscription: verify the URL, then activate the profile

Get a Clash- or Mihomo-compatible subscription URL

On your provider's subscription page, choose a URL explicitly labeled Clash, Clash Meta, or Mihomo, and check that your client's core supports it. A link to the account or billing page, or a generic subscription for another protocol, may not provide a complete Clash config.

Subscription URLs often contain access tokens, so anyone with the full link may be able to view node details. Don't post it in public chats, screenshots, or online YAML checkers. When asking for help, share only the error message and redact the path, query parameters, and node credentials.

Using the “Profiles” page in Clash Verge Rev

  1. Open “Profiles,” paste the URL into the subscription field, and click “Import.” If your version has a “New” option instead, choose the Remote type and enter a name and subscription URL.
  2. Wait for the profile card to appear. Check for download or parsing errors and verify the update time. Don't keep clicking Import while the request is still in progress.
  3. Give the profile a short, descriptive name that identifies its source and purpose, such as “Daily - Main Subscription.” Select the card and confirm that it's marked as active.
  4. Open “Proxies” and confirm that proxy groups and nodes are listed. For everyday use, start with Rule mode and select a node in the proxy group you use.
  5. Go back to “Settings” and check the system proxy status. If you plan to use TUN, first make sure the service, permissions, and related settings are working; then enable it separately to make troubleshooting easier.

Button names and locations can vary between releases, but the success criteria are the same: the config downloaded, parsed successfully, is selected, and loads without core errors. Seeing an “Import successful” message alone doesn't mean your app traffic is passing through the client.

Imported successfully, but no nodes appear?

  • The response is a web page: If the config view shows login text or HTML tags, the URL may be wrong, require authentication, or return an error page.
  • Only a list of nodes: Content containing only proxies may need matching proxy groups and rules. Don't assume it's a complete, ready-to-use config.
  • Unsupported fields: Look in the logs for the specific field or protocol, then confirm that your client's core supports it. Reimporting the same URL won't fix incompatibility.

Import local YAML and edit remote configs

If you already have a file, use the local-file import option on the “Profiles” page and select a file with a .yaml or .yml extension. The client may copy it to its data directory or keep a link to its original location; check how your client handles imports. Editing the original file on your desktop after import may not update the imported copy.

When checking YAML, start with indentation and references. Use spaces, not tabs. Every proxy group referenced by a rule must exist, and every node referenced by a group must match a node name. Here's a structural example with direct connections only; it doesn't include any usable proxy nodes:

mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: Daily selection
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Daily selection

Here, MATCH,Daily selection refers to the proxy group with the same name above, and that group contains only DIRECT. Once loaded, all matching connections go direct, so this example is useful for understanding the structure, but not for testing whether a proxy works. For field descriptions, see the config reference.

Switching profiles: saving several doesn't mean running them all

Most Clash GUI clients let you save multiple profiles, but usually only one can be selected as the primary runtime config. The client's global settings, overrides, and remote providers referenced by that profile may also contribute to the final config. Importing two subscriptions doesn't automatically merge their nodes into the same proxy group.

Name profiles by purpose, not just by import date

  • Daily - Main subscription: Keep stable rules and frequently used proxy groups here as your default.
  • Backup - Separate provider: Switch to this if the main subscription has issues, and check periodically that it still updates.
  • Test - Local rules - 20260804: Use this to test changes. Include the date in the name to distinguish it from your production config.

Check these three things after switching

  1. Active status: On the “Profiles” page, confirm that the active marker moved to the intended card. If the logs report a load failure, the click alone doesn't count as a successful switch.
  2. Proxy group selection: Open “Proxies” and check the selected node. If the profiles use different group or node names, the client may not keep your previous selection.
  3. Actual connection: Test with a newly opened webpage or a new request, then check the connections list for the matched rule and outbound policy.

Existing connections may keep using their original route, so you don't need to clear every connection immediately after switching. Test a new connection first. If an app still uses the old route, restart it or close its connection once you're sure the session can be interrupted. Take extra care when switching during a download, meeting, or remote desktop session.

To use multiple sources at once, you typically need a config approach such as proxy-providers or a merge feature explicitly supported by the client. This is a separate layer of config management: check provider formats, reference names, and update behavior. Don't simply concatenate two complete YAML files.

Auto-updates: distinguish subscriptions, proxy providers, and rule providers

Updating a remote profile fetches the content at its subscription URL. Updating proxy-providers fetches the node providers referenced by the config; updating rule-providers fetches rule sets. These may all use separate schedules, so updating one doesn't mean the others have updated too.

Set the update interval using the units shown in the client

On the “Profiles” page, open the edit menu for the profile and look for “Auto Update” or “Update Interval.” If the unit is minutes, try 1440 minutes, or once a day. If it's hours, enter 24 hours. This is a management recommendation, not a default for every client, and updates may not run on schedule while the device is asleep.

The YAML provider interval is usually measured in seconds. For example, interval: 86400 means one day. Don't copy 1440 minutes from the client interface as 1440 seconds in a provider setting; that would be only 24 minutes and would greatly increase request frequency.

  1. After setting the interval, run a manual update to confirm that the network and subscription URL are working.
  2. Note the profile card's last-updated time, then check whether it changes the next time you start the client.
  3. If the client offers a “Update via proxy” option, choose based on actual network access. If the proxy node has stopped working, relying on it to fetch a new subscription can create a loop.
  4. If the nodes don't change after an update, check that this is the profile in use and whether the nodes actually come from a separate provider.

Delete old profiles: switch first, then back up and clean up

Deleting a profile usually removes its config entry and associated file from the client. It doesn't cancel your subscription with the provider, and may not delete all historical data saved by the client. If a subscription URL has been exposed, deleting the card isn't enough: reset the URL in your provider's account page and update it on each device.

  1. Confirm a working replacement: Select the profile you plan to keep and verify access with a new connection.
  2. Back up what you need: Export or copy any local rules and YAML you want to keep to a controlled location. Backups may contain server addresses, passwords, and tokens.
  3. Remove duplicate entries: Choose Delete from the old profile card's menu. If names look alike, check the source and last-updated time instead of relying on the list order.
  4. Restart to verify: Confirm that the client can still load the profile you kept after restarting, then remove temporary test files.

For long-term upkeep, “one daily, one backup, and a few test profiles” is usually enough. Check expired URLs, auto-updates, and local edits once a month. Recording test results in a profile name or local note makes problems easier to trace than repeatedly importing the same subscription.

FAQ: switching, updates, and missing configs

Why did my custom rules disappear after a subscription update?

First check whether the rules were added directly to the remote config file. A fresh download can replace local edits. Move changes you need to keep into an override or merge feature supported by your client, and check rule order: rules are usually matched from top to bottom, so rules placed after the fallback MATCH may never be reached.

Will importing the same subscription twice give me two separate accounts?

No. The two entries can have different names and local settings, but they access the same subscription source and usually correspond to the same account. Whether the client reuses its local cache or allows duplicate imports depends on the client. Duplicate cards aren't a genuine backup connection.

Will switching profiles also change the port and TUN settings?

Not necessarily. The client may override YAML fields for ports, DNS, or TUN with global settings. For example, if the actual mixed port is managed on the client's “Settings” page, changing mixed-port in the subscription may have no effect. Check the runtime config and logs when troubleshooting; don't infer the current state from the source file alone.

Is copying the YAML file enough when moving to a new computer?

A complete local YAML file is a good starting point for migration, but auto-update URLs, override scripts, external rule files, and client preferences may not come with it. After importing on the new device, recheck file paths, core compatibility, and system proxy permissions. Follow the quick start guide for the full setup process; if loading fails, troubleshoot based on the error in the Help Center.