What Is a Clash Profile? Manage and Switch Between Subscriptions and Local Configs

A Profile Is a Config Entry, Not an Individual Node

In a Clash client, a Profile usually means one entry in the configuration list. It can come from a subscription link or a YAML file imported from your device. Having three Profiles in the list does not mean the core is running three configs at once. Most desktop clients activate one main config at a time, optionally applying client-supported overrides, merges, or runtime settings.

First, distinguish between a config, a subscription, and a node. A subscription is a source of configuration data; YAML is a common file format for that data; a Profile is the client’s way to manage it; and a node is a proxy outbound in the config. Switching nodes usually changes the selection in a policy group. Switching Profiles can change the rules, DNS, listening ports, and policy groups as well.

Naming Multiple Configs: Track Source, Purpose, and Date Separately

Keep two types of entries: remote configs that update from the provider, and local configs for testing and rollback. Avoid generic names like “Subscription 1” and “Subscription 2,” and never put a full subscription URL in the display name. Its token may grant access to your account and could be exposed in a screenshot.

Example Names for Three Configs

• Daily-A-Remote: For everyday use. Retains the original subscription source and updates automatically according to the client’s settings.
• Backup-B-Remote: For backup routes. Store its source and expiration details separately from the daily config.
• Test-Rules-Local-20261016: A local copy of a working config, used only to test rule changes.

The display name is not a standard top-level YAML field. Don’t add profile-name to a config just to rename a Profile. Use the client’s rename or edit option for the config entry. If the editor has no name field, give the file a descriptive name before importing it.

Import and Activate in Two Steps

1. Open the config management page. Depending on the client, it may be called “Config,” “Subscriptions,” or “Profiles”; use the label shown in your app.
2. Import a subscription URL or local file, then check the new entry’s name, source type, and last update time.
3. Select the new entry and wait for the client to confirm it loaded. Then check which config is marked as active.
4. Open the proxy groups page and confirm that the group names and node list have changed. An entry appearing in the config list does not mean it is active.

Importing a local file usually copies it to the client’s data directory, though some products manage files differently. Editing the original file on your desktop may not update the client’s copy. Reimport it, or use the client’s “Edit file” or “Open config file” option to modify the file it actually manages.

Switching Profiles: Check Mode, Ports, and Policy Groups

A reliable switch means checking both that the config loaded and that traffic follows the expected route. A config containing mode: rule does not guarantee the client is in rule mode; some clients override the file value with runtime settings. Check the client’s current status, core logs, and connection details together.

Four Checks to Make Before and After Switching

1. Back up the working config: Note the current Profile name and key policy group selections. Export a copy if needed.
2. Confirm the load result: Check the logs for YAML parsing errors, unknown fields, or references to missing policy groups.
3. Check traffic entry settings: Review the system proxy, TUN, and listening ports—not just the node list.
4. Test with a new connection: Reopen a test page and check the matched rule, policy group, and actual outbound in the connection details.

For example, the old config may use mixed port 7890, while the new one uses 7891. A terminal still using the old proxy environment variables may then fail to connect. These ports illustrate two separate configs; they are not meant to be added to the same file:

# Listener settings in the daily config
mixed-port: 7890
mode: rule

# After switching to another config, the listener may use port 7891
# mixed-port: 7891

If the client controls the port, it may override the values in the file. When troubleshooting, first check the port shown in the client, then check for manually configured proxy addresses in your browser, terminal, or development tools. Also verify TUN status, virtual adapter creation, and route installation separately; a Profile name tells you none of these.

Subscription Updates Overwrite Changes: Separate the Source from Personal Settings

Changes made directly to a remote Profile’s downloaded content usually last only until the next update. The update fetches the provider’s config again and may replace the local cache. Common signs include a custom direct-connection rule disappearing, DNS settings reverting, or policy group names returning to their original values.

Choose Where to Save Changes Based on What You’re Editing

To send intranet.example.com directly, you could use a rule like this. The domain is an example; replace it with the internal domain you need. This snippet is not a complete config that you can import on its own.

rules:
  - DOMAIN-SUFFIX,intranet.example.com,DIRECT
  - MATCH,Proxy

Proxy must match a node or policy group defined in the final config. If you switch to a Profile that only has an Auto group, the original reference may no longer work. When sharing an override across Profiles, use consistent policy group names or bind a separate override to each config; copying the rule text alone is not enough.

