What Is a Clash Profile? Structure Explained and Multi-Profile Switching

A Profile is not a subscription URL—it is the runtime configuration the core actually reads

In Clash, Clash Meta, or mihomo clients, Profile is commonly referred to as a configuration or config file. Ultimately, it is a YAML document containing more than just proxy nodes: it can define listening ports, DNS, proxy groups, routing rules, TUN settings, and the control interface. When the core starts, it reads this configuration—not the subscription URL in your browser.

A subscription URL is better understood as a configuration source. The client requests the URL, downloads the server response, and saves the result as a local Profile. Even when temporarily offline, the client can usually still load that configuration as long as the local file remains available and the node credentials are valid. When you click “Update subscription,” the client downloads the content again and overwrites or rebuilds the corresponding local data.

What a complete configuration usually contains

The minimum runnable structure varies by core version and client wrapper, but common fields usually fall into six layers:

• port, socks-port, mixed-port: local proxy listening ports.
• proxies or proxy-providers: individual nodes or remote node collections.
• proxy-groups: policy groups for manual selection, automatic latency tests, failover, and more.
• rules or rule-providers: the matching order for domains, IPs, processes, and rule sets.
• dns: DNS listeners, upstream servers, and Fake-IP or Redir-Host behavior.
• tun, sniffer, external-controller: system traffic interception, domain sniffing, and the control interface.

Here is a compact example for understanding the hierarchy. Port 7890 serves as a combined HTTP and SOCKS entry point, while 9090 is used for the external control interface. Real credentials are omitted, so this example should not be used directly as a connectable configuration.

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

proxies:
  - name: Tokyo-A
    type: ss
    server: 203.0.113.10
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - Tokyo-A
      - DIRECT

  - name: AUTO
    type: url-test
    proxies:
      - Tokyo-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

The three core sections: proxies, proxy-groups, and rules

To understand a Profile, do not start with hundreds of lines of DNS settings and rule sets. Focus on three core sections: proxies provides exits, proxy-groups organizes those exits, and rules decides which group receives each connection. Together, they form a reference chain from the underlying nodes to the routing logic.

proxies: node definitions and connection parameters

proxies is a static array of nodes. Each item includes at least a name, protocol, server address, port, and authentication details. Different protocols add their own fields—for example, Shadowsocks encryption settings, Trojan passwords and TLS parameters, VMess UUIDs, and VLESS flow-control and transport settings.

Node names must be identifiable within the current configuration. Proxy groups reference nodes by name, so rename checks should always include proxy-groups. If a group still contains the old name, validation may fail outright, or the client may show an empty group or an unavailable member.

proxies:
  - name: HK-01
    type: trojan
    server: hk01.example.net
    port: 443
    password: change-me
    sni: hk01.example.net
    udp: true

Large subscriptions usually do not list every node manually in the main file. Instead, they use proxy-providers. A Provider can fetch a node collection remotely and refresh it on a schedule. It only defines the node source; it does not decide which sites those nodes should handle.

proxy-groups: turning nodes into actionable policies

proxy-groups are the objects users actually operate on in the client’s “Proxies” page. Four common types are:

A group can reference nodes or another group. A common pattern is to create a top-level PROXY group containing HK-AUTO, JP-AUTO, Fallback, and DIRECT. Rules then reference the top-level or business-specific group, so updating the underlying nodes does not require editing rules one by one.

proxy-groups:
  - name: Streaming
    type: select
    proxies:
      - HK-AUTO
      - JP-AUTO
      - PROXY

  - name: HK-AUTO
    type: url-test
    use:
      - provider-main
    filter: "(?i)港|HK|Hong Kong"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100

rules: evaluated top to bottom, stopping at the first match

rules is an ordered list of match conditions. Requests are checked from the first rule onward; once a rule matches, the connection is sent to its designated policy and evaluation stops. Put specific rules before broad ones, and use MATCH as the final fallback.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - PROCESS-NAME,git.exe,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Fallback

In this section, api.example.com connects directly. Other example.com subdomains use the proxy. Connections created by git.exe on Windows and recognized by the core go to PROXY. Local network addresses connect directly, remaining mainland China IPs connect directly, and unmatched traffic finally goes to Fallback.

Profile and subscription updates: what gets overwritten

