Clash Profiles Explained: Subscription URLs, Local Configs, and Switching Between Profiles

Profiles, Subscription URLs, and Runtime Configs

In Clash clients, a profile is generally a configuration that can be saved, updated, and enabled. Depending on the client, the interface may call it a “configuration,” “subscription,” or “profile.” It is not an individual proxy node or a standalone proxy protocol. For the mihomo core, the configuration that actually runs is the final content passed to it by the client, including settings for proxies, groups, rules, DNS, and listening ports.

A subscription URL points to remotely hosted content. The client fetches the content from that URL, saves it as a local configuration, then validates and loads it. The URL, the downloaded file, and the configuration currently running in the core are three distinct things. Adding a subscription entry in the interface does not mean it is enabled, and a successful download does not guarantee that the current core accepts every field in the file.

Complete configs vs. node subscriptions

Not every response labeled “subscription” can be used directly as a complete profile. A complete mihomo config can include fields such as proxies, proxy-groups, and rules; a resource containing only proxy nodes may instead be intended for proxy-providers. Node lists in other formats require an import or conversion feature supported by the client. The file extension alone does not tell you whether a file is compatible.

Where remote configs end and local YAML maintenance begins

Remote profiles: the provider maintains the main content

Remote profiles are useful for regularly receiving node changes and server-side rule updates. A typical workflow is “Profiles” → “Add” or “Import” → “URL”: paste a compatible link from the provider, download it, then select and enable the profile. Menu names vary across clients, so follow the interface in your current version. Check the profile’s source type and whether it is enabled.

Editing a downloaded copy of a remote profile directly risks losing your changes. The next update may regenerate nodes, groups, and rules, removing domain rules you added manually. For changes you need to keep, use the client’s override, merge, or scripting features when available. These are client-side capabilities, and implementations vary across mihomo clients.

Local configs: the file itself is your responsibility

Local YAML is useful for testing rules, keeping an offline copy, or setting up a fixed use case. It does not continue updating automatically just because it originally came from a subscription. If the file uses remote providers, those resources can still refresh according to their own settings; that is separate from replacing the entire local profile remotely.

Here is a direct-connection config for examining the structure. It has no remote nodes and cannot be used as a proxy service. The example listens on mixed port 7890, accepts HTTP and SOCKS clients, and routes traffic to a selectable group using rules.

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

proxies: []

proxy-groups:
  - name: Daily Egress
    type: select
    proxies:
      - DIRECT

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

• proxies stores inline nodes. The example uses an empty list, so there are no usable proxy nodes.
• proxy-groups organizes outbound options into groups. Any group referenced by a rule must exist, and its name must match exactly.
• rules are matched from top to bottom. The domain rule above is checked first; the final MATCH rule handles all remaining traffic.
• mode: rule enables rule-based routing, but does not automatically turn on the system proxy or TUN for the operating system.

Distinguish the source file from the effective config

Some clients use interface settings to override ports, DNS, or TUN, then merge those values into the profile. In that case, the source file may specify mixed-port: 7890, while the running config uses a different port from the interface. If the values do not match, check the client’s “Runtime Config,” “Effective Config,” or relevant logs instead of repeatedly editing the source file.

Subscription update intervals and provider refreshes

The client usually handles scheduled downloads of the full remote profile. Refreshing resources in proxy-providers and rule-providers, however, can be handled by mihomo using each resource’s interval. These are separate timers; updating one does not guarantee that the other changes at the same time.

Set update frequency based on the source

1. First, check the update toggle and time unit under “Profiles” → the relevant subscription → “Edit” or “Settings.”
2. If the provider has no specific requirements, 24 hours is a reasonable starting point for updating a remote profile. Adjust it to match how often nodes change. This is a management recommendation, not a core default.
3. Run an update manually, check when it completed and whether any errors appeared, then confirm that the config was reloaded.
4. Do not assume scheduled tasks keep running while the device is asleep. After reconnecting, check the last update time and refresh manually if needed.

Do not try to fix connection issues by fetching the subscription every minute. Frequent requests may trigger rate limits at the provider and will not fix incorrect credentials, DNS problems, or rules matching the wrong traffic. Updating answers “Is the config out of date?” Connection logs answer “Where did this request go?”

Update succeeded, but the nodes did not change

First, make sure you updated the currently enabled profile, not another entry with a similar name. Then check whether the nodes are inline or come from a provider: if they are in a provider, fetching the profile again may simply return the same provider definition. Also distinguish a successful file download from a successful core reload. If the client keeps running the old config, the network may still work even though the new content has not taken effect.

Using overrides alongside subscription updates