“Merge” does not always mean automatic append. Some tools replace the entire rules list; others support prepending, appending, or script-based processing. Place rules before fallback entries such as MATCH; rules after them usually won’t match. Once configured, check the generated runtime config to make sure the original rules are still present and in the expected order.

Using Two Subscriptions: Switching Is Not Aggregation

Importing subscriptions A and B into the config list usually creates two Profiles you can switch between. It does not automatically combine their nodes into one policy group. If you just need a backup, keeping them as separate entries makes troubleshooting easier. Consider node providers or an aggregation feature explicitly supported by your client only if you need to select nodes from both subscriptions at once.

What the Main Config and Node Providers Do

• The main config controls overall behavior, including proxy-groups, rules, and DNS.
• proxy-providers fetches a compatible set of nodes, which policy groups reference by provider name using use.
• Don’t assume a full-config subscription can be used as a node provider. Compatibility depends on the core and the content returned by the source.

In mihomo, for example, interval: 3600 under an HTTP node provider means that provider is updated every 3,600 seconds. It does not mean the client updates the entire Profile every hour. health-check.interval within a provider sets the health-check interval, not the subscription update frequency. Remote Profile auto-updates are often configured separately in the client, and the interval may be shown in minutes or hours.

Track these as separate events: when the whole config updates, when the node set updates, and when nodes are checked for availability. If nodes have changed but rules have not, you can first determine whether only the provider updated instead of repeatedly deleting and reimporting every config.

Back Up and Migrate Configs: Save the Source, Overrides, and State Separately

Exporting a single runtime YAML may not be enough to restore your everyday setup. The runtime file may include merged overrides but not the remote subscription URL; it may also contain node passwords, subscription tokens, and local listener settings. It can help reconstruct the config as it was, but it is not a substitute for backing up the client’s data.

What to Include in a Backup

1. Config sources: Save notes about each subscription source, Profile names, and any subscription URLs you need. Store sensitive links somewhere protected.
2. Local YAML: Save manually written configs and a working copy from before testing, such as daily-local-20261016.yaml.
3. Personal overrides: Save rules and scripts separately, along with the Profiles they’re bound to and their processing order.
4. Runtime settings: Record ports, system proxy, TUN, DNS-related settings, and the actual client and core versions.
5. Selection state: Record selections for frequently used policy groups. Clients may store this state in different places and ways.

For migrations, use the client’s export and restore features when available. If you need to copy the data directory, quit the client first and copy it to a protected local location. This avoids copying a database or state file while it’s being written. Don’t assume a fixed directory path: installation method, portable mode, and operating system all affect the actual location.

Verify the Setup After Restoring

Import the config first, restore overrides next, then enable the system proxy or TUN one at a time. For the first test, enable only the traffic entry you need to make problems easier to isolate. Once the config loads, DNS resolves, and connections succeed, restore auto-updates and launch-at-startup settings.

Basic YAML fields may be reusable across clients, but config indexes, override scripts, and interface state may not be compatible. When switching cores, check for core-specific fields as well. If loading fails, use the logs to identify the specific field; don’t overwrite the new client’s data directory with the old client’s entire directory.

FAQ: Why Isn’t the Config Running as Expected?

After switching, the nodes changed but the rules didn’t. Why?

First check whether both configs use the same rules, then check for a global client override. If a shared override replaces rules, the rules may stay the same after switching the source Profile. Judge by the final runtime config and the rules matched by new connections, not by the source file preview.

Does deleting a Profile also delete my subscription account?

Deleting a local entry usually affects only the config stored in the client; it does not cancel your account with the provider. Whether the client also removes cached data, linked overrides, or local copies depends on the deletion prompt. Export anything you need beforehand. If your subscription URL has been exposed, reset it with the provider rather than simply deleting the local Profile.

Can a local config never change automatically?

A local file usually doesn’t update like a remote Profile, but it may still reference auto-updating proxy-providers or rule-providers, or have client runtime settings applied to it. To reproduce an issue, record these external sources and when they update; saving only the top-level YAML is not enough.

What’s the Minimum for Day-to-Day Config Management?

Keep a working config for rollback; name remote subscriptions and local tests separately; put lasting changes in an override layer that persists; and check the rules and outbound with a new connection after each switch. For first-time imports, see the subscription import guide. For field relationships, see the YAML structure reference.