Clash Profile Guide: Importing, Switching, and Managing Multiple Configurations

A Profile is a switchable runtime configuration

In a Clash client, a Profile usually means a configuration file that can be read by the core. It is typically written in YAML and may include listening ports, proxy nodes, proxy groups, routing rules, DNS settings, proxy providers, and rule providers. After you select a Profile, the client parses the file and passes the active configuration to the Clash or mihomo core.

A Profile is not synonymous with a single node. A node is just a connection entry in the configuration; a proxy group organizes multiple nodes or other policies; and rules route requests to the appropriate proxy group based on conditions such as domain, IP address, or process. Switching nodes usually changes only the currently selected member of a proxy group, while switching Profiles can change the node list, rule order, DNS mode, ports, and TUN settings at the same time, with a much broader impact.

Different clients may use slightly different terms for Profiles, such as “configuration,” “subscription,” “config file,” or “Profiles.” Although the interface labels vary, the basic relationship remains the same: the client stores configuration sources, the core reads the active configuration, and the user adjusts the actual route through proxy groups.

The configuration source determines how it updates

Profile sources generally fall into three categories: importing from a subscription URL, importing a local YAML file, or creating and duplicating configurations in the client for manual maintenance. Each source has different update behavior. Before building a multi-Profile setup, confirm whether each configuration is maintained remotely or locally.

Importing from a subscription URL

A subscription URL returns configuration content from a remote source. The client usually saves the URL and lets you refresh it manually or on a schedule. During a refresh, it requests the remote content again and replaces the corresponding cached version. Whether local edits are preserved depends on the client, so avoid maintaining long-term rule changes directly in a remote Profile that may be overwritten.

A subscription URL may contain account-identifying information and should be treated like a sensitive credential. Do not include it in public screenshots, public code repositories, shared documents, or issue logs. When importing it on another device, use a trusted channel, and remove the related configuration from devices that no longer need it.

Importing a local YAML file

Local files are useful for testing, custom rules, and offline backups. Some clients copy the file contents into their own configuration directory, so later edits to the original file will not sync automatically; others may reference the specified path directly. After importing, change an easy-to-recognize description field or rule, then reload the configuration to confirm whether the client reads a copy or the original path.

Creating or duplicating a configuration manually

Duplicating an existing Profile before making changes is useful for preserving a stable version while testing new rules. For example, duplicate “Daily Stable” as “DNS Test” and change only the DNS settings and related rules. After testing, decide whether to merge the changes into the long-term configuration. This avoids repeatedly editing the only working configuration.

Confirm each layer after switching Profiles

Selecting a Profile in the interface only tells the client to prepare that configuration for use. Actual activation also depends on configuration parsing, core runtime status, and the system traffic entry point. A reliable sequence is: save the current work, select the target Profile, wait for parsing to finish, confirm proxy group status, then check the system proxy or TUN.

1. Select the target configuration: Click the entry you want in the Profile list and confirm that the active marker has moved to it.
2. Check the load result: Look for YAML syntax errors, unsupported fields, port conflicts, or failed proxy provider downloads.
3. Check proxy groups: Confirm that the key proxy groups exist and that the current node is still available. Proxy groups with the same name can contain completely different nodes in different configurations.
4. Confirm the operating mode: Check whether the client is in Rule, Global, or Direct mode. Rule is generally suitable for everyday split routing; Global sends most requests through the global policy; Direct connects without using a proxy.
5. Confirm the traffic entry point: Programs such as browsers that follow the system proxy require the system proxy to be configured correctly. Programs that ignore it usually need TUN or their own proxy settings.
6. Run access checks: Test a direct destination, a proxied destination, and DNS resolution separately. Do not judge whether the configuration is fully active solely by node latency.

When switching to a Profile with different listening ports, the port saved in the system proxy must match as well. For example, the old configuration may use mixed-port: 7890 while the new one uses mixed-port: 7897. If the system still points to the old port, applications may appear unable to connect. Some clients synchronize the system proxy port automatically, but it is still worth checking after a switch.

mixed-port: 7890
mode: rule
allow-lan: false

dns:
  enable: true
  ipv6: false
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

This example shows configuration hierarchy only; it is not a complete Profile. A working configuration must also match the core version, node protocols, rule structure, and local network conditions. YAML uses spaces to express hierarchy, and tab characters, inconsistent indentation, or duplicate fields can all cause loading failures.

Name multiple configurations by purpose, source, and status

As the number of configurations grows, the most common problem is not a missing file but uncertainty about which one is active and which one can be updated. Names such as “Config 1,” “New Config,” or “Final Version” make quick rollback difficult during an outage. Include the purpose and source in each name, and add a status or date when useful.

Daily use rarely requires many duplicate copies. One primary remote configuration, one verified local stable backup, and a small number of scenario-specific test configurations cover most switching and rollback needs. Too many copies create confusion around proxy group choices, update times, and subscription sources.

Separate system proxy and TUN configurations

