Getting Started Estimated reading time: 12 minutes

What Is a Clash Profile? How to Switch and Manage Multiple Configurations

Learn how Profiles work in Clash clients, how they relate to subscription URLs and config.yaml, and how to name, switch, update, and clean up multiple configurations without editing the wrong file.

First, separate Profiles, subscription URLs, and config.yaml

The short version: Profile is the logical unit a client uses to manage one proxy configuration. A subscription URL is the remote source for that configuration, while a YAML file is the actual content saved locally after download or import. They are related, but they are not the same thing.

In graphical clients such as Clash Verge Rev and Clash Nyanpasu, Profile may appear as “subscription,” “configuration,” or “config file.” A Profile typically includes a name, source URL, local file path, update time, and enabled status. When you select an entry, the client reads its YAML, validates the syntax, and passes the processed configuration to the Mihomo core.

Object Primary purpose Common form How it is updated
Profile Organize, select, and manage configurations in the client An entry in the configuration list Switch, rename, or fetch again
Subscription URL Provides remote configuration content A URL beginning with HTTPS Requested by the client using the address
YAML file Stores ports, nodes, proxy groups, and rules config.yaml or another filename Remote replacement or local editing
Runtime configuration The configuration actually executed by the Mihomo core The result after client-side merging and overrides Switch the Profile or reload the core

config.yaml is simply a commonly used filename

config.yaml is a common default filename in the Clash ecosystem, but not every Profile has to use it. To avoid duplicate names, graphical clients may save files under random identifiers such as 7f2c8a.yaml, or create a separate directory for each subscription. The list might show “Office line” even though the file on disk has a completely different name.

A runnable base YAML file usually includes listening ports, proxy nodes, proxy groups, and rules. The structure below shows how these parts relate within a Profile without including real node credentials:

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: "Example node"
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: "Node selection"
    type: select
    proxies:
      - "Example node"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Node selection
  - MATCH,DIRECT

Create multiple Profiles: name them before importing

When keeping several configurations, the most practical approach is to replace default names such as “Config 1” or “New subscription” as soon as you import them. At minimum, each name should make three things clear: the use case, the line source, and whether automatic updates are allowed.

Use a “scenario — source — update method” naming scheme

  • Daily — primary subscription — automatic updates: For everyday use, with scheduled client updates enabled.
  • Work — internal rules — manual updates: Includes company-domain routing; review rule changes before updating.
  • Mobile data — low bandwidth: Prioritizes more stable nodes with lower data usage.
  • Testing — local YAML — no overwrite: For debugging rules, DNS, or TUN parameters.
  • Fallback — 2026-08-27: Keeps a verified static copy available.

Using the common Clash Verge Rev 2.x interface as an example, go to “Subscriptions” → “New,” paste the subscription URL, enter a name, and save it. Then click the download or refresh button. To import a local file, choose “Subscriptions” → “New” → “Local file,” and select a file with the .yaml or .yml extension. Button labels vary by version—“Import,” “New profile,” and “Add subscription” are also common—but the basic steps are the same.

  1. Note the name of the Profile currently in use.
  2. Create a remote subscription or import a local YAML file.
  3. Replace the default name with a recognizable scenario name.
  4. Run one manual update and confirm that the update time changes.
  5. Open the configuration details and check that the nodes, proxy groups, and rules are complete.
  6. Only then switch to the new Profile, so a failed import does not interrupt the current connection.

Switching Profiles: verify the active configuration, not just the selected entry

After you click a Profile, the client typically performs four actions: parses the YAML, applies overrides, passes the configuration to Mihomo, and refreshes proxy-group status. A selection marker only shows that the switch was initiated. To confirm that it actually took effect, check the core status, active proxy groups, and connection logs.

Four checks after switching

  1. Check the core status: Open “Settings” → “Core settings” or “System settings” → “Core,” and confirm that Mihomo is running.
  2. Check the port: Make sure the current Profile’s mixed-port matches the system proxy port. 7890 is common, but the active configuration is authoritative.
  3. Check proxy groups: Open the “Proxies” page and confirm that groups such as “Node selection” and “Auto select” come from the new configuration, rather than showing names from the previous Profile.
  4. Check connections: Open “Connections” or “Logs,” visit a test page, and see which rule and proxy group handled the new connection.

If both Profiles use mixed-port: 7890, the system proxy usually needs no change because the listening address and port stay the same. If the new configuration uses mixed-port: 7897, point the system proxy to 127.0.0.1:7897 as well. Changing only the YAML while leaving the old system proxy port in place will make the browser appear unable to connect to the proxy.

TUN mode requires an extra check

TUN mode takes over traffic through a virtual network interface, covering more traffic than a standard system proxy. After switching Profiles, changes to tun, DNS, route exclusions, or the network stack may require restarting TUN. A common path is “Settings” → “System settings” → “TUN mode”: turn it off, wait 2 to 3 seconds, then turn it back on.

After enabling TUN, check the logs for interface creation, route updates, and DNS listener messages. If the configuration uses dns.listen: 0.0.0.0:1053, also confirm that port 1053 is not occupied by another running proxy. Running TUN in multiple clients at once can repeatedly rewrite the default route, so keep only one core running while testing switches.

Updating Profiles: distinguish remote refreshes, overrides, and runtime reloads

“Update subscription” usually only downloads the remote YAML again. “Reload configuration” makes the core read the local content again. Some clients perform both actions in sequence; others require you to switch the Profile manually. If the node count does not change after an update, that does not necessarily mean it failed—the server may have changed only node parameters or rule content.

