What Is a Clash Configuration File? A Beginner’s Guide to Profile Structure and Managing Multiple Profiles

What exactly does a Clash Profile store?

In Clash clients, Profile is usually translated as a configuration or configuration file. It is more than a simple list of nodes: it is a structured document describing how the proxy core listens on ports, resolves DNS, organizes nodes, builds policy groups, and matches traffic against rules. Classic Clash, Clash Meta, and the later mihomo core primarily use YAML, while graphical clients may also store the selected policy, subscription update time, and interface preferences outside the YAML file.

A basic configuration that can start normally usually includes listening ports, the operating mode, proxy nodes, policy groups, and rules. With mihomo, it may also include extended fields such as TUN, sniffer, rule-providers, and proxy-providers. After reading a Profile, the client parses the YAML and passes the valid content to the core process. Indentation errors, mismatched field types, or references to nonexistent policy groups can all stop loading.

The concise example below shows how these fields reference one another. The final column of each rule must point to an existing policy group. For example, “Node Select” in a rule must exactly match a name in proxy-groups, including spaces and capitalization.

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: "Node A"
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: "Node Select"
    type: select
    proxies:
      - "Node A"
      - DIRECT

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

The difference between subscription configurations and local configurations

A subscription configuration is fetched from a remote URL. The client sends an HTTP request to that address, receives Clash YAML from the server, saves it as a local copy, and loads it. The subscription link itself functions like an access credential, so copying it into logs, screenshots, or public repositories can expose account information. Treat it like a password in day-to-day management.

A local configuration is a YAML file that you import or edit directly. It does not change automatically when you click “Update subscription,” making it suitable for self-hosted nodes, fixed rules, debugging configurations, and offline environments. Both ultimately become YAML that the core can read, but their sources, update methods, and overwrite behavior differ.

Why direct edits to subscription YAML are easily lost

Many clients let you open and edit the cached file for the current subscription, but the next update downloads the entire document again and overwrites manually added rules, DNS parameters, or policy groups. Even if the client keeps the old file, the new Profile may receive a different internal identifier, so the edits are no longer used.

For custom content that must be kept long term, use the client’s built-in override, script, or merge features whenever possible. Menu names vary by client; common paths include “Configuration” → “Override,” “Profiles” → “Merge,” or the edit menu on the right side of a configuration card. Clients using mihomo may also support overrides for DNS, rules, and TUN fields. Before enabling one, confirm the merge order: a later value with the same scalar name usually replaces the earlier value, while whether arrays are replaced or appended depends on the client.

What really happens during updates and switching

Manual and automatic updates

After you click the update button on a configuration card, the client typically follows this sequence: request the subscription URL, check the response, write a temporary file, parse the YAML, replace the old cache, and notify the core to reload. A successful HTTP request does not guarantee a usable configuration: if the server returns a login page, an error message, or incomplete YAML, the status code may still be 200 while parsing fails.

Automatic updates simply run the same process on a schedule. Common intervals are 6, 12, or 24 hours. Some clients read the update interval from the subscription response, while others use a fixed period configured under “Settings” → “Configuration” or on the “Profiles” page. Tasks usually do not run while a laptop is asleep; whether an update runs immediately after wake depends on the client’s scheduler.

1. Record the current Profile name and selected policy group before updating so you can identify changes afterward.
2. Make sure the system clock is correct. A large time discrepancy can cause HTTPS certificate verification to fail.
3. After updating, check the node count, policy group names, and last-updated time instead of looking only at “Request successful.”
4. Open the core log and confirm there are no errors involving yaml, parse, or proxy group.
5. Use a regular HTTPS page to verify a rule match, then test a destination that requires a proxy. Do not rely on latency numbers alone.

Switching Profiles means more than changing nodes

When you select another Profile from the configuration list, the client makes the core reload the entire configuration. The listening port may change from 7890 to 7897; the DNS mode may change from fake-ip to redir-host; and TUN, routing rules, and policy groups may change at the same time. If “the browser works but the terminal does not” or “the system proxy still points to the old port” after switching, check the port and traffic-capture mode first.

The system proxy is simply the proxy address configured in the operating system. For example, if a Profile uses mixed-port: 7890, the client will usually point the system HTTP and HTTPS proxies to 127.0.0.1:7890. If the new configuration changes this to 7891 but the graphical client does not refresh the system proxy, applications will continue connecting to the old port. Try turning the system proxy off and on again so the client rewrites the address.

TUN mode affects a broader range of traffic. mihomo creates a virtual network interface and captures traffic that matches the routing conditions; DNS hijacking, strict routing, and auto-route settings all come from the current configuration or client overrides. After switching Profiles, check the status under “Settings” → “Network” or “Settings” → “TUN Mode.” macOS may also ask you to reconfirm the network extension or administrator permissions.

Naming and grouping multiple Profiles

When using multiple subscriptions, the most common problem is not the number of configurations but poor naming. Names such as “Provider A,” “Backup,” or randomly generated filenames make it difficult months later to identify a configuration’s purpose, source, and update policy. Names should describe intended use, not a temporary state.

Use a four-part naming scheme

Purpose-Source-Platform-Update method

Work-ServiceA-macOS-Auto12h
Personal-ServiceB-All platforms-Manual
Test-Local rules-mihomo-Fixed
Emergency-ServiceC-iOS-Auto24h

“Purpose” distinguishes work, personal, testing, or emergency use. For “Source,” use a recognizable short name rather than the full subscription URL. “Platform” indicates whether the configuration contains system-specific rules. “Update method” shows whether the configuration changes automatically. If the client limits name length, shorten it to something like Work-A-Mac-12h, but keep the same order across all configurations.

