Clash Profiles: How to Switch Configs, Manage Local Files, and Automate Subscription Updates

Profiles and config.yaml: The Difference Between Config Entries and Runtime Configs

A Profile is usually a config entry saved by the client. It may come from a subscription URL or an imported local YAML file. Along with the config itself, the client may store the entry name, source URL, last update time, update interval, and local processing rules. Profile is a client-side management concept, not a required top-level field in a YAML file.

config.yaml is a common config filename. The core reads the config contents and the file path specified at startup; every config file does not have to use that name. A client can store multiple Profiles, but a given core instance usually loads one final config at a time. When you select another Profile, the client generates or loads a different runtime config.

So if you edit a file but the port does not change, that does not necessarily mean the save failed. The client may be overriding mixed-port with its own setting, or it may be using a different Profile. When troubleshooting, first check which entry is selected, then inspect the final config provided by the client or its startup logs.

Local Files and Subscription Configs: Choose by Maintenance Source

Remote Profiles: Keep Subscription Updates

The content returned by a subscription URL must use a format supported by your core. Subscriptions that support Clash YAML typically include proxies, proxy groups, and rules; a subscription that provides only a proxy list cannot replace a complete config as-is. A URL is a way to retrieve config, but its response is not necessarily loadable YAML.

Remote Profiles are useful for receiving ongoing proxy updates. Adding rules directly to a downloaded copy only changes the local file; the next subscription refresh may overwrite it entirely. Some clients save edited results separately, but confirm how yours behaves by testing an update rather than relying on the filename.

Local Profiles: Fixed Copies for Independent Testing

Export a remote config as a local file, then import it as a new entry to create an independent copy. This is useful for troubleshooting rules, testing DNS, or preserving a known-good state. The tradeoff is that changes to the main subscription—such as renamed proxies, updated addresses, or new credentials—usually will not reach the local copy automatically.

For day-to-day management, keep both a remote Profile for regular use and a local copy for troubleshooting. The remote entry receives updates; enable the local copy only to investigate an issue or test a change. This keeps one config from having to serve two different maintenance needs.

Name and Switch Between Configs: Change One Variable at a Time

Include the Source, Purpose, and Date in the Name

Use filenames to identify the source, not to store subscription secrets. These examples distinguish remote entries from frozen copies. The date marks when the backup was created, not when the subscription expires.

• remote-main: Primary subscription for everyday use, with scheduled updates enabled.
• remote-backup: Backup subscription; check that it works before using it.
• local-main-2026-09-30.yaml: Local copy of the main config as of this date.
• local-dns-test-2026-09-30.yaml: Test config used only to compare DNS settings.

Six Checks Before and After Switching

Depending on the client, this section may be called “Config,” “Profiles,” or “Subscriptions.” The steps below focus on what you need to do rather than assuming menu names are the same across clients and versions.

1. Record the current state. Note the active Profile, rule mode, selected proxy, system proxy, and TUN status. These details are more useful than the filename when you need to reproduce an issue.
2. Back up the working config. Use the entry’s export or copy feature to save a YAML file, and note the core name and version.
3. Import first, then enable. Add the new file to the config list and run the client’s config check before enabling it. If it reports unknown fields, check whether the core supports them.
4. Select the target Profile. Wait for it to load, then check the logs for parse errors, missing proxy group references, or port binding failures.
5. Check the active settings. Confirm the expected rule mode is still selected, proxy groups have not switched to an unexpected default, and the system proxy port matches the runtime config.
6. Test with a new connection. Reopen the page you want to check and review the connection list for the matched rule and proxy. An existing download alone is not enough to verify the switch.

How config switches affect existing connections depends on the client and core. Old connections may continue using their previous proxy, or a reload may interrupt them. To verify the new rules, create a new request. If an important transfer is in progress, wait for it to finish before switching configs.

Automatic Subscription Updates: Separate Client and Provider Timers

The client usually manages subscription refreshes for a complete Profile. Look for update settings in the entry’s edit panel or the global subscription settings. Manually update once to confirm the config downloads and parses successfully, then enable automatic updates. This helps distinguish network issues from scheduling issues.

Check the Units When Setting an Interval

If the unit is minutes, 360 means 6 hours and 1440 means 24 hours. If the unit is hours, enter 6 or 24, respectively. These are examples of interval conversions, not defaults shared by every client. Do not copy values from screenshots of another client.

• Check whether your subscription provider specifies an update frequency to avoid making repeated requests in a short time.
• Scheduled updates may be delayed when your computer is asleep, the app is closed, or a mobile OS restricts background activity. “Every 6 hours” does not guarantee an update at the exact scheduled time.
• After a successful update, check whether the active Profile reloads automatically. Some clients only update the cached file; you may need to select it again or reload it manually.
• If an update fails, note when it happened and the error type, then check your network, subscription validity, server response, and returned content.

