What Is a Clash Config File? Profile Structure & Multi-Config Switching

New Clash users often mix up "config file" and "subscription link," which leaves them stuck when rules don't apply, node switches have no effect, or an update breaks everything that used to work. In reality, every Clash-family client (Clash Verge, ClashX, and the various Clash for Windows forks all built on the mihomo core) runs on a YAML configuration file, commonly called config.yaml or a Profile inside the client. Understanding its structure, where it comes from, and how it updates is the starting point for troubleshooting almost every issue you'll hit.

The three main blocks of config.yaml

A complete Clash config file is plain text, and it breaks down into three functional parts: basic ports and runtime options, proxy groups, and rules. Together with the outbound node definitions (proxies), these three decide exactly which path your traffic takes.

port: 7890
socks-port: 7891
mixed-port: 7892
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies: [HK-01, JP-01, SG-01]
    url: http://www.gstatic.com/generate_204
    interval: 300

rules:
  - DOMAIN-SUFFIX,googlevideo.com,Auto Select
  - GEOIP,CN,DIRECT
  - RULE-SET,reject,REJECT
  - MATCH,Auto Select

The first part covers ports and run mode: port / socks-port open local HTTP and SOCKS5 proxy ports respectively, while mixed-port combines both into a single port that most modern clients use by default; allow-lan controls whether other devices on your local network can use this machine's proxy; common values for mode are rule (route by rules), global (send everything through one node), and direct (bypass the proxy entirely).

The second part is proxy groups, which decide "which node to pick." A select group is chosen manually with a tap in the client; url-test auto-tests latency on the configured interval and picks the fastest node; fallback falls back through a set order when the primary node is unavailable; and load-balance spreads requests across multiple nodes by hash or round-robin, useful when you need stable session persistence.

The third part is rules, which decide "which traffic goes through which group." Rules are matched top to bottom, and matching stops at the first hit. Common rule types include:

• DOMAIN-SUFFIX: matches by domain suffix — for example, googlevideo.com matches every subdomain;
• GEOIP: matches by the destination IP's country/region, most often used as GEOIP,CN,DIRECT to send mainland China traffic direct;
• RULE-SET: references an external rule-set file, making it easy to maintain large domain lists outside the main config;
• MATCH: the catch-all rule, which must sit on the last line and decides "what happens if nothing above matched."

How subscription links relate to local config files

A subscription link is essentially a URL the client can fetch directly; the server's response is the same YAML text described above (or a generic subscription format the client converts on the fly). The client doesn't re-request that text every single time — it saves the result as a local file, and that saved file is the Profile. In other words, the subscription link is "where the config comes from," and the Profile is "the config's local, saved form" — even offline, the client can keep working with whatever Profile it last synced.

A Profile doesn't have to come from a subscription; it can also be a hand-written or otherwise downloaded local file. Both types sit on equal footing in the client and appear in the same list to switch between. The only difference is that a subscription-type Profile carries a remote address, so the client can automatically re-fetch and overwrite the local file on the configured update-interval (usually in hours); a local-file Profile has no such auto-update step — any change has to be re-imported by hand.

Many subscription services include a subscription-userinfo field in the response headers, carrying used traffic, total traffic, and expiry date. The client parses this and shows it next to the Profile entry — which is why some imported subscriptions show a traffic progress bar and others just show a plain filename. It comes down entirely to whether the server sends that info, not to anything about the client itself.

Importing, updating, and switching profiles in the client

Wording differs slightly between clients, but importing a config generally falls into two categories: pasting a subscription link, or picking a local file. Here's the general flow — check your specific client's actual menu layout for exact wording.

1. Open the client's "Config," "Profiles," or "Subscription Management" page;
2. Tap the add button, choose "Import from URL," paste the subscription link, and confirm — the client will download it and parse it into a new Profile;
3. For a local config file, choose "Import from File" and point to the downloaded .yaml file;
4. Once imported, tap the entry in the list to make it the active config — most clients mark the one "in use" with a checkmark or a highlighted border;
5. To update, tap the refresh icon next to the entry to re-fetch the remote content — no need to delete and re-add it.

For auto-update, a 12–24 hour interval is a sensible range — don't set it too short. Requesting the subscription endpoint frequently is usually unnecessary (node lists rarely change more than once a day), and some providers will rate-limit or even temporarily block clients that request too often.

It's worth stressing that keeping multiple Profiles saved in the client doesn't cause any interference — at any given moment only the selected one is actually in effect, and the unselected configs just sit there statically, taking up no running ports or extra resources. That's exactly why multi-config management matters in practice: switch to a low-latency in-country relay Profile while traveling, switch back to your main subscription day to day, and spin up a throwaway draft Profile when testing new rules — all without touching each other.

Common multi-config mistakes

Once you've got importing and switching down, these are the mistakes that trip people up most often in day-to-day use.

Manual edits get wiped out by subscription updates

If you hand-write extra rules directly into a subscription-type Profile's local file, the next auto-update will overwrite the entire file with the remote content, and your manual edits will be gone. If you need long-term custom rules without losing subscription content, use the client's "Override," "Patch," or equivalent feature — it layers your own saved rules/proxy groups on top of the raw subscription content, so updating the subscription only replaces the base layer and leaves your overlay untouched.

Proxy group name clashes across subscriptions

Different providers often reuse generic group names like "Hong Kong Nodes" or "Auto Select." If you try to hand-merge two subscriptions into a single config, rules referencing a proxy group name can easily fail to resolve, and traffic falls through to the catch-all MATCH branch instead of the node you intended. Before merging configs across subscriptions, check that proxy group names are unique.

Mistaking a Profile switch for a node switch

Switching Profiles swaps the entire config — ports, rules, and proxy group definitions included — while day-to-day "switching to a different node" usually just means reselecting a node inside a proxy group within the current Profile, with no need to switch the whole config. Confusing the two means rules and routing logic change along with it, which makes it much harder to pin down the real cause when something breaks.

Setting the update interval too short

As mentioned above, setting auto-update to fire every few minutes might feel "more up to date," but in practice most subscription node lists don't change that often, and overly frequent requests just raise the risk of being rate-limited. A 12–24 hour range is reasonable — just trigger a manual update once before anything important.

FAQ

Can I keep multiple Profiles and subscription links at once? Will they conflict?

Yes — you can save any number of Profiles, since each is just an independent entry in the list and they don't interfere with each other. Conflicts only arise when you manually merge multiple subscriptions' content into one config file and mishandle naming or rule order.

Why did my rules suddenly stop working after updating the subscription?

Most likely the subscription server updated its rule set or proxy group structure, and your existing hand-edited content got completely overwritten. Using the Override/Patch feature to store your custom parts separately prevents this from happening repeatedly.

Can a local-file Profile be set to auto-update?

No. Auto-update relies on a fetchable remote address, and a purely local file has no such address — any content change has to be synced by re-importing it manually.