The system proxy mainly affects applications that follow the operating system’s proxy settings and is relatively straightforward. TUN mode creates a virtual network interface and handles a broader range of traffic, while also involving routing, DNS hijacking, interface detection, and permissions. If you switch between the two modes often, maintain separate Profiles to avoid manually changing multiple parameters each time.

When using the mihomo core, a TUN configuration may include fields such as stack, auto-route, auto-detect-interface, and DNS hijacking settings. Field support depends on the core version, operating system, and client permissions. Copying a TUN section designed for one platform directly to another can cause incorrect interface selection, local network access problems, or changes in the DNS path.

Keep one verified rollback point

A stable backup should come from a configuration that has actually run successfully, not a newly downloaded file that has never been used. When creating a backup, record the export date, core type, and intended use. If a subscription becomes invalid, a rule provider is unreachable, or fields are incompatible with a new version, switch back to the stable configuration first, restore connectivity, and then inspect the update separately.

Handle subscription updates and local changes in separate layers

Remote subscriptions make it possible for the source provider to update nodes, proxy groups, and rules centrally, but a refresh may overwrite edits made directly to that Profile. To keep updates and customizations maintainable, separate “content generated remotely” from “content customized locally.”

Option 1: Use the client’s override feature

Some clients support overrides, mixins, or script processing. After downloading a remote configuration, they can append or modify selected fields, such as standardizing ports, enabling LAN access, adding rules, or replacing DNS settings. Override syntax is not a universal standard across Clash clients, so export and inspect the format before migrating to another client.

Option 2: Use proxy-providers and rule-providers

mihomo can split external content into separate proxy providers and rule providers. The main configuration handles ports, DNS, proxy groups, and rule order, while providers load nodes and rule sets from a URL or file path. This lets you update external data without replacing the entire main configuration.

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

proxy-groups:
  - name: PROXY
    type: select
    use:
      - remote-nodes

The example URL uses a reserved domain that cannot be resolved and is provided for structural illustration only. In practice, enter a valid source and confirm that its response matches the proxy provider format. A complete subscription configuration does not necessarily have the same structure as a provider file; do not assume that placing any subscription URL in proxy-providers will make it parse successfully.

Option 3: Maintain a complete local configuration

When you need precise control over rule order, DNS routing, and TUN behavior, maintain a complete local YAML file and update the node section manually. This provides clearer control but requires more maintenance. After every change, run a configuration check before switching to it as the active Profile. Never let an unverified file replace a stable version directly.

A troubleshooting path for import and switching failures

Check Profile issues in this order: source retrieval, file parsing, core runtime, system traffic interception, and rule matching. Layer-by-layer diagnosis is more effective than repeatedly deleting and re-importing, and it preserves the original failure state.

The list is empty after importing a subscription

• Confirm that the subscription URL is still valid, and check whether the client reports an HTTP status or timeout.
• Confirm that the response is YAML readable by Clash, not a login page, error message, or format intended for another client.
• Check the system clock. Certificate validation, subscription expiry, and remote requests can all be affected by a significantly incorrect system time.
• If the current network cannot reach the subscription source, use an existing stable Profile to establish a connection before updating.

The configuration imports but cannot be activated

• Check the exact field and line number in the log, focusing on YAML indentation, array syntax, and duplicate keys.
• Confirm that the fields used by the configuration are supported by the current core. Extension fields written for mihomo may not be accepted by an older Clash core.
• Check whether the listening port is already occupied by another program or another core instance.
• Check that every proxy group referenced by the rules exists, with matching names, capitalization, and characters.
• Check whether external provider files downloaded successfully, whether their paths are writable, and whether their contents match the required provider type.

The switch succeeds, but the traffic path does not change

• Confirm that the active Profile marker in the client has changed and check whether the core has finished reloading.
• Confirm that the system proxy address and the new Profile’s listening port match.
• Confirm that the current mode is not Direct, and check which rule ultimately matched the target request.
• When using TUN, check the virtual interface, routes, and permission status. After disabling TUN, verify separately that no stale system proxy setting remains.
• A browser or application may reuse an existing connection. After switching, close the related connections or restart the application before testing again.

Build a repeatable daily configuration workflow

A maintainable workflow can be reduced to six steps: import, name, check, enable, test, and back up. Record the source and purpose on first import; check syntax and compatibility before loading; after enabling, verify proxy groups, DNS, rule matches, and the traffic entry point separately; once stable, create a local rollback version.

When updating a remote configuration, do not look only at whether the node count changed. Also check key proxy group names, rule order, DNS mode, and listening ports, because these directly affect existing client selections and system settings. If the update causes problems, roll back to a verified Profile first, then compare the structural differences between the two configurations.

For devices that frequently move between workplaces or network environments, keep scenario-based configurations such as “Home - System Proxy,” “Mobile Network - TUN,” and “Development - Local Rules.” Each configuration should have a clear purpose and follow consistent naming. When the network changes, switch to a verified scenario instead of temporarily editing many fields.

The goal of Profile management is not to accumulate more files, but to make each configuration’s source, update method, intended use, and rollback relationship clear. Separate remote subscriptions from local changes, distinguish node selection from full-Profile switching, and verify activation in a fixed order to keep multi-Profile use manageable.