Do Not Confuse Provider Intervals

In Clash or Clash Meta (mihomo) cores that support these fields, HTTP-based proxy-providers and rule-providers can use interval, usually in seconds. For example, interval: 86400 updates the relevant resource every 24 hours. It controls that resource only; it does not refresh the subscription URL for the entire Profile.

Likewise, profile.store-selected saves proxy group selections; it is not a subscription scheduler. In cores that support it, profile.store-fake-ip saves Fake-IP mappings; it is not a list of multiple configs. The client’s Profile list and the YAML profile field belong to different layers.

Keep Local Rules: Overrides, Separate Resources, and Full Copies

To keep custom rules while subscriptions update automatically, use an override, merge, or scripting feature explicitly supported by your client. These features apply local changes after subscription content updates. Their names, execution order, and syntax depend on the client, so do not assume an override file can be imported as a general-purpose Clash config.

Rule Order Determines Whether a Rule Matches

rules are evaluated in order. Custom rules placed after MATCH will generally never be reached, while replacing the entire rule list may discard the subscription’s existing routing logic. Before making changes, check whether the tool prepends, appends, or replaces the rules, then inspect the final runtime config to confirm the result.

Below is a standalone, minimal local demo config for observing Profile switching, ports, and rule order. It provides only direct and reject policies, with no remote proxy nodes, so it cannot replace a subscription config.

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

proxy-groups:
  - name: LocalChoice
    type: select
    proxies:
      - DIRECT
      - REJECT

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

Once enabled, new connections to example.com and its subdomains match the direct rule first; other connections use LocalChoice. If another process on the same machine is already listening on 7890, the config may fail to bind the port. If the client overrides global ports, check the UI and logs for the actual port.

If you want to manage rules yourself and update only the proxies, you can use a fixed main config with proxy providers. This requires a compatible core, a remote response in the provider format, and proxy groups that reference the right resources. It is more complex than importing a complete subscription and is best for users who understand config references.

Backups and Rollbacks: Save the Original Config and Runtime Settings

What to Include in a Backup

• Config contents: Save working YAML files and distinguish the original subscription from the merged runtime config.
• Local overrides: Save override, merge, or script files separately, along with notes on which Profiles they apply to.
• Runtime environment: Record the client and core versions, ports, mode, and TUN status.
• Referenced resources: For offline recovery, account for the availability of external rule sets, proxy providers, and geodata.

Before any major change, save a dated snapshot and keep at least one config you know works. Do not back up only the temporary runtime file generated by the client: it may contain machine-specific paths or be regenerated on the next launch. When exporting client data, check whether the export includes local overrides and subscription URLs.

Roll Back in This Order: Config, Overrides, State

1. Temporarily turn off automatic updates for the affected entry, but keep the failing config for comparison.
2. Import a known-good local snapshot, check its syntax, then enable it.
3. Pause any newly added overrides so they do not apply the same faulty rules to the old snapshot.
4. Restore the previous rule mode, proxy group selections, and proxy handling settings, then test with a new connection.
5. Once everything is working again, add changes back one at a time. Resume automatic updates only after confirming the remote content is healthy.

FAQ: Switching Issues, Proxy Changes, and Updates Overwriting Changes

Why Didn’t the System Proxy Change When I Switched Profiles?

Switching Profiles usually changes the core config, but does not necessarily rewrite the operating system’s proxy settings. For example, if the system proxy still points to 127.0.0.1:7890 while the new config listens on 7891, apps may fail to connect. Match the system proxy port to the client’s actual listening port, and check whether the apps in question use the system proxy.

Why Does My Proxy Selection Reset After Switching?

The core or client may cache proxy selections. If a strategy group or proxy is renamed, or the selected proxy is removed from the new config, the previous selection can no longer be matched. Even with selection saving enabled, check your main proxy groups after a subscription update. A name change does not necessarily mean the proxy is unreachable.

Why Did My Custom Rules Disappear After a Successful Subscription Update?

First, check whether you edited the downloaded remote copy. If so, an update overwriting those edits is normal for a remote entry. Move changes you want to keep to a supported local override, then update manually and check the final rule order. If your client does not support overrides, use a separate local copy and maintain it manually.

Can Two Configs Be Active at the Same Time?

In a single core instance, switching Profiles selects the active config; it does not automatically combine two files. To combine proxies or rules, use an explicit merge process or provider references. Check the order of config fragments, how duplicate proxy groups are handled, and the port settings. Do not assume that selecting two files at once will merge them.

For everyday management, think in three parts: remote entries handle updates, local overrides preserve long-term changes, and dated snapshots make rollbacks possible. Change one layer at a time and verify the result with a new connection to make it easier to pinpoint issues. For fields and references, see Advanced; for the first import, see the Getting Started guide.