What Is a Clash Profile: Breaking Down the Structure and Managing Multiple Configs

What exactly is a Profile

A lot of people treat "subscription link" and "config file" as the same thing, but strictly speaking they're not identical. A subscription link is an HTTP address that the client periodically requests; what comes back is the actual config file, usually a piece of text in YAML format that's commonly called a Profile. The client downloads this text locally, parses it, and loads it — the node list, proxy group switches, and rule matches you see in the UI all come from the contents of this one YAML file.

A Profile is essentially just a structured text config — nothing mysterious or complicated about it. Break it open and there are really only three core sections doing the actual work: node definitions, proxy group orchestration, and the rule list. The rest of the fields are mostly runtime parameters like ports, log level, and DNS. Once you understand these three sections, you basically understand how a Profile operates.

Nodes, proxy groups, rules: what each section controls

Read through a Profile from top to bottom and you'll notice the content is basically organized into three tiers, with clear reference relationships between them. If you don't understand this reference chain, managing multiple configs and adjusting rules later will end up being much harder than it needs to be.

proxies: what a node is

The proxies section lists all available proxy servers. Each entry contains connection parameters like server address, port, encryption method, and password or key, corresponding to a specific server node. This is the lowest-level "raw material" — it doesn't directly decide where traffic goes, it just declares "which servers are available."

proxy-groups: what a proxy group is

The proxy-groups section organizes the nodes declared above into logical groups. Common group types include:

• select — a manual selection group, shown in the UI as a row of node buttons; whichever you click is the one that's used;
• url-test — an automatic latency-testing group that picks the best node based on delay, usually paired with a periodic probing interval;
• fallback — a failover group that automatically switches to a backup node if the primary one goes down;
• load-balance — a load-balancing group that spreads traffic across multiple nodes.

Proxy groups can also be nested and reference each other — for example, an auto-select url-test group can appear as one of the options inside another manual select group. This nesting is one of the easiest things to overlook when troubleshooting unexpected rule matches.

rules: what a rule is

The rules section is a list matched top to bottom, line by line. Each rule consists of a match condition and a target policy, in a format like:

DOMAIN-SUFFIX,openai.com,US Node
DOMAIN-KEYWORD,github,Auto Select
GEOIP,CN,DIRECT
MATCH,Auto Select

Common match conditions include DOMAIN (exact domain), DOMAIN-SUFFIX (domain suffix), DOMAIN-KEYWORD (domain keyword), GEOIP (by the region the destination IP belongs to), and IP-CIDR (by IP range). The last line is usually MATCH, the catch-all that applies "when nothing above matches." Rules are compared top to bottom, and as soon as one matches, its policy is applied immediately and matching stops there — this "first match wins" behavior is the key premise for the rule-overwrite issue discussed later.

How switching works when multiple subscription configs coexist

The longer you use Clash, the more likely you are to end up with more than one subscription. Some providers offer multiple lines each tied to a different subscription URL; some users keep one subscription for daily use and a separate custom-rule subscription for specific scenarios. When multiple configs coexist, clients generally follow a few consistent rules of behavior.

Configs load exclusively, not additively

At any given moment, the client only has one Profile loaded and running. Switching configs is essentially "unload the current config, load another one" — it's not a process where multiple configs' rules get merged and take effect together. This is a common point of confusion: some users assume that adding a second subscription means the two sets of rules get combined, but in reality, switching replaces the previous config's nodes, proxy groups, and rules entirely — nothing crosses over between them.

When the switch takes effect and its scope

Switching configs rebuilds the proxy groups and rule table. Connections already in progress generally aren't interrupted, but any new connection immediately gets matched against the new config's rules. If a site suddenly stops working after a switch, it's most likely because the new config has a different policy for that domain than the old one — check the new config's rule matches first before rushing to restart the client.

Where auto-update and manual switching draw the line

Each subscription can have its own auto-update interval set independently. Auto-updating only refreshes the content of that specific subscription — it doesn't affect which config you currently have selected. In other words, multiple subscriptions can each keep updating on their own schedule in the background, but whatever's active in the UI is always the one you've manually selected. Updating and switching are two independent processes that don't trigger each other.

Naming habits: keeping multiple configs from turning into a mess

Once you have several configs, the first problems that come up usually aren't technical — they're human error, like meaning to switch to your work-specific ruleset but accidentally clicking a different subscription with a similar-looking name. Building a clear naming habit early on saves a lot of troubleshooting time down the line.

• Prefix by purpose: something like "Daily-ProviderX," "Work-RuleSet," or "Test-SelfHosted" lets you tell at a glance what a config is for;
• Note the update cycle or lifespan: if a subscription is a short-term one you're using just to test speed, add a date or the word "temp" to the name so it doesn't get mixed in with your permanent configs;
• Avoid keeping default file names: many clients auto-generate a name like "config.yaml" when importing a subscription, and if several subscriptions all end up with that same default name, they become impossible to tell apart — rename immediately after import;
• Note down where the subscription came from: if the client supports a notes field, jot down the provider or purpose there, so that six months later you can still tell at a glance what each one was for.

How to keep rules from getting overwritten

"Rules getting overwritten" usually doesn't mean two configs' rules literally collide — it means that after manually adding or editing rules within a single config, the next automatic subscription update replaces the whole file with fresh content from the server, wiping out those manual changes without warning. This is one of the easiest traps to fall into when managing multiple configs.

Why this overwrite happens in the first place

Most clients update a subscription by replacing the entire local file with the complete YAML content returned by the server, rather than merging field by field. In other words, if you manually add a custom rule to the local rule list, and that rule doesn't exist in the original content returned by the server, the next time an auto-update fires, that manually added rule disappears along with the rest of the file being replaced — with no notification.

Three ways to avoid it

1. Use the client's "override" or "extra rules" feature: some clients let you maintain a separate local override file outside of the subscription itself — updating the subscription only replaces the subscription's own content, while the local override stays independent and keeps taking effect on its own. This is the recommended approach;
2. Turn off auto-update for that subscription and maintain it manually: if a config needs frequent manual rule adjustments and the provider doesn't update it often, you can simply disable auto-update — changes will only get overwritten when you deliberately click "update," which keeps the risk under control;
3. Keep custom rules in a separate file and merge them via a subscription conversion tool: a good fit for users comfortable with a bit of tinkering — maintain your manual rules as an independent rule file, then use a subscription conversion service to splice the original subscription and your custom rules into a new subscription URL. That way, every update pulls content that's already merged, and you don't have to keep re-adding rules by hand in the client.

A few habits worth building into routine maintenance

Once you're juggling more configs, it's worth building a few fixed checks into your routine so you catch problems before they grow:

• Periodically open the rule list and confirm the final MATCH catch-all policy still points to the group you expect — subscription updates can quietly change this without you noticing;
• After switching configs, run the client's built-in latency test to refresh node status — the node pool in a new config often isn't quite the same as the old one;
• If you're maintaining several configs at once, periodically clean out old subscriptions you no longer use to reduce the odds of switching to the wrong one by mistake;
• Get into the habit of keeping a local backup copy whenever you manually add rules — even if you're using an override feature, it's still worth keeping a text copy in case the client's data gets lost.

Once you understand the reference chain between nodes, proxy groups, and rules, and pair it with clear naming and a sensible update strategy, managing multiple configs at once stops being a burden — it actually lets you route traffic for different scenarios more precisely and with more control.