Clash Profiles Explained: Subscription Configs, Local YAML, and Managing Multiple Profiles

What Is a Profile? A Selectable Configuration Entry

A profile is an entry the client uses to manage a configuration—not an individual proxy node. It typically stores the configuration, display name, source URL, and last update time. Depending on the client, you may find it under “Config,” “Profiles,” or “Configuration.” Select an entry and the client passes its contents to the core to load.

The core is the program that handles connections. Clash and Clash Meta (now called mihomo) operate at this layer; desktop windows, subscription lists, and update buttons belong to the client interface. Profile management differs across clients, so this guide explains the purpose of each operation rather than treating one interface's button layout as universal.

YAML is a text format that uses indentation to represent structure. A complete config usually includes ports, proxy nodes, proxy groups, and rules—but a subscription URL may return something less complete. Some URLs provide only a list of nodes, some return Base64-encoded data, and others provide a complete Clash YAML config. A file extension that looks like a config does not guarantee the contents are ready to use.

Identify the source first: subscription or local config

Subscription config: fetch remote content again when you update

Subscription profiles are useful when a provider manages your nodes and baseline rules. The client stores the source URL and contacts the server when you update. When the remote content changes, the local cache is usually replaced; whether the client keeps an older copy or merges settings depends on its implementation.

• Benefit: Refresh to get added or removed nodes and updated connection settings without editing each entry yourself.
• Watch out: Changes made directly to a downloaded config may be lost on the next update.
• Check: Does the entry show its source URL and last update time? Did the latest update succeed?

Local config: maintain the file yourself

Local configs are useful for learning how rules work, keeping a fixed setup, or troubleshooting against a known baseline. After import, some clients copy the file while others read it from a specified path. Don't assume edits to the original file take effect immediately: reload it and confirm which copy the client is actually using.

A local config can also contain proxy-providers, which fetches nodes from a remote source. So a “local profile” isn't necessarily free of remote updates. Updating the full config, refreshing proxy providers, and updating rule-providers are three separate things.

Import your first config: check the format, then confirm it's active

Successfully imported doesn't mean it's in use. A new entry in the list only confirms that the client created a profile. You still need to check whether it passes syntax validation, is active, and is sending traffic through the core.

1. Open the client's “Config” or “Profiles” page and choose the remote import or import-from-URL option. Paste a subscription URL that the provider explicitly identifies as compatible with Clash or mihomo.
2. Name the new entry Everyday-Subscription-A. Don't delete your existing working config yet. A name that describes its purpose is easier to recognize than “New Config.”
3. Run an update and check the result. If you see a format error, check whether the response is actually a login page, an expiration notice, or subscription data in another format.
4. Select the entry and choose Enable or Switch. Check the logs for load failures or references to missing proxy groups.
5. Open the “Proxies” page and check that the proxy groups are listed. Then confirm the mode is Rule. Finally, visit a site whose expected route you know and check the connection log.

To import a local config, choose the file import option and select a .yaml or .yml file, then repeat the activation and verification steps. Clients may call this “Import,” “New,” or “Add.” If you can't find the option, start with the basic workflow in the user guide.

Create a local baseline config: separate syntax issues from network issues

A simple local config helps you check whether the client can load YAML correctly. This example is for mihomo and demonstrates config structure and proxy-group references only. It includes no remote proxy nodes and provides no proxy exit.

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

proxies: []

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

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

• mixed-port: 7890 defines a local proxy port that accepts both HTTP and SOCKS requests. This is an example value; not every client uses port 7890.
• allow-lan: false prevents devices on your local network from accessing this proxy listener, making it suitable for an initial check on your own device.
• Manual Select is the proxy group name. The last field in the rule must match it exactly.
• DIRECT means connect directly; REJECT means deny the connection. Both are built-in outbound options, not remote proxy nodes.
• MATCH,DIRECT is the fallback rule: if none of the preceding rules match, the connection goes direct.

Save the file as local-baseline.yaml, then import it and name it Troubleshooting-Local-Direct. Even if it loads successfully, that only proves the basic structure is accepted; it doesn't prove subscription nodes work. If the client has global overrides enabled, the actual port and mode may also differ from the file.

Use spaces for YAML indentation, not tabs. For details on individual fields, refer to the YAML manual. Don't apply fields intended for mihomo to every older Clash core: unknown fields may cause errors or be ignored.

Name and switch between profiles: keep their purpose clear and verify in a consistent order

