Breaks down the core fields of a Clash profile: what the port settings, proxy groups, and rules sections each do, and which parts get overwritten when a subscription refreshes. Also covers how to switch between multiple profiles, deduplicate nodes, and back up your setup without losing custom edits.
In the Clash ecosystem, a "profile" refers to a piece of text in YAML format that records the local ports, the list of outbound nodes, the grouping logic for proxy groups, and a complete set of traffic-splitting rules. The policy groups, latency test results, and rule-matching outcomes you see in the client interface are, at their core, just this YAML being parsed and rendered. Whether you manually enter a subscription URL or import a local file, what the client is actually doing is fetching this piece of text (whether remote or local), validating its format, and then handing it off to the core (Clash Premium or mihomo) to load and run.
Understanding the structure of a profile isn't just about troubleshooting faster — more importantly, it helps you determine "which changes are safe, and which ones will get wiped out the next time the subscription refreshes." That's the core question this article aims to answer.
A complete profile can roughly be divided into four blocks. The order isn't fixed, but client interfaces usually group and display them following the logic below.
This section determines which ports the core listens on and what mode it runs in. Common fields include:
| Field | Purpose |
|---|---|
| port | HTTP proxy listening port |
| socks-port | SOCKS5 proxy listening port |
| mixed-port | Combined HTTP/SOCKS5 port; most clients enable this by default instead of running two separate ports |
| allow-lan | Whether other devices on the local network can connect through this proxy |
| mode | Running mode, either rule / global / direct |
| log-level | Log verbosity; usually temporarily set to debug when troubleshooting |
| external-controller | Address the RESTful API listens on; the client's graphical interface reads runtime status through it |
Most of these fields have default values. The "port settings," "mixed port," and "LAN access" toggles you see in a client's graphical interface are really just editing this block.
proxies is an array where each item describes one outbound node. Common fields include name (display name), type (protocol type, such as ss, vmess, trojan, hysteria2), server, port, plus protocol-specific parameters like encryption method, UUID, or password. This section almost never needs manual editing — it's generated by your subscription provider, and all you need to do is make sure the subscription URL itself is valid.
proxy-groups determines how nodes get "packaged" into a selectable group. Common fields for each entry:
The rows of "select a node" dropdowns you see in a client interface correspond directly to the select-type groups defined here.
rules is a list matched from top to bottom, typically in the format type,match value,target policy. Common types include DOMAIN-SUFFIX (domain suffix matching), DOMAIN-KEYWORD (domain keyword), IP-CIDR (IP range matching), GEOIP (matched against a geolocation database), and RULE-SET (references an external rule set). There's usually a final MATCH,policy name entry as a catch-all, which handles any traffic that didn't match earlier rules. The earlier a rule appears in the list, the higher its priority — once a rule matches, no further rules are checked.
Additional note
Newer Clash Meta (mihomo) cores also support a rule-providers field, used to declare external rule sets (for example, pre-packaged rule files organized by domain category). The rules section references these via RULE-SET,rule set name,policy, allowing the rule file to be updated independently instead of hardcoding thousands of domains into the main config.
This is where people most often trip up. A subscription URL points to a complete YAML file hosted by the provider, and when a client "updates the subscription," it's essentially re-downloading that file and replacing the local cache wholesale. In other words, as long as the subscription provider's original file includes proxies (node list), proxy-groups (group structure), and rules (rule list), all three of these blocks will be fully overwritten with the provider's latest version after an update — any custom rules you added manually, or any reordering of groups you did, will almost certainly disappear along with it.
As for basic runtime parameters like ports, the LAN toggle, or the mode — this varies by client. Most graphical clients store these settings as a separate "runtime override" layer that isn't written back into the subscription file itself, so refreshing a subscription usually doesn't affect port settings. But if you're directly editing a local YAML file and importing it as a "local configuration" rather than going through the subscription-refresh mechanism, there's no overwrite issue at all — because there's no "re-download" step to begin with.
One case worth flagging specifically: some subscription providers let you append parameters when generating a link to insert custom rules or force certain groups. That kind of content also gets rewritten on every update, and it can't coexist with your local edits. The rule of thumb boils down to one sentence: if the content comes from a "download" rather than "manual input," it will be overwritten by the next download.
Most graphical clients (Clash Verge Rev, FlClash, ClashX Meta, and others) support saving several profiles at once and switching between different subscriptions or local files via a list in the interface, with each profile independent of the others. When managing multiple profiles, a few principles are worth following.
If you use multiple subscription providers at once, or keep one profile for daily use and another for testing new nodes, save them as separate profiles rather than copy-pasting back and forth within the same file. That way, switching is just a matter of selecting from a list in the client — no text editing involved, and the lowest possible chance of mistakes.
If you genuinely need to keep certain custom rules long-term (say, whitelisting a direct connection for some internal service), the more reliable approach is to use the client's "override" or "merge" feature — most modern clients let you maintain a separate local override file outside of the subscription. When the subscription updates, only the provider's original content gets replaced, while the local override stays intact and isn't overwritten along with it. If your client doesn't support this, the fallback option is to manually back up the currently active YAML before every update, then paste your custom rule sections back in afterward.
Using the same subscription account for a long time tends to accumulate redundant nodes in the list, or nodes that have gone offline but are still sitting in a group. It's worth building a habit of checking regularly:
If you're migrating to a new device or reinstalling a client, keeping just two things is usually enough to fully restore your previous setup: the subscription URL itself (so you can re-fetch the latest nodes and rules at any time), and your local override or custom rules file, if you have one. There's no need to separately back up the client's cached temporary files — those get regenerated automatically the next time the subscription is fetched.
Note
Don't upload profile files that contain sensitive information like node passwords or UUIDs to public repositories, or share them with parties you don't trust. Treat the subscription URL itself as sensitive information too — if it's ever exposed, reset it in your provider's dashboard as soon as possible.
Combined with the field breakdown above, most common problems can be traced back to a specific block:
Once you approach a profile as a piece of structured configuration rather than an unreadable blob of YAML, most troubleshooting becomes noticeably more grounded. When a toggle in the interface doesn't behave the way you expect, checking the field value it maps to is usually more productive than reinstalling the client over and over.