What Is a Clash Profile? Core Concepts and Managing Multiple Configs

What Is a Profile: The Blueprint Behind Every Clash Run

Let's answer the question people ask first: what exactly is a "Profile" in Clash? It's a plain-text YAML file. Everything Clash does after launch—which port it listens on, how traffic gets routed, which proxy handles the outbound connection—all follows what's written in that file. In Clash Verge, Clash for Windows, and most mihomo-based GUI clients, each entry listed under the "Profiles" tab is one standalone Profile, and clicking one switches it into effect.

Open any Profile and the structure looks roughly the same: a block of general settings, plus three core sections.

mixed-port: 7890        # Local proxy port
allow-lan: false        # Whether to allow LAN devices to connect
mode: rule              # Routing mode: rule / global / direct
log-level: info

proxies:                # List of proxy nodes
  - name: "NodeA"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:           # Proxy groups: bundle nodes for rules to reference
  - name: Auto Select
    type: url-test
    proxies: ["NodeA", "NodeB"]
    url: http://www.gstatic.com/generate_204
    interval: 300

rules:                  # Routing rules: matched top to bottom
  - DOMAIN-SUFFIX,google.com,Auto Select
  - GEOIP,CN,DIRECT
  - MATCH,Auto Select

• proxies: the list of proxy nodes. Each entry specifies the protocol, server address, port, and credentials — these are the raw ingredients of the whole config.
• proxy-groups: proxy groups. Nodes get bundled into groups — manual selection, auto speed-test (url-test), failover (fallback) — and rules only ever reference a group, never a node directly.
• rules: routing rules. Matched top to bottom; whichever rule hits first decides where the traffic goes, with MATCH as the catch-all at the end.
• General settings: mixed-port (local proxy port), allow-lan (whether LAN devices can connect), mode (rule / global / direct), log-level, and more. Configs built for the mihomo core also add sections like dns and tun.

The short version: proxies are the raw materials, proxy-groups are the drawers they're sorted into, and rules decide the order they get pulled. All three need to be in place for anything to work — skip rules and everything funnels through one group; skip proxies and there's nothing to route at all.

Subscription Links vs. Local Files: Two Origins of a Profile

By origin, a Profile is one of exactly two types: generated from a subscription link, or imported as a local file. They look identical in your client's config list, but they behave completely differently — and mixing them up is the root cause of nearly every "my edits vanished" complaint down the line.

There's nothing mysterious about a subscription link: your provider hosts a YAML file at some URL, and the client downloads it and saves a local copy inside its config folder. So a subscription-based config is, technically, still a .yaml file sitting on your disk — it just comes with a built-in habit of periodically re-downloading the "latest version." That habit is exactly what causes the symptom in the next section.

Why Edits Keep Getting Wiped: Updates Replace the Whole File

The symptom: you add a few rules or tweak a port in a subscription-based config, everything works fine at first — then a few days later, it's all reverted, as if you never touched it.

The cause: updating a subscription means re-downloading the file from the original URL and replacing the local copy entirely. The client doesn't diff anything, and it definitely doesn't preserve your manual edits. If you've set an auto-update interval (commonly 24 or 48 hours), it overwrites silently the moment that timer hits — no warning, no confirmation. This isn't a bug; it's the subscription mechanism doing exactly its job: keeping your config identical to whatever the provider is serving.

Three Ways to Keep Your Custom Edits Safe

In order of how much effort they take, smallest first:

1. Merge / override mechanism (recommended). Clash Verge's "Merge" feature and Clash for Windows' Mixin work on the same idea: the original subscription stays untouched, and you write a small YAML patch on the side that the client layers on top when loading the config. Subscription updates only replace the base file — your patch keeps applying automatically. This is ideal for small tweaks: adjusting the dns block, adding or removing a few rules, changing a port. Two things to watch: a typo in a field name fails silently, so reload the config and check the logs after every edit; and when the patch conflicts with the original, priority rules vary by client — check that client's documentation.
2. Save a local copy and edit that instead. Save the downloaded subscription file as a separate copy and import it as a local file — from then on you can edit freely, and updates never touch it. The tradeoff: it's now disconnected from the subscription, so any new nodes or rule changes on the provider's end have to be merged in by hand. Best for heavy customization on a subscription that rarely changes anyway.
3. Split references via proxy-providers / rule-providers (mihomo core). Build your own local master config: point proxy-providers at the subscription URL for nodes, and rule-providers at an external rule set. The master config stays entirely under your control, while the subscription is just a referenced ingredient — updates on either side never interfere with the other.

proxy-providers:
  My subscription:
    type: http
    url: "https://example.com/subscribe.yaml"
    interval: 86400
    path: ./providers/subscribe.yaml
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 300

This third option has the steepest learning curve but pays off the most: the master config holds only your own proxy groups and rule skeleton, nodes refresh automatically from the subscription, and "overwritten" stops being a concept you ever deal with.

Running Multiple Configs: Naming, Switching, and Backups

Keeping two or three configs around at once is common — one per provider, a primary and a backup line, separate configs for work and home. Managing multiple configs day-to-day comes down to a few habits:

• Rename it the moment you import it. The default name is usually an unreadable string of characters — rename it to something like "provider + purpose" so it still makes sense three months from now.
• Keep the port consistent across configs. Make sure mixed-port matches in every config (e.g., always 7890). Otherwise, after switching configs, whatever port your system proxy or other apps have hardcoded won't match anymore — the symptom is "switched configs, now I have no internet."
• Don't set the update interval too short. 24 hours is plenty for a subscription config; polling more often gets you nothing except more chances for your edits to get overwritten.
• Check three things after switching. Confirm the mode is still rule, confirm the system proxy is actually enabled, and test a site outside mainland China to verify the connection works. Switching configs rebuilds the core, so a brief drop in active connections is normal.
• Keep two kinds of backups. Copy the entire config folder somewhere safe, and separately keep a record of the raw subscription URLs — with the link in hand, you can always rebuild a config from scratch. That's the single most useful safety net.

Quick Symptom Reference

• Custom rules disappear after a subscription update → Switch to merge/override or a local copy; see the fixes in section four.
• "Failed to parse" when importing a subscription → The URL most likely isn't returning YAML: some subscription endpoints only return Clash-formatted output when they detect a matching client User-Agent, or need to go through a subscription converter first. Bad file encoding can also trigger this error.
• "Port already in use" when switching configs → Two configs have the same mixed-port, or the previous core process didn't fully exit — kill the leftover process, then switch again.
• Edits don't take effect → Reload or restart the core after editing. Some clients reload automatically on save; others need a manual click — don't skip that step.

That covers the essentials of a Profile: one YAML file, two possible origins, one hard rule about overwrites, and three ways to protect your edits. For getting the client itself and importing your first subscription, head to the links below.