Do not put every node into one file

Combining multiple sources into one large YAML file may seem convenient, but it creates naming conflicts, rule overrides, and update problems. Two subscriptions may both contain items named “Auto Select” or “Hong Kong Nodes”; without stable renaming rules, a merge tool may make policy groups reference the wrong nodes. Once a configuration contains hundreds of nodes, latency checks can also create a large number of connections in a short time.

A clearer approach is to keep separate Profiles and use proxy-providers when you need to select nodes across sources. mihomo providers can load nodes from multiple remote files and be referenced through use in the main configuration. The main configuration then handles rules and policies while each node source updates independently.

proxy-providers:
  provider-a:
    type: http
    url: "https://subscription.example/provider-a.yaml"
    path: ./providers/provider-a.yaml
    interval: 43200
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "Auto Select"
    type: url-test
    use:
      - provider-a
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

In the example, interval: 43200 updates the provider every 12 hours, health checks run every 600 seconds, and the policy group reevaluates latency every 300 seconds. Avoid setting intervals too short: with many nodes, a full test every 60 seconds increases connection and battery usage. On mobile devices, consider setting policy evaluation to 600–1800 seconds.

What to keep in backups and restores

The goal of a configuration backup is not to copy the entire application directory, but to preserve the materials needed to rebuild the working environment. Directory layouts and database formats vary between clients and versions, and copying application data directly into a newer version can carry over incompatible state. A more reliable approach is to keep readable YAML files together with subscription source notes and records of key settings.

Five types of data worth backing up

• Local YAML: Include the hand-written main configuration, override files, custom rules, and provider definitions.
• Subscription list: Record the service name, purpose, and update interval. Store subscription URLs in a protected password manager.
• Client settings: Record the system proxy, TUN, launch-at-login, LAN access, and port settings.
• Version information: Record the graphical client and core versions, such as client 2.0.0 and mihomo v1.19.x, to make field compatibility easier to reproduce.
• Restore notes: Document the import order, default Profile, commonly used policy groups, and any required system authorization steps.

Archive backups by date, for example clash-profile-backup-2026-07-09. Save a version before major DNS, TUN, or rule changes, and add the purpose to the filename, such as work-mac-before-tun-change.yaml. YAML works well with Git for tracking differences, but files containing subscription URLs, authentication parameters, or private server details should only be stored in private repositories with controlled access.

Do not enable every feature at once during a restore

1. Install a client version compatible with the original environment, and keep the system proxy and TUN disabled initially.
2. Import the YAML, check that the core starts, and confirm the log contains no field parsing errors.
3. Manually select a working node and test the local proxy port with 127.0.0.1:7890.
4. Enable the system proxy and test browsers and applications that follow the system proxy.
5. Enable TUN last, then check DNS, LAN access, and network behavior after sleep and wake.

Staged restoration makes it clear whether the problem lies with the Profile, a node, the system proxy, or TUN. If everything is enabled immediately after import, a network failure can produce DNS, routing, and connection errors at the same time, making the original failure difficult to identify.

Common Profile problems and how to diagnose them

The configuration updated, but the node list did not change

First confirm that you updated the currently active Profile rather than another configuration with a similar name. Then check the update time and subscription response. If the remote server definitely returned new nodes but the interface still shows the old list, switch to another Profile and back, or restart the core to trigger a reload. If nothing changes, check whether the client has a fixed override or provider cache enabled.

Parsing fails after importing YAML

YAML uses spaces for indentation and cannot rely on Tab indentation. Check the hyphens before list items, the space after colons, node names containing special characters, and duplicate fields. If the error log includes a line number, inspect the complete block above that line as well, because the actual indentation problem often occurs several lines earlier.

# Correct: proxies is an array
proxies:
  - name: "Node A"
    type: socks5

# Incorrect: list item and field levels do not match
proxies:
 - name: "Node A"
    type: socks5

All websites use direct connections after switching configurations

Check whether mode is set to direct, whether the last rule is MATCH,DIRECT, and whether the destination domain matched a direct-connection rule. The mihomo log shows the connection target, matched rule, and final policy. If the log shows no new connections at all, the problem is usually the system proxy, application proxy settings, or TUN capture rather than the rules themselves.

The policy group selection resets after every restart

The classic configuration field profile.store-selected: true lets cores that support it save policy group selections; mihomo also supports settings related to Profile persistence. However, a graphical client may manage this state itself or generate a new configuration identifier after each update. Along with enabling persistence, keep policy group names stable and avoid automatically adding dates or node counts during subscription conversion.

profile:
  store-selected: true
  store-fake-ip: true

A beginner’s management workflow: start with one configuration

When getting started, there is no need to merge multiple subscriptions or write complex rules immediately. Keep one primary subscription and confirm that updating, switching nodes, using the system proxy, and viewing logs all work normally. Use a second configuration only as an emergency fallback, with a clearly distinct name. Introduce providers or overrides only when you genuinely need to select nodes across sources.

A practical routine can be reduced to a short checklist: check the subscription update time once a week; verify the node count and policy groups after an update; copy the local YAML before changing rules; check the port and traffic-capture mode after switching Profiles; and record the core version after upgrading the client. This turns “the connection suddenly stopped working” into several verifiable steps instead of repeated deletion and re-importing.

The key to Profile management is separating three layers: subscriptions maintained remotely, rules kept locally for the long term, and runtime state recorded by the client. The subscription supplies changing nodes, the local configuration expresses stable routing intent, and client state remembers the current selection. Managing these separately makes multiple Profiles, automatic updates, and device migration much easier to control.