Let the provider maintain remote nodes and keep local routing preferences in the override layer. This is easier to maintain over time. For example, if work-related service domains should connect directly while other traffic continues to use the subscription’s policies, maintain only the relevant rules instead of copying the entire remote node list.

1. Check whether the client supports merge configs bound to a single profile, or whether all profiles share a global override.
2. Check where rules are inserted. A rule appended after an existing MATCH rule will never be reached.
3. Check the merge strategy: whether lists are replaced, prepended, or appended depends on the client. Do not assume YAML merging automatically combines rules.
4. After reloading, inspect the effective config to confirm the rule order and referenced group names.

For example, DOMAIN-SUFFIX,example.com,DIRECT sends the domain and its subdomains directly. To route a type of request through a group in the subscription, use a group name that actually exists there. If the provider renames a group, update the old name in your override as well; otherwise, config validation may fail.

Using multiple profiles and switching between scenarios

Saving multiple profiles does not mean they are all enabled at once. Most desktop clients load only one final config in a given core instance. Switching profiles usually reloads rules, nodes, and groups, but does not guarantee that existing connections will be migrated immediately. The exact behavior depends on the client and core.

Name profiles by purpose, not by node count

• Daily — Remote: For regular use, updated according to the provider’s policy.
• Work — Local Rules: Keeps specific requirements for internal services, along with the necessary DNS and routing settings.
• Test — Local Copy: For changing rules and testing new fields without overwriting the daily profile.

You could name a backup file daily-2026-09-09.yaml. The date makes rollback easier, but do not put subscription tokens in filenames. Record the source, update method, and override scope for each profile; these notes are more reliable than remembering “the third item in the list.”

Five checks after switching profiles

1. Confirm the active status: Select the target profile, wait for the client to finish loading, and check for configuration errors.
2. Check group selections: A group with the same name may restore its previous selection. Check carefully if persistent settings such as profile.store-selected are enabled.
3. Check listening ports: If an app is configured manually to use 127.0.0.1:7890, the new config must provide that endpoint, or you must update the app’s settings as well.
4. Check traffic handling: Verify the status of the system proxy, TUN, and DNS. Switching profiles does not necessarily switch the operating system’s network settings.
5. Test a new connection: Make the request again and check the matched rule and outbound chain in the connection log. If needed, disconnect the relevant existing connections before testing.

If your work network uses a dedicated VPN, also check for conflicts between TUN routes and internal DNS. Public internet access alone does not mean the switch succeeded; correct resolution of internal domains and access to file servers are also part of validating the profile for that scenario.

Common issues and recovery steps

YAML parsing error after import

Check that indentation uses spaces, not tabs, and that required spaces follow colons. Also inspect the beginning of the downloaded content: if it starts with <html>, a login prompt, or an expiration notice, the URL returned something other than the expected config. Do not try to fix a web error page by editing it as YAML.

Error: group or node not found

Check the references between proxy-groups, proxies, and providers. A rule’s target name must resolve to an existing outbound option. First undo the most recently added override and load the original config to find out whether the issue comes from the subscription or a local change.

Config will not load after an update, but the old one still works

Keep the old config; do not start by deleting every profile. Find the first loading-related error in the logs and note the client and mihomo core versions. The GUI version and core version are not the same. If the core does not support a new field, update to a compatible core as recommended in the maintenance notes, or restore the last working config.

Update times out or returns an access error

HTTP 401 and 403 usually mean you should check credentials, permissions, or server restrictions. 429 indicates that the request rate has been limited. For timeouts, check the network, DNS, and whether the client fetches the subscription directly or through a proxy. Do not assume update requests necessarily use the currently selected node.

If your existing nodes are no longer working and fetching the subscription depends on one of them, updates can get stuck in a dependency loop. If the client allows it, temporarily use an update method that can reach the provider, fetch the new config, then restore the previous settings. There is no need to repeatedly clear the subscription list.

Backup and routine maintenance checklist

• Keep at least one recently verified working config and its matching override content.
• Use distinct names for remote profiles and local test files to avoid overwriting manual rules during updates.
• Exported files may contain proxy passwords, subscription URLs, and controller credentials. Store them as sensitive files.
• When moving to another device, recheck port conflicts, file paths, TUN permissions, and system proxy settings; do not just copy the YAML.
• After every major change, record the active profile, group selections, and test targets so you can reproduce or roll back the setup.

Good profile management keeps the source, modifications, and runtime state separate: subscriptions provide remote content, local files or overrides preserve scenario-specific requirements, and the effective config and connection logs show what actually happened. With these three layers clearly separated, updates and profile switches can be checked with a repeatable process instead of repeated reinstalls.