What Is a Clash Profile? Subscriptions, Local YAML, and Managing Multiple Configs

A Profile Is a Config Entry, Not a Single Proxy Node

In a Clash client, a Profile usually means a selectable, loadable configuration entry. It may come from a subscription URL or a YAML file on disk. Clients often store a name, source URL, last-updated time, and update policy alongside each entry; this management data may not be part of the YAML loaded by the core.

A complete config can include listening ports, DNS, proxy nodes, proxy groups, and routing rules. Nodes are only one part of it. After importing a config, you must also activate it in the client before the core applies its settings to new connections. A subscription being added, a config being active, and the system proxy being enabled are three separate states.

Three Actions That Are Easy to Confuse

• Update a subscription: Fetches content again from its original URL; it does not necessarily switch to that config.
• Switch Profiles: Changes the active config source, which may also change proxy groups, rules, and DNS settings.
• Switch proxy nodes: Changes the selected node in a proxy group within the active config; it usually does not replace the entire config.

Menu labels vary by client. Common sections include “Subscriptions,” “Config,” and “Profiles.” This article uses Profile to mean a configuration entry rather than treating one client’s button label as a universal menu name.

Remote Subscriptions, Local YAML, and Proxy Providers

A remote subscription is a way to fetch data; YAML is a data format. They are not mutually exclusive: a remote subscription can return YAML. When you import a local file, the client usually saves its own copy. Editing the original downloaded file may not update that copy, so check whether the client imports a copy or references the file directly.

A subscription URL is not necessarily readable by the Clash core. A list of node URIs, an HTML page, a login screen, or an error message is not a complete Clash config. Before importing, choose a Clash- or mihomo-compatible format explicitly provided by the subscription source, and check which core your client uses.

proxy-providers Is Not a Separate, Complete Profile

In cores that support this feature, proxy-providers in the main config defines node sources, and proxy-groups can reference providers with use. Refreshing provider nodes does not replace the main config’s DNS, rules, or ports. rule-providers loads rule sets; it is not the same as a node provider.

First Import: Check the Format, Then Activate the Config

1. Choose a client for your operating system on the downloads page. Note the client and core versions; you may need both when troubleshooting config compatibility.
2. Open the config manager, then add a remote subscription URL or import a local .yaml or .yml file. Paste the full remote URL without spaces, line breaks, or punctuation added by a messaging app.
3. Give each entry a clear name, such as “Daily - Remote,” “Work - Local,” or “Test - DNS.” The name is for organization; it does not automatically create a proxy group with the same name.
4. Update the config and check the result. If parsing fails, first verify the returned content and format. Toggling the system proxy repeatedly will not fix a syntax error.
5. Select and activate the config. Check that its proxy groups and rules have loaded before deciding whether to enable the system proxy or TUN.

The system proxy routes traffic from apps that honor the system proxy settings through a local proxy port. TUN uses a virtual network interface to capture traffic that matches its routing rules. Neither is required to import a config, and neither will fix node authentication errors. TUN support also depends on the core, operating system permissions, and routing settings.

Use the port shown in your client. The example below uses 7890 as the mixed proxy port; this is only an example value and does not mean every client listens on 127.0.0.1:7890.

Local YAML Example: Understanding Config Boundaries

The local config below illustrates how the fields fit together and can be used to check basic structure in a mihomo environment. It only provides a direct connection and does not offer remote proxy access. Save it as local-direct.yaml, import it, and examine how ports, proxy groups, and rules relate to one another.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: Manual Select
    type: select
    proxies:
      - DIRECT

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

• mixed-port is the shared listening port for HTTP and SOCKS proxies. If another process is using it, choose an available port.
• allow-lan: false prevents devices on your local network from accessing the proxy; it is separate from the TUN setting.
• mode: rule enables rule-based routing. The final MATCH,DIRECT rule handles requests that did not match any earlier rule.
• The Manual Select group contains only DIRECT, so traffic routed to it still connects directly. The group name must match wherever a rule references it.

YAML indentation uses spaces; do not mix in tabs. Boolean values such as false must be distinguished from strings, and list items need their -. If parsing fails, check the line named in the log and the line above it. Common causes include incorrect indentation, a missing colon, or an unclosed quote.

Successful parsing does not guarantee a working connection. After the syntax check passes, verify that nodes are present, proxy group references are valid, and rules route traffic through the intended outbound. Clash, Clash Premium, and Clash Meta (now called mihomo) support different features, so a file extension alone cannot confirm compatibility.

Update Intervals: Subscription Refresh vs. Node Health Checks

