A Profile is the complete config unit a Clash client loads, and it has a containing relationship with subscriptions, nodes, and rules. This article breaks down where profiles come from, where they're stored, how they update, and how to switch between multiple profiles.
In the context of Clash and its derivative cores (Clash Premium, Clash Meta, mihomo), a Profile refers to the single complete YAML file the client actually loads and applies. It isn't a synonym for "subscription," nor for "node list" — a subscription is just one channel for obtaining a profile, and nodes are just one section within it. Getting this containment relationship straight makes the later discussion of storage location, update logic, and switching between profiles much easier to follow.
A typical Clash config file usually contains the following sections, in order:
Only when these five sections come together do you get a complete, usable Profile. Without the proxies section, proxy-groups have nothing to choose from; without the rules section, the client can only fall back to the global default behavior set by mode, with no real traffic splitting.
By origin, Profiles fall into roughly three categories, and in practice they're often mixed:
This is the most common approach. A provider offers an HTTP(S) link; when the client requests it, the server returns node information (sometimes full YAML, sometimes a Base64-encoded node list). Most Clash-family clients (Clash Verge, FlClash, ClashX Meta, etc.) take that node data, combine it with a built-in or custom rule template, and assemble a complete usable Profile, which is then saved locally. This is why the same subscription link can produce a different proxy-group structure or rule count depending on which client imports it — the assembly template differs.
If you already have a YAML file someone shared, or one you put together yourself, you can load it directly via the client's "import from file" feature without any network request. This kind of Profile never updates automatically — its content stays completely fixed, which makes it well suited for debugging and offline scenarios.
Advanced users often edit proxy-groups and rules directly with a text editor or the client's built-in config panel — common cases include adding a custom node to a proxy group, assigning a dedicated exit for a specific app, or blocking a particular domain. It's a good idea to back up the original file before making such edits, so a syntax error that breaks loading doesn't leave you without a way back.
A Profile is a local file, and its exact storage path varies by client — when troubleshooting, you often need to go check the folder manually to confirm the file has actually been updated. Common storage patterns are roughly as follows:
| Client | Storage pattern | Notes |
|---|---|---|
| Clash Verge / Clash Verge Rev | A profiles folder under the app data directory; each subscription maps to a .yaml file named with a hash/UUID | config.yaml records which one is currently active |
| ClashX Meta (macOS) | The .config/clash/ folder under the user directory | Files can be opened directly with a terminal or text editor |
| FlClash (cross-platform) | A profile subfolder inside the app's private data directory | Editing files directly on mobile isn't advised; use the built-in editor panel instead |
| Bare core (mihomo/Clash Meta core) | The path passed via the -f launch flag; defaults to config.yaml in the current directory | No GUI wrapper — the path is entirely determined by how it's launched |
It's worth stressing that most GUI clients don't recommend hand-editing these auto-generated files directly in the app data directory — the client's own update logic may overwrite manual changes on the next refresh. If you need to keep custom rules long-term, the safer route is to use the client's "merge" or "override" feature, storing custom snippets separately and layering them on top of the subscription-generated main config.
Only a Profile obtained via a subscription link supports the "update" action — locally imported or hand-written files never change on their own. The update mechanism mainly depends on two fields:
During an update, the client generally only replaces node-related content and leaves any custom rules you've added alone (provided you used the merge/override mechanism instead of directly editing the auto-generated file itself). If your custom routing rules disappear after an update, it's most likely because the change was written into the main file that gets overwritten — switch to using the override feature and reconfigure it there instead.
Most users don't stick to a single config — for example, subscribing to two providers at once, or keeping a locally saved variant tuned for streaming traffic alongside a minimal one for everyday browsing. In that setup, "switching" and "managing" profiles becomes a routine part of daily use.
At runtime, the core only ever loads one Profile. The "config list" you see in the GUI is really just several saved YAML files; clicking one sets it as the active config, and the client reloads the core to apply the new proxies, proxy-groups, and rules. A brief connection interruption during the switch is normal.
Once you have several configs, the default generated filenames make it hard to tell them apart. It helps to rename each one in the client and label its source and purpose clearly — separating out categories like "daily subscription," "temporary test," and "local custom rules" — to cut down on the risk of switching to the wrong one by mistake. Some clients also support tagging or grouping configs so you can organize them by scenario.
If you just want to add a few custom rules on top of an existing subscription (say, forcing a particular internal service domain to connect directly), there's no need to create a whole new config — it's better to use the client's "override" or "merge config" feature. These let you maintain a small standalone YAML snippet (typically just the rules you want to add or replace), which gets layered on top of the main config when applied. The override snippet survives even after the main config updates, so you never have to re-add it.
Test configs you no longer use should be deleted promptly, especially any that contain real node credentials — even after a subscription expires, the key information in that file is still stored locally in plain text. Cleaning up old configs is basic hygiene for regular use.
| Question | Answer |
|---|---|
| Are a Profile and a subscription the same thing? | No — a subscription is one channel for obtaining a Profile; the Profile is the final config file that actually takes effect |
| Will manual edits to a config file get overwritten by the next update? | Directly editing the auto-generated main file will get overwritten; use the override/merge feature to keep custom content separate |
| Can multiple configs be active at the same time? | The core only loads one at a time — multiple configs are handled by switching, not simultaneous stacking (layering is handled via the override mechanism) |
| Do locally imported files update automatically? | No — only a config tied to a subscription link can update automatically or manually |
Once these points are clear, the "config management," "subscription info," and "override" labels in the client UI will map cleanly onto the storage, update, and layering mechanisms covered here, making it much harder to mix up Profile, subscription, node, and rule as concepts.