Clash Profiles: Manage Multiple Subscriptions and Local YAML Configs

1. How Profiles, Subscriptions, and Runtime Configs Fit Together

In Clash clients, a profile is typically a saved configuration that you can select and load into the core. It may come from a subscription URL or a local YAML file. Seeing three profile cards in a list does not mean three proxies are active at once. Most desktop clients use one selected primary profile at a time, then combine it with client settings and overrides to generate the runtime config passed to the core.

This guide uses desktop clients such as Clash Verge Rev that run the mihomo core as its reference. Depending on the client, look for a section called “Subscriptions,” “Profiles,” or “Config.” The steps below cover the relevant features regardless of their labels. The legacy Clash core and mihomo do not support exactly the same fields, so a .yaml extension alone does not guarantee compatibility.

Subscriptions can return different types of content. Some provide a complete config, while others return only proxy nodes. A full config typically includes proxies, proxy groups, and rules. Node-only data may need to be connected through a client-supported conversion method or proxy-providers; it cannot be used as a complete profile as-is. Never submit a subscription URL containing a token to an untrusted online conversion service.

2. Add Two Subscriptions, Name Them, Then Select One

When managing multiple profiles, the first challenge is telling them apart. Names like “Subscription 1” and “Subscription 2” make it hard to know which one you can edit and which one updates remotely. Keep the purpose, source label, and config type distinct. Never include access tokens, email addresses, or full subscription URLs in display names.

Create Profiles You Can Recognize

1. Open “Subscriptions” or “Profiles” in the sidebar, find the subscription URL field, paste the Clash-compatible URL from your provider, and click “Import.” Wait for the profile card to appear; a successful paste does not mean the download succeeded.
2. Open the card's context menu or More menu, then choose an option such as “Edit info.” Rename it “Daily-A-Remote.” Make sure the record still has the correct remote URL, then save.
3. Import the second subscription the same way and name it “Backup-B-Remote.” If you get a format error, first check that the response is YAML, not a login page or an expired-subscription notice.
4. Select the “Daily-A-Remote” card. Once it shows as selected, open the “Proxies” page and confirm that the proxy groups and nodes defined in this profile appear.

These names are only labels shown by the client; they do not change the proxy group name in the YAML. If a rule points to a proxy group named PROXY, changing the group name to “Daily Proxy” without updating its references may prevent the configuration from loading. When organizing profiles, change only the card name and leave internal group names as they are for now.

3. Verify These Four Things After Switching Profiles

Switching from A to B changes more than the node list. DNS, rules, proxy group names, listening ports, and TUN-related fields may also change with the profile, while global client settings may override some of them. A changed node name alone does not prove that the full config is working as expected.

1. Check the load result: After selecting B, open “Logs” and look for config parsing errors or missing proxy group references. If the new config fails to load, the core may keep using the old config or stop running, depending on how the client handles the error.
2. Check the proxy mode: On the home screen, confirm whether the current mode is Rule, Global, or Direct. Use Rule mode to test routing. Global mode sends traffic through the global policy and cannot verify that rule order is correct.
3. Check the actual egress: Open “Proxies,” select an available node in B's main proxy group, and then visit a test website. If B uses a different group name from A, your previously saved node selection may not carry over.
4. Check new connections: Open “Connections” and check which rule and proxy chain a new request matches. Long-lived connections may keep using the previous egress. Close and reopen the test website, or disconnect only the relevant test connection if needed.

Why a Port Change Can Break Your Connection After Switching

Suppose an app is manually set to use the local HTTP proxy 127.0.0.1:7890, but B changes the effective listening port to 7897. Requests from the app will fail if it keeps using the old port. These values are examples for troubleshooting, not universal defaults. Check the current port in the client's “Settings” and compare it with the proxy settings in each app.

System proxy, TUN, and profiles are separate layers. A profile provides the config the core needs to run; the system proxy affects apps that follow the system proxy settings; TUN captures traffic that matches its routing conditions. Selecting a profile does not automatically enable the system proxy or TUN.

4. Set Update Intervals: Subscription Updates vs. Health Checks

The client manages scheduled updates for remote profiles. Look for “Update interval” or “Auto update,” usually under “Edit info” on the profile card. Check the unit shown beside the field before entering a value. If it uses minutes, 720 means every 12 hours; if it uses seconds, enter 43200 for the same interval. Do not copy a value from a screenshot of another client without checking its units.

• Everyday profile: Start with one update every 24 hours; if the field uses minutes, enter 1440. Follow your provider's guidance if it specifies an update frequency.
• Backup profile: Update it regularly too, so its URL is not expired when you need it. After updating, check the node count and test a connection.
• Local profile: Without a remote source, there is no need to set a subscription fetch interval. Do not enter an arbitrary URL just to enable an auto-update button.

The client's scheduled tasks usually do not run after it exits, and you should not expect an update to happen on time while the computer is asleep. Whether the client catches up as soon as it resumes depends on its implementation. Before heading out with the backup profile, open its card menu, click “Update,” check the success time, and run a connection test.