Automatic updates for remote Profiles are generally managed by the client. HTTP proxy providers in the main config can use interval to set a refresh period; in the relevant mihomo field, the value is in seconds. These settings operate at different levels, so setting one does not automatically manage the other.

Seconds-to-Hours Conversion

• 3600 seconds equals 1 hour.
• 21600 seconds equals 6 hours.
• 86400 seconds equals 24 hours.

These conversions apply to fields measured in seconds. A client’s interface may ask for minutes or offer hour-based options instead, so follow the label next to the input. For everyday use, start with the interval recommended by your subscription provider. If there is no recommendation, try once a day and adjust based on how often the nodes change.

A node health check tests connectivity and latency to a specified address; it does not download a new node list. If nodes appear to be down, distinguish between a failed health check and a failed subscription fetch. For health checks, look at the outbound, test address, and timeout. For subscription fetches, check the URL, network path, access permissions, and response format.

Config Overrides: Keep Personal Settings Separate from Remote Content

Editing YAML downloaded from a remote subscription can lead to your changes being overwritten on the next refresh. For personal rules, DNS, or port settings you need to keep, use the client’s override, merge, or scripting features where available. Support varies by client; the Clash core itself does not recognize every client-specific override file format.

Check the Final Active Config First

A useful way to think about loading is “subscription config → client merges and overrides → config loaded by the core.” This is a troubleshooting model, not a fixed sequence used by every client. Some clients override config ports with interface settings; others distinguish between global overrides and per-Profile overrides. Check the final running config rather than only the original subscription content.

1. Change one thing at a time: For example, add just one domain rule for direct access instead of changing DNS, TUN, and every proxy group at once.
2. Check how lists are merged: Lists may be replaced, prepended, or appended. Rules are matched in order, so appending a new rule after the fallback MATCH usually will not produce the intended result.
3. Verify referenced names: Any proxy group named in a custom rule must exist in the merged config.
4. Check again after refreshing: Manually update the subscription, then confirm the new rule is still present and in the right order.

Take extra care when sharing overrides across multiple Profiles. Config A may have a “Manual Select” group while Config B does not. A shared rule that depends on that name can become invalid after switching. You can standardize group names in configs you maintain or create a separate override for each Profile, rather than forcing unrelated configs through the same modification script.

Managing Multiple Profiles: One Active, Others on File

A typical single-instance client uses one main Profile at a time, with any supported overrides layered on top. Adding three subscriptions does not automatically merge their rules or put all their nodes in one proxy group. If you need to combine nodes, design a main config and proxy providers explicitly instead of relying on the order of entries in the config list.

Keep Three Clearly Labeled Profiles

• Daily config: Use a reliable source, enable automatic updates, and make it your default.
• Backup config: Verify its source and access path separately, and update it manually on a regular schedule so it is not out of date when you need it.
• Test config: Use it to test DNS, rules, or TUN settings. Disable unnecessary automatic updates to make before-and-after comparisons easier.

Before switching, note the current Profile name, mode, proxy group selection, and ports. After switching, check whether the new config still uses rule mode and whether DNS, LAN access, and TUN settings have changed. A client may retain some global toggles, so switching Profiles does not always reset every setting.

Existing connections may not switch to a new outbound immediately; this depends on how the client reloads and whether those connections are closed. Test with a new request. If needed, close old connections in the client or restart the target app. Do not judge whether the switch worked based only on a download that was already in progress.

Back Up and Restore: Save Sources, Overrides, and Runtime Settings

Backing up only the YAML is often not enough to restore a client completely. Remote URLs, update intervals, override files, and global interface settings may be stored separately in the client database or config directory. Before migrating, use the client’s export feature where available and check whether the export contains sensitive information.

1. Save the source details: Record where the subscription is managed, its Profile name, and its update interval. Store token-bearing URLs somewhere secure.
2. Save local files: Back up local YAML, override scripts, and rule files you maintain. If a config uses relative paths, preserve the directory structure too.
3. Record runtime settings: Note the client and core versions, actual listening ports, system proxy status, and TUN settings.
4. Test a restore: Import the config, load the overrides, check the logs for parsing or reference errors, and then test a new connection.

Use filenames such as daily-2026-08-27.yaml and override-2026-08-27.yaml to make the source and date easy to identify. A backup does not make cached data a permanently valid subscription: node credentials can expire, so after restoring, fetch the remote source again and verify the connection.

FAQ: Update, Switching, and Restore Issues

The key to managing multiple Profiles is to keep four things straight: where each config comes from, where personal changes are saved, which Profile is active, and what the core ultimately loads. Checking these four points usually helps pinpoint the cause of overwritten changes, switching issues, or lost settings during migration.