Clash Profiles Explained: Manage and Switch Between Multiple Configs

How Profiles Relate to config.yaml

In Clash GUI clients, a Profile usually means a selectable configuration. It may come from a local YAML file or be linked to a remote subscription URL. Along with the config itself, the client may store a name, source, last-updated time, and override settings. This management data belongs to the client and may not be included in the YAML read by the core.

config.yaml is a common filename for a core configuration file. mihomo, the core developed from the Clash Meta project, can read configs containing listening ports, proxies, proxy groups, DNS settings, and routing rules. The filename doesn't have to be config.yaml: the command line can use -f to specify another file, and GUI clients may generate their own runtime files.

• Profile list: Stores multiple configs so you can choose the one you need.
• Active Profile: The client uses this profile to generate or load the current config.
• Runtime config: The config actually used by the core, which may include global settings, overrides, or script-generated changes.

When troubleshooting, distinguish between the original subscription, the config after client-side edits, and the config currently loaded by the core. Opening a config.yaml on disk may not show all the rules currently applied to connections.

Choosing Between a Local Config and a Remote Subscription

A local config can also include proxy-providers or rule-providers to fetch proxies and rules remotely. “Local” describes how the Profile was added; it doesn't mean every resource is stored offline. If a backup omits provider caches and dependent files, the config may still be unusable without an internet connection.

A Subscription URL Isn't a Config Format

The same import field may accept a URL, but the content returned by that URL can vary. A complete Clash YAML config can include proxies, proxy-groups, and rules. A Base64-encoded proxy list usually contains only proxy details, so it can't be used as a complete rules config. Other YAML files are proxies lists intended for providers, not full Profiles.

If an import fails, check the client's error details first and make sure the response is a config—not a login page, expiry notice, or HTML error page. If the server offers format options, choose a Clash or mihomo config compatible with your core. Subscription URLs often contain access tokens; don't share them on public conversion sites, in screenshots, or in support requests.

Naming and Grouping Multiple Profiles

Name profiles by purpose first, source second, and whether they're experimental last. Names like “Config 1,” “New Subscription,” or a string of “Final” versions make it hard to tell which profile is safe to update. Here are some practical examples:

• Daily-primary-subscription: Keeps server updates enabled for everyday browsing.
• Backup-independent-subscription: Uses a separate source so you can switch manually if the primary fails.
• Office-local-rules: Clearly identifies rules for office domains and private network addresses.
• Test-DNS-2026-08-18: Tests DNS changes without replacing your everyday config.

Dates are useful for snapshots and test copies; keep long-running subscription names stable. For each profile, note its source type, compatible core, and required overrides—for example, “remote YAML; mihomo; office-domain rules applied.” This is more useful when migrating than a provider abbreviation alone.

Test Backup Profiles in Advance

Two Profiles with different names may point to the same subscription URL. That kind of copy is useful for testing changes, but it isn't an independent backup connection. Check in advance that the backup can update, its proxy groups have selectable proxies, and the sites you need are reachable—then switch back to your everyday profile. Waiting until the primary connection fails can leave you troubleshooting both subscription downloads and proxy connections at once.

How to Switch Profiles and Verify the Change

Clients may call the relevant section “Config,” “Subscriptions,” or “Profiles,” and button labels can change between versions. Find the target entry in the profile list and distinguish between “Edit,” “Update,” and “Activate”: editing changes the config, updating fetches new source content, and activating switches the current config. Some clients reload automatically after an update; others require confirmation.

1. Note the current state. Record the active Profile, rule mode, proxy group selections, and system proxy setting. If needed, take a screenshot that doesn't show the subscription URL.
2. Update the target profile. Refresh a remote Profile and check its update time and any error message. For a local config, check the paths to its dependencies.
3. Activate the target config. Wait for it to load, then check the logs for YAML parsing errors, missing policies, or failed resource downloads.
4. Choose proxies again. The new config may use different group names, so don't assume it will retain the previously selected proxy.
5. Start a new connection. Reopen a test website and check the rule, policy chain, and destination address in the connection details.

