What Is a Clash Configuration File: Profile Basics and Managing Multiple Configs

NT-05.1What Is a Profile

Once a Clash client starts up, the node list, proxy groups, and routing rules you see on screen all come from the same file — commonly called a profile, or configuration file. It's essentially a YAML text file describing three things: which proxy nodes exist, how those nodes are grouped, and which traffic goes through which proxy group. The client itself is just an execution engine — it stores no node information on its own. Everything it does is determined by whichever profile is currently loaded. That's why swapping in a different config file on the same client can completely change the nodes, groups, and rules shown in the interface.

Understanding profiles matters because when you run into issues like missing nodes, rules that don't apply, or renamed groups, the first move shouldn't be to suspect the client is broken. Instead, check which profile is currently loaded and whether it was recently updated. Most usage confusion traces back to the config file itself, not the client program.

NT-05.2How a Configuration File Is Structured

A standard Clash / mihomo config file is made up of several top-level fields. The most common ones and their roles are listed below. Field names are case-sensitive and must match the spec exactly.

A minimal skeleton looks roughly like this. Real-world configs will have more fields, but the core structure stays the same:

proxies:
  - name: "sample-node"
    type: vmess
    server: example.example
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000

proxy-groups:
  - name: "Auto Select"
    type: url-test
    proxies: ["sample-node"]
    url: "http://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,example.com,Auto Select
  - MATCH,DIRECT

The three sections have a clear dependency chain: proxy-groups references node names declared in proxies, and rules in turn references proxy group names defined in proxy-groups. Renaming anything in one section without updating the other two triggers errors like "proxy group can't find node" or "rule points to a nonexistent group" — this is the most common source of hand-edited config mistakes.

NT-05.3Where Configs Come From: Local Files vs. Subscription Links

Config files typically come from one of two sources, and the choice has a big impact on ongoing maintenance.

• Local file: a hand-written or downloaded YAML file. It won't change automatically once imported, so when a node stops working you have to manually swap in a whole new file.
• Subscription link: an HTTP/HTTPS URL that the client periodically requests to fetch the latest content and overwrite the local cache. Node pool updates, expiration reminders, and traffic usage are usually delivered through this URL's response headers.

NT-05.4Running Multiple Configs: Naming, Updating, and Switching

Running several subscriptions at once is common — say, one for daily use, one as a backup, and one just for testing a specific app. The biggest risk when juggling multiple configs is having them overwrite each other: two subscriptions showing the same default name in the client, updating the wrong one by mistake, or switching profiles and forgetting to confirm which one is actually active. A few habits go a long way toward avoiding these mistakes.

1. Rename each subscription immediately after importing it, tagging it with its purpose and source — e.g., distinguishing "Daily" from "Backup" — instead of leaving the client's auto-generated default name in place.
2. Before updating, confirm which profile is currently selected, then run the update — this avoids accidentally hitting the update button for the wrong profile after switching.
3. Set different auto-update intervals depending on purpose, and turn off auto-update entirely for backup subscriptions you rarely use, to cut down on unnecessary background requests.
4. Recheck your proxy group selections after switching configs — group structures and names can differ between subscriptions, so a node you manually picked before may no longer exist.
5. For configs with extensive rules or heavy customization, keep a local backup on hand in case a subscription update overwrites your custom rules wholesale.

NT-05.5Common Troubleshooting Steps

When you notice symptoms like a mismatched node count, rules that don't take effect, or a proxy group disappearing, work through the checklist below in order. Most of the time the cause turns out to be in the config file itself, and reinstalling the client won't be necessary.

1. Confirm which profile is currently active and whether an auto-update just ran.
2. Open the raw config file and check that every node name referenced in proxy-groups actually exists under proxies.
3. Check that every proxy group name referenced in rules exactly matches a name in proxy-groups, including case and full-width/half-width characters.
4. If you're using rule-providers, confirm the external rule set URL is reachable and its format matches what the client expects.
5. Only after ruling out the config file itself should you look at the node's server side or your local network environment.

Treating the config file as readable, checkable text — rather than an opaque blob you can only swap out wholesale — is the foundation of stable, long-term Clash usage. When running multiple configs side by side, disciplined naming and update habits do more to prevent mistakes than any client feature toggle ever could.