Clash Profiles: Importing, Switching, and Managing Multiple Configurations

PROFILE / 01

What a Profile actually contains

In a Clash GUI client, a Profile usually means a configuration the core can load. It may come from a remote subscription URL or from a YAML file imported manually. The client downloads, stores, switches, and updates Profiles; the Clash or mihomo core uses the active config to open listening ports, load proxies, build proxy groups, and process connections according to its rules.

Clash clients do not all use the same labels for Profiles. Common labels include “Config,” “Configuration,” “Subscription,” and “Profiles.” The names differ, but the basic relationship is the same: a config list can store multiple files, while usually only one main config is active in the core at a time. Switching entries does more than change a proxy; it may also replace ports, DNS settings, proxy groups, rules, and TUN parameters.

A simplified config can show how these parts relate. Real subscriptions usually contain many more nodes and rules, and supported fields also depend on the core version in use.

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

proxies:
  - name: example-node
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: Node Selection
    type: select
    proxies:
      - example-node
      - DIRECT

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

SOURCE / 02

Remote subscriptions vs. local configs

A remote subscription Profile is provided through a subscription URL. After saving the URL, the client can download the config on demand or on a schedule. The updated content usually replaces the old cached version, so changes to nodes, proxy groups, and rules take effect the next time the config loads. Subscription URLs often contain access credentials and should be treated like passwords—never include them in public screenshots, logs, or issue reports.

A local Profile comes from a YAML file stored on the device. It is useful for hand-written rules, fixed ports, experimental DNS settings, or a minimal troubleshooting config. Because a local file has no remote source, the client usually will not update it automatically; later changes require editing the file or importing a revised copy again.

One easily confused case is when a client lets you copy a remote config into a local file. That copy inherits the subscription content at the time it is created, but usually stops receiving automatic updates afterward. To identify the source, check whether the entry shows a subscription URL, last update time, update interval, or refresh button. If it shows only a file path and modification time, it is more likely a local file.

If you need subscription updates while keeping custom rules long term, use the client’s built-in override, merge, or extension feature whenever possible. Depending on the client, it may be called Override, Mixin, Merge, or an override config. These features append to or modify selected fields after a subscription download, reducing the risk of changes being lost by editing a cached file directly. Merge syntax varies between clients, so read the target client’s field documentation before migrating.

IMPORT / 03

Importing a config and checking it for the first time

When importing a remote subscription, use “Import from URL” or a similar entry on the client’s Profile page. Do not paste the subscription URL into a proxy name, rule editor, or browser proxy settings. A successful import only means that the client received a response; you must also confirm that the current core can parse it. If the server returns a login page, explanatory text, or incomplete YAML, the client may create an entry even though the core later fails to load it.

Before importing a local file, check its extension and text encoding. YAML typically uses .yaml or .yml; UTF-8 is recommended. YAML uses indentation to express hierarchy, so use spaces and avoid mixing tabs at the same level. Proxy names referenced by a proxy group must match the defined names, and policy names targeted by rules must actually exist.

1. Keep the currently working config. Before importing a new Profile for the first time, do not delete the old one immediately. Keeping it lets you switch back quickly if loading fails.
2. Finish the import and check the update time. A remote entry should show its latest fetch time, while a local entry should identify the file name.
3. Activate the config and watch the core status. Make sure the client does not continue reporting parse failures, startup failures, or port conflicts.
4. Check the proxy groups. Confirm that each group contains selectable nodes and that the URL-test group can complete latency checks.
5. Check the traffic interception method. In system proxy mode, verify the listening port; in TUN mode, confirm the virtual interface status and permissions.
6. Test direct and proxied destinations separately. Opening one webpage is not enough to prove that the rules, DNS, and all policies are working correctly.

For mihomo configs, also watch for fields supported only by specific cores. A Profile that works in a mihomo client may not load directly in an older original Clash core. If you see an “unknown field” error or a parse failure after migration, compare the core type and version instead of repeatedly changing the subscription URL.

SWITCH / 04

Switching between multiple Profiles correctly

Before switching configs, note the current mode and the proxy groups in use. Some clients save group selections per Profile; others try to restore selections with matching names in the new config. If both configs contain “Node Selection” but their node lists are completely different, the client may fall back to the first available option. Recheck important policies after switching rather than assuming the previous selections still apply.

The port is another field that needs verification. If config A uses mixed-port: 7890 and config B uses mixed-port: 7893, while the system proxy still points to 7890, browsers may stop connecting after switching to config B even though the core itself appears healthy. Some desktop clients synchronize the system proxy port automatically; others only load the config. After every switch, check the actual listening address shown by the client.

TUN mode has broader effects. Different Profiles may use different DNS modes, route exclusions, auto-route settings, and interface detection parameters. The virtual interface may briefly be rebuilt during a switch, and existing connections may continue using the old path until they close. When validating a new config, reopen the test application and, if necessary, close old connections before checking rule matches.

A reliable order for everyday switching

1. Confirm that the target Profile updated successfully and check for loading errors.
2. Record the current proxy group selections, especially manual groups and the egress used in global mode.
3. Switch to the target Profile and wait for the core to finish reloading.
4. Check whether the mode is Rule, Global, or Direct, since another config may have changed it.
5. Confirm the system proxy or TUN status and verify the actual listening port.
6. Open the connection log and test one direct rule and one proxied rule.

If you only want to change the egress after switching, without replacing the rules or DNS settings, selecting a node in the existing Profile’s proxy group is a better option. Avoiding unnecessary config switches also reduces the troubleshooting cost of changing ports, rules, and TUN parameters at the same time.

CATALOG / 05

Organizing and naming multiple configs

