What Is a Clash Profile? Subscriptions vs. Local Configs and Managing Multiple Profiles

A Profile is a configuration managed by the client

A Profile is usually a configuration saved by the client. It is neither a proxy node nor a proxy protocol. It can come from a remote subscription or a local YAML file. The client stores its source, name, update details, and active status. The core reads the resulting configuration to open listening ports, load nodes, and apply routing rules.

A complete configuration can include mixed-port, mode, dns, proxies, proxy-groups, and rules. Nodes contain connection parameters, policy groups let you choose nodes, and rules determine which policy handles each connection. Switching Profiles can change all three—not just the server you connect to.

Depending on the client, the menu may be called “Config,” “Subscriptions,” or “Profiles.” These are interface labels, not menu names standardized by Clash or the mihomo core. To confirm an action worked, check the active Profile indicator, core load results, and actual routing rules—not just whether another card appears in the list.

Remote subscriptions vs. local YAML files

The main difference is where the configuration comes from and how it gets updated—not what YAML can do. A client typically fetches a remote subscription from a URL, while users import, create, or edit local configurations themselves. A remote response may be a complete Clash configuration in YAML, but a “subscription URL” is not guaranteed to return a complete configuration that can be loaded as-is.

A subscription URL is not necessarily a configuration file URL

Some services return a complete YAML file, some return only a list of nodes, and others return a collection of encoded proxy links. The latter two formats need to be supported by the client or converted through a trusted process before they can become a usable configuration. Opening a URL in a browser only confirms that it returned a response; it does not mean the response is compatible with your core.

If importing fails with missing fields or a parse error, first check whether the response is a login page, an error message, or an unsupported format. Subscription URLs often contain access tokens. Don't share the full URL when troubleshooting or submit it to an untrusted online converter.

Understand configuration boundaries with a minimal YAML file

This local configuration illustrates how the fields fit together. It listens on 127.0.0.1:7890 and sends all connections through the built-in DIRECT policy. It has no remote proxy nodes, so it cannot be used to test a proxy's exit route. Use it in an isolated test Profile to check YAML loading and rule structure.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: ROUTE
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,ROUTE
  - MATCH,DIRECT

• mixed-port: 7890 makes the same port accept both HTTP and SOCKS proxy connections. If the port is already in use, choose an available one.
• mode: rule routes connections according to the rules list. If the runtime switches to global mode, these rules no longer determine routing.
• ROUTE is the policy group name, and rules must use exactly the same name to reference it. The built-in DIRECT policy does not require a separate node.
• MATCH is the fallback rule. Put it last in this example; otherwise, later rules will never be checked.

Use spaces for indentation, not tabs. When importing an existing subscription, do not replace its entire file with this example. It only demonstrates the structure and does not include the provider's nodes or policies. See the configuration field reference for details on all supported fields.

Naming, updating, and switching between Profiles

Use names for purpose and notes for source

A useful naming pattern is “purpose – source – management method,” such as “Daily – Subscription A – Remote,” “Work – Local Rules – Override,” or “Troubleshooting – Direct – Local.” Avoid generic names like “Config 1” and “Config 2,” and never include subscription tokens in a name. If the client supports notes, record the import date, core type, and override location there instead of cramming everything into the name.

Check updates and switches separately

1. Keep a way back before updating: Export a working configuration and save your current policy group selections and local overrides. Exported files may contain node credentials, so store them in a secure location.
2. Update only the intended Profile: Confirm its name and source, then check whether the last-updated time changed. A new timestamp does not mean the configuration is active.
3. Check the load result: After activating the target Profile, review the core logs for YAML parse errors, failures caused by unknown fields, or invalid policy references.
4. Review runtime settings: Check the proxy mode, listening ports, DNS, and TUN setting. Some clients override fields in the file with global settings of their own.
5. Test a new connection: Make a new request and check its matched rule, policy chain, and exit route in the connections panel. Don't rely on node latency alone.

For example, if the old configuration listened on 7890 and the new one uses 7891, the existing http_proxy setting in your terminal will not update automatically. A browser's system proxy setting and terminal environment variables are also separate. Keeping the local listening port consistent across Profiles helps prevent port mismatches after switching.

Keep custom rules from being overwritten by subscription updates

Whenever possible, save personal rules in a persistent override layer supported by the client rather than editing the downloaded subscription copy. Common approaches include configuration merging, prepended rules, and configuration scripts, but names, scope, and array merge behavior vary by client. There is no universal override file format that works with every client, so check your client's documentation before making changes.

Check where rules are inserted, then verify policy names

Suppose you want traffic to an example domain to go direct. You can place the following rule near the top of the final rules list. This shows the intended order in the final configuration, not override syntax that can be applied to every client as-is:

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,ROUTE

In rule mode, rules are evaluated in order, and the policy for the first match is applied. Personal rules appended after MATCH usually won't work as intended. If a rule references ROUTE, the final configuration must contain a policy group with that exact name. If a subscription update renames the group, update the override too.

• Check the scope: Does the override apply to one Profile or to every configuration? Work-related rules should not unexpectedly affect other Profiles.
• Check how lists are merged: A client may replace the entire rules array, prepend entries, or append them. Don't assume what “merge” means.
• Inspect the final configuration: If the client offers a runtime configuration preview, check that your rules appear in the right order and that the target policy exists.
• Test after an update: Save the override, manually refresh the subscription, then review the rules and test a new connection to confirm the changes survived the update.

If your client doesn't support persistent overrides, you can copy the configuration to a local Profile and edit it. That copy will no longer receive node updates from the original subscription automatically. Choose whether to maintain the copy manually or keep using remote updates; don't mix local edits with automatic refreshes in the same temporary file.

proxy-providers and multiple Profiles are different management layers

proxy-providers lets a configuration reference node providers; multiple Profiles are separate configurations saved by the client. For example, mihomo can use multiple providers in one local configuration, keeping node sources separate from local rules. You still need to configure policy groups to reference those providers correctly.

Provider updates usually refresh only the nodes they supply, not the entire main configuration. The provider URL must also return a format supported by the implementation; not every “subscription link” can be used directly. If you also use rule-providers, troubleshoot rule set downloads separately from main configuration updates.

For typical use, start with one reliable subscription and add clearly defined local overrides. Consider providers only when you need to separate node sources, rule sets, and update schedules. This avoids maintaining duplicate rules across multiple configurations and makes it easier to trace where the active settings came from.

Troubleshoot issues after switching configurations in four layers

1. Source: Confirm you updated the intended Profile and that the response is a configuration, not a web page. Check whether the subscription has expired, and avoid repeatedly importing the same invalid URL.
2. Loading: Check whether the core accepted the new configuration. If you find an indentation error, a missing policy, or an unsupported field, fix the loading issue before blaming a node timeout.
3. Entry point: Check that 7890 or your custom port is listening and that the system proxy and terminal point to the same entry point. For TUN, also check permissions, routing, and DNS interception.
4. Routing: Confirm the runtime mode is rule, then check the rule matched by a new connection and its policy group selection. Only then investigate a remote node or server issue.

Good Profile management keeps source updates, local edits, and runtime selections separate. Keep one known-good configuration, update only the intended Profile, and verify the final rules and new connections after every switch. This usually makes issues easier to track down than repeatedly deleting and reimporting configurations.