Use the update time and logs to verify a refresh

Before updating, note the time shown for the Profile, such as 2026-08-27 09:30. After the refresh, confirm that the time changed and check the HTTP status in the logs. A successful request commonly returns 200; 401 or 403 usually indicates subscription permissions or an expired token; 404 means the remote path does not exist; a connection timeout calls for a check of the current network and direct-connection rules.

Symptom Check first What to do
Update time changes, but node names remain old Was the active configuration reloaded? Select the Profile again and restart the core if necessary
Custom rules disappeared after an update Did you edit the subscription cache directly? Restore the fallback copy and use an override instead
YAML parsing error appears during update Indentation near the reported line Restore the original file and use spaces consistently
New nodes exist but do not appear in proxy groups Proxy-group proxies or provider references Check that the nodes were added to the relevant group

YAML is sensitive to indentation. List items typically use two spaces and should not contain tabs. After editing, first review the client’s syntax-check result before loading the file into the core. If the error points to line 86, the missing colon or incorrect indentation may actually be on line 85, so check the preceding line as well.

Editing a local configuration: confirm the file mapping first

The most common mistake in a multi-Profile setup is editing a file named config.yaml and seeing no change in the client. The client may actually be running another cached file, or the runtime configuration may also include overrides. Before editing, open the file from the Profile’s details menu instead of guessing from filenames on disk.

A safer editing sequence

  1. Confirm the enabled entry in the configuration list.
  2. Use that entry’s “Open file,” “Edit configuration,” or “Open folder” action.
  3. Copy the original file and add the date and purpose to the copy’s name.
  4. Change one section at a time—for example, edit mixed-port first, verify it, then change DNS.
  5. Run a syntax check and reload the configuration after saving.
  6. Use the logs to confirm that the core read the expected file.

For Mihomo, common core fields include mixed-port, allow-lan, mode, dns, tun, proxies, proxy-groups, and rules. Before changing a field, check whether the client exposes a separate toggle for it. For example, the TUN switch in the interface may control a runtime override; even if the YAML contains enable: false, the client may merge its own setting before starting the core.

When you need to inspect the final configuration, use the client’s “Runtime configuration,” “Current configuration,” or debug export feature. It shows the result after merging the remote subscription, local overrides, and client settings, making it closer to what Mihomo actually receives than the subscription cache alone.

Cleaning up old Profiles: disable first, then delete

As the configuration list grows, duplicate names and expired subscriptions make accidental switches more likely. Do not start cleanup with the currently enabled entry. First switch to a verified primary Profile, open a webpage, and check the logs before handling old entries.

Save essential information before deleting

  • Record the Profile’s display name, source type, and last update time.
  • Export local custom configurations as YAML before deleting the list entry.
  • Confirm that the old Profile contains no unique rules, proxy groups, or DNS settings.
  • Keep only remote subscription entries still in use, and avoid multiple names pointing to the same URL.
  • After deletion, inspect the cache directory and distinguish client-managed files from manual backups.

Organize configurations into “active,” “testing,” and “fallback” groups. Keep one or two active copies, merge or delete test configurations after verification, and retain only the latest stable fallback. Dated copies that are several months old may contain obsolete rules and node information, so they should not remain preferred configurations indefinitely.

Common questions about managing multiple configurations

Why did the selected node change after switching Profiles?

Node selections are usually saved by proxy-group name and node name. If the new Profile lacks a node with the same name, the client uses the group’s default entry or falls back to the first available item in the list. After switching, check key groups such as “Node selection” and “Auto select” again.

Can multiple Profiles run at the same time?

Most desktop clients pass only one primary Profile to a single Mihomo core at a time. If you start multiple cores manually, assign different mixed ports, control ports, and DNS listener ports, and avoid having them take over the system proxy or default route simultaneously. For typical use, switching within one client is the better approach.

Will a subscription update overwrite manually selected proxy-group options?

Remote YAML updates the proxy-group definitions, but the client may save the previous selection separately. If the original node still exists, it can usually continue to be used. If the node was renamed or removed, the group falls back to an available default. After updating, check latency and the currently selected item.

Why did changes to config.yaml have no effect?

First confirm that you edited the file associated with the active Profile, then reload it. Also check whether the client’s Merge, Mixin, or override settings replace the same fields. After changing a port, update the system proxy settings as well.

How often should a Profile be updated?

For a daily subscription, refreshing every 6 to 24 hours is usually reasonable. Local configurations with infrequent rule changes can be updated manually. Refreshing too often creates unnecessary repeat requests and does not make node health checks more timely; proxy-group health checks should handle latency monitoring separately.

A repeatable Profile management workflow

Reliable management of multiple Clash configurations depends on keeping the source, file, and runtime state aligned. Name entries clearly during import, check ports and proxy groups after switching, save a fallback before updating, and preserve local edits through overrides or a separate Profile. Even as the list grows, this makes it quick to identify exactly which configuration the core has loaded.

  • Include the scenario, source, and update method in each name.
  • Store remote subscriptions separately from local test configurations.
  • After switching, check the core, port, proxy groups, and connection logs.
  • Do not use an automatically updated subscription cache for long-term custom edits.
  • Keep a dated, working copy before making major changes.
  • During cleanup, switch to the primary configuration before deleting old entries.
Get the client See all platform options