As the number of configs grows, the problem is often identification rather than import. When several entries are all named config.yaml, it is hard to tell their source, purpose, or update method. Include at least the source type and use case in each name, such as “Subscription-A-Daily,” “Local-Rule-Test,” or “Backup-Before-Migration.” Do not put subscription credentials, full URLs, or proxy server addresses in names.

Dates work well for one-time snapshots, such as “Backup-2026-05-18.” Continuously updated subscriptions should not be renamed after every refresh, or you will accumulate many indistinguishable duplicates. For long-term configs, keep the core requirements, port, DNS mode, and customizations in a separate record instead of relying on memory.

Information worth keeping

• Source: A remote subscription, local file, or local copy made from a subscription.
• Purpose: Daily use, rule debugging, TUN testing, or migration backup.
• Core requirements: Whether it works with original Clash or depends on mihomo extension fields.
• Traffic interception: System proxy, TUN, or a proxy port provided only to devices on the local network.
• Changes: Whether DNS, ports, rules, or proxy groups have been modified.
• Last updated: The subscription’s last refresh time or the local file’s last revision date.

Before deleting a config, determine whether it is currently in use. Some clients prevent deletion of the active Profile, while others automatically switch to another entry. The safer approach is to activate a verified working config first, then remove duplicates. If a local file contains important hand-written rules, export it to a clearly named backup directory beforehand.

REVISION / 06

Updates, edits, and overwrite behavior

The defining trait of a remote Profile is that its local cache is managed by remote content. Editing nodes, rules, or DNS fields directly in the client cache may work temporarily, but the next subscription refresh will usually replace the file. If custom rules keep disappearing after updates, first check where you edited them instead of assuming the core update failed.

There are three practical approaches to long-term changes. First, use the client’s override or merge feature and save only the fields you need to change. Second, copy the subscription into a local config and maintain it yourself. Third, use proxy-providers and rule-providers to separate proxy collections and rule collections from the main config. The third approach suits users familiar with YAML and mihomo’s config structure, and requires confirming that the remote resource format meets the relevant provider requirements.

proxy-providers:
  remote-set:
    type: http
    url: "https://example.invalid/provider.yaml"
    path: ./providers/remote-set.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: "https://www.example.com/generate_204"

proxy-providers is not the same as a client Profile. A Profile is the main config given to the core; a provider is an external resource referenced by that config. One Profile can reference multiple providers, or none at all. Keeping the two separate makes it clear whether you need to refresh the client subscription, update a provider, or reload the main config.

When editing YAML, also watch for list replacement. Some merge tools replace the entire existing rules list with the new one, while others support inserting items before or after it. Rules are matched from top to bottom. If a custom rule is appended after MATCH, it will never match even though the file loads normally. After merging, inspect the final generated config rather than checking only the override fragment.

PROOF / 07

Troubleshooting common multi-Profile issues

No application can connect after switching

First confirm that the core is running, then check whether the system proxy port matches the listening port in the active Profile. If you use TUN, verify that the virtual interface was created successfully and that the client has the required permissions. You can also temporarily disable traffic interception to confirm that the underlying network works. Do not delete the config first; a port mismatch or failed TUN rebuild is more common.

The config updated successfully, but the nodes did not change

Check that the active entry is actually the one you just updated. Duplicate Profiles with similar names are easy to confuse. Then review the update time, proxy group contents, and core logs. If the main config references a provider, verify the refresh status of both the Profile and the provider; updating only one layer may not immediately change the node list.

Local rules disappear after being saved

This usually means you edited the subscription cache and a later update overwrote the change. Move the rules into the client’s supported override mechanism or create a separate local Profile. During migration, copy the names of the proxy groups referenced by the rules as well, so the rules do not point to missing targets.

A config works in an older client but fails in a newer one

Compare the cores actually in use, not just the client names. mihomo extension fields evolve across versions, and the supported field sets differ between original Clash and its various forks. Use the error message to identify the field, then determine whether the problem is indentation, field type, or lack of core support. Keep booleans, numbers, and strings in their correct types; do not add quotes everywhere just to bypass an error.

Proxy group selections reset after switching

First check whether the old and new configs contain exactly matching proxy group names and whether the new group includes the previously selected node. If the target is missing, the client can only fall back to an available option. A URL-test group may also select a different node based on latency; that is normal group behavior and does not necessarily mean the Profile switch failed.

Only some domains are unreachable

Open the connection log and inspect the matched rule and policy. If domain resolution fails, check the DNS config, fake-IP filter settings, and upstream reachability. If the wrong policy matched, inspect rule order. In a multi-config setup, also confirm that the rule editor belongs to the active Profile, rather than repeatedly editing an inactive entry.

A useful troubleshooting report should include the active Profile name, source type, core name and version, running mode, listening port, traffic interception method, and one specific error. Hide subscription URLs and proxy credentials before sharing. This information quickly classifies the issue as config parsing, core startup, port interception, DNS resolution, or rule matching, reducing aimless re-imports.

FINAL CHECK / 08

Multi-config management checklist

• Config names clearly identify their source and purpose instead of relying on default file names.
• Manage remote subscriptions and local files separately, with a clear record of what updates may overwrite.
• After switching, check the running mode, proxy groups, listening port, and system proxy or TUN status.
• Keep important custom rules in an override or local file, with a recoverable backup.
• Before upgrading the client or core, check whether the Profile uses extension fields from a specific branch.
• During troubleshooting, confirm the active entry first so you do not edit a config that is not running.
• Before deleting a duplicate config, switch to a verified working Profile.

The goal of Profile management is not to save as many configs as possible, but to make each config’s source, purpose, and update boundaries clear. Keep the daily config stable, put tests in separate entries, avoid editing remote subscription caches directly, and check ports, mode, policies, and DNS in that order after switching. This greatly reduces the effort needed to locate problems when multiple configs coexist.