Editing the YAML generated by a subscription may work briefly, but your changes can disappear at the next update. The reason is straightforward: the client treats the remote response as the authoritative version of that Profile and rewrites its nodes, policy groups, and rules during an update. Manually added PROCESS-NAME rules, DNS upstreams, or custom groups are replaced unless they are handled by a separate override mechanism.

How three configuration sources behave differently

1. Import from a local file: Loads YAML from disk and usually does not contact a remote source automatically. Best for configurations you maintain yourself.
2. Import from a subscription URL: Requests the remote source on the interval set by the client. A common refresh interval is 24 hours, and updates can also be triggered manually.
3. Provider-based setup: Keeps DNS, groups, and rules in the main config while proxy-providers refreshes the nodes. Best for users who need to maintain the rule structure over time.

In common graphical clients, the import path is usually “Profiles” → “New” → “Import from URL,” while the update action appears on the corresponding profile card as an “Update” button. Ports are often adjusted under “Settings” → “Parameters” → “Mixed port.” Different clients may call a Profile a “config,” “subscription,” or “profile manager,” and button locations may differ, but the underlying relationship remains the same.

mihomo’s Provider structure can cache remote nodes in a local file. In the example below, interval: 86400 means checking every 86,400 seconds, or 24 hours. Health checks run every 600 seconds:

proxy-providers:
  provider-main:
    type: http
    url: https://subscription.example.net/clash
    path: ./providers/provider-main.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

If the client supports overrides, extension scripts, or Merge configs, put local DNS settings, rules, and policy groups in the override layer whenever possible. Let the remote source handle nodes and keep personal logic local. That way, refreshing 80 nodes will not also wipe out a direct-connection rule created for your development environment.

Naming and keeping multiple provider and use-case configs

As the number of configurations grows, naming usually becomes the first thing to get out of control—not the YAML itself. Once the list contains “New config,” “Subscription 2,” and “Test copy final,” it becomes difficult to tell which one is active and which can be deleted. Names should clearly express the source, purpose, and last structural update.

Recommended naming format

[source]-[purpose]-[update method]-[date]

Provider-A-daily-auto-20260625
Provider-B-streaming-auto-20260625
Local-dev-routing-manual-20260625
Emergency-basic-direct-manual-20260625

The date does not need to change every time the nodes refresh. It is more useful for recording when the configuration structure was last edited manually. Let the client track automatic subscription updates; renaming the profile every day only creates noise.

Split by source or by purpose?

When you are getting started, keeping one Profile per source is the simplest approach. Once your routing needs stabilize, migrate to “one main config with multiple Providers.” Avoid putting every source, dozens of business groups, and thousands of rules into one file from day one; a single indentation error can greatly expand the troubleshooting scope.

Keep an emergency configuration

An emergency config does not need to be complex. Keep one working node, one select group, and a few basic rules, while disabling nonessential TUN and complex DNS features. If the main config update fails, a rule-set URL becomes unreachable, or the TUN driver malfunctions, switch to the emergency config to restore basic connectivity before troubleshooting.

The emergency config should use local YAML and should not depend on downloading remote rule sets at every startup. Load it manually once a month to confirm that it passes validation, the node is still reachable, and port 7890 is not occupied by another program.

What happens inside the client when switching Profiles

Switching Profiles is not simply replacing a node list. The client typically stops or reloads the current core, passes the new YAML through validation, and then recreates listening ports, DNS, the TUN adapter, and policy state. The more complex the configuration, the more system components are involved in the reload.

Existing connections may not migrate automatically

TCP connections established before the switch may close or remain active until they time out, depending on how the client reloads the core. New connections follow the new rules. Avoid switching Profiles while downloading a large file, pushing with Git, or maintaining an SSH session.

A reproducible switching check can look like this: first confirm the number of active connections in the connection panel—for example, 23; stop download tasks; switch the config; wait until the core status returns to “Running”; then open a test domain and check which rule handled the new connection. In common desktop environments, a simple config may reload in 1–3 seconds. Enabling TUN, remote rule sets, and many Providers can take longer.

Policy selections may be remembered—or reset

Some clients save the last selection by policy-group name. For example, if two Profiles both contain a group named PROXY, the client may try to restore the previously selected node after switching. If the new configuration has no node with that name, it falls back to the first available member of the group.

When multiple configurations share the same policy semantics, use consistent group names such as PROXY, Streaming, and Fallback. Do not force different meanings into the same name; the interface may appear to preserve the selection while the actual exit logic has changed.