For example, the old config might use mixed-port: 7890 and the new one mixed-port: 7897. If your terminal still points to 127.0.0.1:7890, the connection may fail. A GUI client may also override the port in the Profile with a global setting, so check the port that's actually listening rather than comparing config files alone.

On Linux, use the command below to check whether the example port is listening. If you're using a different port, replace it with the actual value:

ss -lntp 'sport = :7890'
ss -lntp 'sport = :7897'

Existing downloads, video streams, or persistent connections may continue using the old connection after a switch. For a reliable check, start a new connection. If needed, close the relevant connections on the client's connection page and try again so an old connection isn't mistaken for a config that failed to take effect.

Where to Put Custom Rules for Easier Maintenance

Keep remote subscriptions as updateable sources whenever possible, and put long-term changes in the client's supported override, merge, or script mechanism. Clients handle field merging differently: some replace an entire list, while others let you prepend or append rules. Before saving, inspect the generated config to confirm your changes are included in the runtime result.

Check Rule Order and Proxy Group Names

The example below illustrates rule order; it isn't a complete config. It sends an internal example domain and private network ranges directly, then lets later rules handle other traffic:

rules:
  - DOMAIN-SUFFIX,office.example,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,DIRECT

office.example is a reserved example domain, not a real office domain. The final MATCH,DIRECT is included only to complete the example structure; copying it would send all remaining traffic directly. Keep the additional rules you need in your actual config and use a fallback policy you've already defined.

Rules are evaluated from top to bottom. A custom domain rule appended after MATCH won't run. If a rule points to a proxy group named Office-Exit, the new config must also define that group or it may fail to load. Referencing only DIRECT avoids depending on a group name, but whether direct access is appropriate depends on your needs.

Change One Type of Setting at a Time

Test rules first, then adjust DNS, and check TUN mode last. Don't replace a subscription, change DNS and ports, and enable TUN all at once; if something breaks, it'll be hard to identify the cause. Global overrides may also affect every Profile. If a DNS change should apply only to a test profile, check the override's scope first.

Back Up, Test, and Roll Back Configs

A complete backup should include at least the original config, client management data, and custom overrides. Copying only a runtime config.yaml may omit the subscription URL, automatic update schedule, scripts, and proxy group selections. Exporting only the client profile list may also leave out the actual provider content.

1. Use the client's export or backup feature to create a copy, and record the client and core versions.
2. Archive manually maintained rules, override scripts, provider files, and any required certificate dependencies together.
3. Date snapshots taken before and after a change—for example, daily-2026-08-18.yaml—so you don't overwrite your only usable copy.
4. Store backups containing proxy passwords, subscription tokens, or controller API keys in a restricted directory. Redact sensitive data before sharing.

Test a Candidate Config with mihomo

Command-line users can check the core version, then test a candidate file in a separate directory. The example assumes candidate.yaml is in the current directory and mihomo is available on your PATH:

mihomo -v
mkdir -p ./profile-check
mihomo -t -d ./profile-check -f ./candidate.yaml

-t tests the config, -d sets the working directory, and -f specifies the config file. Set up relative paths and external resources in the appropriate directories; resources such as rule sets may also need to be downloaded. Passing the test means the core accepts the config—it doesn't confirm that proxies work, DNS is correct, or the system proxy is active.

To roll back, restore the last working Profile and its matching overrides, reload, then test with a new connection. On the command line, replacing a file on disk isn't enough: reload the config through your usual management method or restart the relevant service so the core reads it.

Frequently Asked Questions About Profile Management

A simple maintenance routine works well: keep the original source, use overrides for long-term rules, verify new connections after switching, and save a rollback snapshot before important changes. You don't need a large number of configs; clear sources, well-defined scope, and repeatable recovery steps matter more.