Don't Confuse These Three Intervals

The profile update interval belongs to the client record. The interval under proxy-providers in YAML controls updates for that remote proxy resource, while health-check.interval controls how often health checks run. In these mihomo provider fields, intervals are measured in seconds. Setting a health check to 300 seconds changes the probe frequency; it does not redownload the main subscription every five minutes.

5. Local YAML: Keep a Snapshot, Not an Auto-Updating Subscription

A local profile is useful for testing rules, keeping a copy of a config from before a problem, or managing a complete config you maintain yourself. A common import flow is “Subscriptions” → “New” or “Import file.” Choose the local YAML file and save it as “Test-Rules-Local.” Some clients copy the file into their own data directory instead of continuing to read the original. Editing the original file externally after import may not change the card's contents.

How to Create a Local Copy

1. In the remote profile's menu, look for “Edit file” or “Open file” and copy the downloaded base config. You can also use the client's export feature.
2. Save the copy in a protected local folder, then use the file import feature to create a new card. Do not overwrite the original remote profile.
3. Change one item at a time. Save, select the local card, and check the logs. Once it works, move on to the next change.
4. Keep the remote profile as a fallback. If an experiment fails, switch back to it and check the proxy mode, proxy group selection, and new connection records.

The snippet below shows how to identify fields; it is not a complete proxy config you can use to replace a subscription. Its final rule sends all remaining requests directly, and it does not define any proxy nodes. Understand this behavior before testing rules; do not treat the snippet as a way to fix connectivity.

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

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

YAML uses spaces for indentation, not tabs; keep fields at the same level consistently indented. When editing an existing file, do not add a second top-level rules or dns key. Duplicate keys may be rejected or cause content to be overwritten. Before saving, use the client's config validation feature if available.

Credentials for nodes in a local copy can still expire; making a copy once does not eliminate the need for future updates. If you want nodes to keep updating automatically while preserving your personal rules, use overrides or a provider-based setup instead of relying on a frozen subscription copy.

6. Keep Overrides When Subscriptions Update: Separate Source Config from Your Changes

If you edit YAML downloaded from a remote subscription, the next update may replace your changes. A safer setup keeps the provider's content in the remote profile and stores your rules in the client's override, merge, or script config. Whenever the client generates the runtime config, it applies those changes according to its own processing order.

In clients that support this feature, look for “Global extension config” or “Global extension script” on the Subscriptions page, or “Extension config” in an individual card's menu. Names and scope vary by version: a global setting may affect every profile, while a profile-specific extension is usually tied to one record. Test its scope with a copy before using it in your everyday config.

Check Merge Behavior Before Adding Routing Rules

• Map entries: When changing a DNS subfield, check whether the client merges recursively or replaces the entire section, so you don't lose existing DNS settings.
• List entries: rules, proxies, and proxy-groups are lists. A plain YAML snippet does not automatically mean “append”; the client determines how it is handled.
• Rule order: Clash checks rules in order. Custom rules usually need to go before the fallback MATCH rule. Adding them after MATCH generally means they will never be reached.
• Policy references: A global override may fail after switching to B if it refers to a proxy group that exists only in A. Before reusing it across profiles, standardize the group names or bind separate extensions to each profile.

For example, to send example.com and its subdomains directly, the rule can be written as DOMAIN-SUFFIX,example.com,DIRECT. This only describes the rule syntax. Use the “prepend rules” feature explicitly supported by your client, or insert the rule through its extension script API. Do not assume every client supports the same prepend-rules field.

Verify Persistence with an Update

1. Save the override and apply the config. Search the final runtime config for the target domain and confirm that it appears only as expected and comes before the fallback rule.
2. Send a new request to the domain, then check “Connections” to see whether it matches the intended rule and the DIRECT policy.
3. Manually update the remote profile, wait for the config to reload, then repeat the first two checks.
4. Switch to the backup profile and confirm the global override does not reference a missing proxy group. If it does, change it to a profile-specific extension.

The config is persistent only when all three checks pass: it remains after an update, requests actually match the rule, and switching profiles causes no errors. If your personal rules do not appear in the base subscription file, they may still be present in the final runtime config through an override.

7. Back Up and Restore: Keep the Essentials Needed to Re-enable Your Setup

A backup should include more than a screenshot of the Proxies page. Keep profile display names, remote URLs, personal overrides, any necessary local YAML, and notes on the current port and mode. If you use proxy-providers, rule-providers, or relative file paths, make sure the required resources can be fetched again or keep the corresponding files too.

Subscription URLs and config files may contain credentials that grant direct access. Do not store them in public code repositories. Before sharing troubleshooting details, remove subscription tokens, node passwords, and private keys; also obscure full URLs in screenshots. After moving to a new device, first import a known-working profile and confirm a connection. Then restore your overrides and enable scheduled updates last, making it easier to pinpoint problems at each step.

For more on importing subscriptions and how rules relate to TUN, read the Clash Configuration Guide. For the recommended steps after installation, see the setup guide.