TUN switches require extra checks

TUN mode takes over more system traffic. If two Profiles use different stack values, DNS hijacking settings, or route exclusions, switching may require rebuilding the virtual adapter and routing table. After switching, check:

• Whether TUN has been enabled again rather than leaving only the system proxy active.
• Whether local network addresses such as 192.168.1.1 still connect directly.
• Whether DNS requests are sent to the new configuration’s listening port, such as 0.0.0.0:1053.
• Whether excluded processes or network ranges are still listed in route-exclude-address.
• Whether browsers, command-line tools, and applications that ignore the system proxy are routed as expected.

A practical Profile management workflow

Managing Profiles does not require complex tools. The key is to separate importing, validation, switching, and rollback instead of experimenting directly on the only configuration that currently works.

Step 1: copy before editing

Before changing DNS, TUN, or rules, copy the current configuration and add the date. Leave the original untouched. If the client has no copy function, export the YAML to a separate directory. Name the modified version “Test,” and replace the main config only after validation is complete.

Step 2: validate the syntax first

YAML uses spaces to express hierarchy, so tabs, misaligned indentation, and missing quotes can all prevent loading. Pay particular attention to names containing colons, regular expressions, and URLs. If the core error reports a line number, inspect the list indentation above that line first: the reported location is often where the parser could no longer continue, not necessarily where the problem began.

# Error-prone: group name contains a colon without quotes
- name: Work: Git

# Safer
- name: "Work: Git"

Step 3: verify routing with fixed test cases

Prepare four fixed test cases: one mainland China domain, one domain that requires a proxy, one local network address, and one specified process. Open the client’s connection log and verify the rule type, matched policy, and final node for each. Do not rely only on checking an IP in a browser; browser caching, HTTP/3, and existing connections can all distort the result.

1. The mainland China domain should match DIRECT or the expected mainland China policy.
2. The proxied domain should match its business group rather than falling through to the final MATCH.
3. Private ranges such as 192.168.0.0/16 should remain direct.
4. The process rule should appear after the specified program creates a new connection.
5. The DNS log should not show persistent timeouts or query loops.

Step 4: record a rollback point

Record the stable configuration’s filename, mixed port, TUN setting, and main policy selection. If the test configuration fails, switch back via “Profiles” → “Stable config,” then go to “Settings” → “Parameters” and confirm that ports such as 7890 have been restored. If the core does not restart automatically, manually click “Stop” and then “Start” once.

Common issue: import succeeds but the config does not work

The config is listed, but proxy groups are empty

First check whether proxies contains nodes or whether proxy-providers downloaded successfully. Then verify that the proxies names in the group exactly match the Provider’s use names. Names are case-sensitive, and even an extra space can break the reference.

Custom rules disappear after an update

This is the typical result of editing a subscription-generated config directly. Move custom content to the client’s override layer, or create a local main config and import remote nodes through a Provider. If the client does not support overrides, keep a local copy and merge changes manually instead of treating the subscription cache as a long-term editing source.

The browser still uses the old node after switching configs

Open a new private window or fully restart the browser to rule out connection reuse. Then check whether the connection panel shows a new connection. If the new connection still uses the old node, check whether a same-named policy group restored a previous selection and whether the rules actually reference another group. With TUN enabled, also confirm that the virtual adapter reloaded with the new configuration.

A rule was added but always matches MATCH

Check the rule order, domain type, and DNS behavior. DOMAIN matches only the complete domain, while DOMAIN-SUFFIX also covers subdomains. IP rules require the connection target to resolve to the relevant IP; with no-resolve, the client will not actively trigger DNS for matching. Process rules also depend on whether the platform and core can obtain process information.

Conclusion: treat Profiles as versioned runtime configurations

The essence of a Profile is not how many nodes it contains, but how it organizes entry points, exits, policies, and match order into a configuration the core can execute. proxies provides exits, proxy-groups combines policies, and rules assigns connections; DNS and TUN determine how domains and system traffic enter this chain.

When keeping multiple Profiles, use readable names, distinguish automatic subscriptions from local configurations, and retain an emergency Profile. After updates, check nodes, policy groups, and rule matches. Before switching, stop critical connections; afterward, verify ports, DNS, and TUN. This makes it possible to quickly return to a working state even when a subscription changes or a rule breaks.