Most clients activate only one main profile at a time. Having three profiles in the list doesn't mean their subscriptions are merged or that traffic is distributed across all three. Combining multiple sources in one config usually requires providers or a merge feature supported by the client.

Check these four things after every switch

1. Active profile: Confirm the selected indicator has moved to the intended profile, rather than merely opening its editor.
2. Operating mode: Rule routes traffic according to rules; Global uses the global policy; Direct bypasses the proxy. The mode saved in the client may override mode in the file.
3. Proxy group selection: Open the group actually referenced by your rules and check the current selection. If group names change in the new config, saved selections may not carry over.
4. New connection logs: Start a fresh request and check the matched rule, proxy group, and final outbound. Existing browser connections may keep using the previous route for a while after a switch.

If the behavior doesn't change right away, close and reopen the test page. If needed, close only the relevant old connections. Don't start by reinstalling the client, clearing all configs, and changing DNS at once; too many changes make it hard to identify the cause.

Scheduled updates and custom rules: know which layer keeps your changes

An update interval is a management choice—not something to set as low as possible. For a regular subscription, you could start with a 24-hour refresh interval and adjust it if the provider specifies otherwise. If the field uses minutes, 24 hours is 1440 minutes; if it uses seconds, it's 86400 seconds. Check the unit before saving.

Scheduled updates are usually handled by the client and may not run while your computer is asleep or the app is closed. The interval field in proxy-providers belongs to the core's provider settings and is usually measured in seconds; it doesn't replace the client's full-profile update schedule.

Keep long-term rules in a separate customization layer

• If your client supports overrides, merging, or scripts, read its documentation first, then put custom content in a separate layer. Merge order varies between clients.
• If the client only lets you edit the original file, export a copy before making changes and expect to maintain it manually going forward.
• Rule order matters. Rules are commonly checked from top to bottom, so appending a new rule after MATCH usually won't produce the result you expect.
• After an update, check the final active config—not just the original subscription file. The client may apply another layer of overrides for ports, DNS, or TUN.

Rules behaving unexpectedly after a switch: troubleshoot by symptom instead of changing nodes at random

Proxy groups are missing or rules point to a group that doesn't exist

Start with the load logs. For example, if a rule references Everyday Proxy but the new config defines only Manual Select, the reference won't match. Check spelling, capitalization, and spaces, then see whether an override still references a group from the previous config. Update your custom rules whenever a group name changes.

The switch worked, but only some apps use the proxy

First check whether traffic is reaching the core. The system proxy is an operating-system setting, and not every app follows it. TUN mode captures traffic through a virtual network interface and also requires the right permissions, routes, and DNS settings. Switching profiles won't automatically fix problems with these traffic entry points.

If an app still points to 127.0.0.1:7890 but the active listener has moved to 7897, it may be connecting to the old port or failing outright. These numbers are troubleshooting examples only; use the listener port shown by your client. Also check whether the system proxy updates when you switch profiles.

The page loads, but traffic takes a different route than expected

First check whether the connection log captured the domain, then see which rule matched. App-specific DNS, encrypted DNS, direct IP connections, and reused connections can all affect what you observe. Don't judge the entire config by the exit IP shown by a single site; check a known domain, a new connection, and the corresponding logs together.

The config stopped working after an update, but the old one still works

Keep the error details, restore the most recent working copy, then compare changes to nodes, group names, and rules. If the subscription response looks wrong, ask the provider to confirm its format and expiration status. Repeatedly clicking Update just sends the same request again; it won't fix bad remote content. For other connection issues, work through the FAQ.

Back up and roll back: keep at least one verified config

A backup needs to preserve both the config and its usage state. Saving only the subscription URL won't restore the rules you had at the time; saving only the YAML may omit the client's mode, TUN toggle, and override settings.

1. Before major changes, export your current working config. A filename like daily-before-edit-2026-08-03.yaml makes it easy to identify by date.
2. Record the core type, actual listening port, mode, selected proxy groups, and active overrides. Hide subscription URLs and proxy credentials in screenshots.
3. Test changes in a new profile. Once it loads correctly and the rules behave as expected, decide whether to replace your everyday profile.
4. To roll back, select the backup profile, restore the corresponding client settings, and verify with a new connection. Don't treat a successful file import as a complete restore.

Everyday profile management can stay simple: one daily subscription, one backup, and one local troubleshooting config. Identify each source, use consistent names, and follow the same checks after every switch. That makes it easier to tell whether a problem comes from the config, the update process, or traffic entry points such as the system proxy or TUN.