What Is a Clash Profile? Subscription vs. Local Configs and How to Switch

A Profile Is a Loadable Configuration

In a Clash client, a profile is usually a configuration entry that you can select, update, or edit. It contains configuration data and may also include management details such as a name, source URL, and update interval. The configuration is typically written in YAML and controls settings such as listening ports, proxies, proxy groups, routing rules, and DNS. Names and update intervals may be stored in the client’s own database rather than in the YAML file.

A profile is not a proxy node or a subscription account. One profile can contain dozens of proxies and multiple proxy groups, while a subscription link may return different content each time it is fetched. The client saves a configuration entry associated with that source; the core runs the configuration after it has been loaded, merged, or overridden.

Start by Separating Three Layers

• Configuration source: A remote subscription URL, a local file, or an editing interface provided by the client.
• Configuration data: Fields in the YAML file, such as proxies, proxy-groups, and rules.
• Runtime state: The currently selected policy, proxy mode, active connections, and system proxy setting.

Switching profiles mainly changes the configuration currently loaded; it does not necessarily reset every runtime setting. Some Clash clients remember proxy group selections, while others preserve port or TUN settings through overrides. To see what is actually in effect, check both the profile name and the running configuration—not just which entry is highlighted in the profile list.

Subscription Profiles vs. Local Profiles

Subscription profiles are fetched from a remote URL, making them suitable for receiving updates to proxies, proxy groups, or rules. Local profiles are imported from a file on your device and managed by you. Either can be a complete YAML configuration; the key difference is the source and how it is maintained, not the file extension.

A subscription link may not return a complete configuration

Some links return a complete Clash YAML file, some return only a list of proxies, and others use a different subscription format. A proxy list alone is not necessarily a complete profile. Before importing, check which format the source provides; a link containing the word “clash” does not guarantee compatibility.

Also, proxy-providers are proxy providers defined within a configuration—not the same thing as subscription profiles in a client’s profile list. A local profile can reference a remote provider, and a remote profile can include both built-in proxies and providers. In that case, updating the whole profile and refreshing provider resources are two separate actions.

YAML Fields and a Minimal Test Configuration

Understand the configuration structure before changing individual settings. Supported fields can vary by core version. Clash Meta is now called mihomo, but a mihomo-specific field should not be assumed to work with every older Clash core. The example below is only for testing YAML loading and a local listener; all traffic goes DIRECT, and no proxy nodes are included.

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

proxy-groups:
  - name: Route
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Route

• mixed-port: 7890: Exposes HTTP and SOCKS proxy endpoints on the same port. The value 7890 is used for this example; it is not a universal default.
• allow-lan: false: Blocks access from devices on your local network. If you need to share the proxy, check the listen address and firewall separately.
• mode: rule: Routes connections according to rules. The mode selected in the client UI may override this value.
• proxy-groups: Defines a selection group named Route. In this example, DIRECT is its only option.
• MATCH,Route: Acts as the final fallback rule, sending connections that did not match earlier rules to Route.

Check Syntax with the Core

Save the example as profile-test.yaml. If the mihomo command-line core is installed, run these commands from the directory containing the file:

mihomo -v
mihomo -t -f ./profile-test.yaml

The first command reports the core version; the second tests the configuration. On Windows, use .\mihomo.exe -t -f .\profile-test.yaml. The executable name depends on what you installed. A successful test only means the core accepts the configuration. It does not prove that remote proxies are reachable or that system traffic is going through the proxy.

Use spaces—not tabs—for YAML indentation. Names referenced by proxy groups must match the names of proxies or other groups. For example, if a rule is DOMAIN-SUFFIX,example.com,Route, Route must exist. If the test reports a line number, first check the indentation, colons, and list markers around that line, then investigate field compatibility.

Importing, Naming, and Setting Update Intervals

Import a Subscription Profile

1. Open the profile management page in your Clash client and choose the remote import or add subscription option. Depending on the client, this may be labeled “Config,” “Profiles,” or “Subscription.”
2. Paste the complete URL provided by the source. Keep its query parameters and do not remove the token manually. Make sure it returns a configuration format supported by your core.
3. Wait for the fetch to finish, check that proxies, proxy groups, and rules are present, then select the profile to enable it.
4. Check the logs for the load result. If the UI only says “Download successful,” make sure the configuration loads afterward without errors.

Name Profiles by Source and Purpose

Use names such as Provider-A-Daily-Remote, Provider-B-Backup-Remote, or Local-Rule-Test-20260729. The source identifies who maintains the profile, the purpose makes it clear when to switch to it, and the date identifies a test snapshot. Never put subscription tokens or passwords in a profile name, and avoid generic names like “Config 1” and “Config 2.”

Keep subscription profile names stable and let the client track when they were last updated. For local test profiles, adding a date can help. Once testing is complete, save the stable version as Local-Daily-Stable so you do not have to guess which dated copy to enable.

Check the Units for Update Intervals

For a daily subscription, try updating every 24 hours as a management guideline—not a protocol requirement. If the client expects minutes, 24 hours is 1440; if it expects seconds, it is 86400. Do not copy the same number between clients without checking their units, and do not set updates to every minute just to troubleshoot a connection problem.

If proxy-providers or rule-providers in your configuration use interval, the value is usually in seconds; confirm this in the documentation for your core version. The client’s profile update interval and a provider’s interval manage different resources, so one cannot replace the other.

Switching Profiles and Verifying Connections

Most Clash clients enable one main profile at a time. Having ten entries in the profile list does not mean all ten sets of rules are active at once. Some clients support merging, overrides, or scripts, but these are explicit configuration features; you cannot infer how profiles run by simply selecting multiple subscriptions.

Check These Four Things Before Switching

• Main profile: The current profile name and whether any local overrides are applied.
• Proxy mode: Rule, Global, or Direct—so you do not mistake a mode change for a configuration issue.
• Listening port: For example, confirm whether the mixed port is still 7890 and whether other apps use the same port.
• Traffic capture: Check the system proxy and TUN settings, along with any required system permissions.

1. Select the target profile and wait for the client to finish loading it. Do not rapidly select several profiles while it is still loading.
2. Open the proxy groups and confirm the selected options are available and suit your needs. If a previously selected proxy has disappeared, choose one that is still available.
3. Make a new request, then check its matched rule and final policy in the connection list. Do not rely on latency tests alone.
4. If something looks wrong, switch back to the last known-good profile and compare the differences one at a time.

Existing long-lived connections may continue using their old route after a switch. Browsers, download tools, and messaging apps may also reuse connections. To verify the new profile, make a new request and, if needed, close existing connections in the relevant app. Some clients offer a close-connections feature, but using it will interrupt active transfers; make sure no important downloads or sessions are in progress first.

Test the Local Proxy on a Specific Port

If the mixed port is actually 7890, use the command below to make curl use the local HTTP proxy directly, without relying on the system proxy setting:

curl --proxy http://127.0.0.1:7890 --head https://example.com

This command checks whether a request can pass through that endpoint; on its own, it does not prove that a remote proxy is being used. Check the final policy in the connection log too. If the rule matches DIRECT, the request bypasses the proxy. If the actual port is 7897, change the port in the command to 7897 as well.

TUN mode captures traffic at the system level; it is not another name for a profile. After switching profiles, DNS, routing, and rule results may change even if TUN is still enabled. It is usually easier to separate configuration issues from system permission issues by first testing the specified proxy port with TUN off, then checking TUN capture.

Managing Updates and Local Changes

Direct edits to YAML downloaded from a remote subscription may be overwritten the next time it updates. For ongoing changes to ports, rules, or DNS, use an override, merge, or extension feature explicitly provided by the Clash client whenever possible. If the client has no such feature, you can copy the configuration into a local profile, but you will then need to sync proxy updates yourself.

Assign Maintenance by Configuration Content

Rule order matters: rules are generally evaluated from top to bottom. If you add a domain rule after MATCH, it will not handle those connections as intended. When overriding a rule list, also check whether the client replaces the entire list or inserts entries at the beginning or end. Implementations differ, so do not assume one client works like another.

Before making changes, save a known-good configuration and note the client name, core version, and override contents. Change one category at a time—for example, rules first, then DNS. This makes it easier to revert a specific change if something breaks after an update, without resetting the entire client.

FAQ and Profile Management Checklist

The subscription updated successfully. Why haven’t the proxies changed?

The source may not have changed, or the proxies may come from a separate provider that needs to be updated independently. Also check that you updated the active profile, not a backup entry in the list. The update timestamp shown by the client does not prove that the proxies themselves changed.

The configuration imported successfully. Why can’t I connect?

Importing, parsing, loading, and connecting are separate stages. Check the logs to confirm the configuration loaded, make sure a valid proxy is selected in the proxy group, verify that the actual port (such as 7890) is listening, and confirm the app’s traffic is captured by the system proxy or TUN. A successful proxy latency test also does not mean every website will match the same policy.

Can I combine two subscriptions into one?

You can organize proxies using a supported configuration merge feature or a self-managed provider, but you cannot simply concatenate two YAML files. You will need to handle duplicate top-level fields, repeated proxy names, proxy group references, and rule order. If you are new to this, keeping two separate profiles and switching between them by purpose makes testing and rollback easier.

What should I copy when moving to another device?

Along with the configuration file, record the subscription source, update interval, and local overrides. After migrating, recheck the port, system proxy, and TUN permissions. Do not copy desktop paths, network interface names, or routing settings directly to a phone. Before copying any files, make sure the storage location and transfer method are suitable for account credentials.

• Keep one profile for daily use, one backup, and one for testing. Remove copies you have confirmed you no longer need.
• For remote profiles, record the source and update interval. For local profiles, record the modification date and purpose.
• After updating, check that the configuration loaded. After switching, check the rules and final policy for a new connection.
• Back up before making changes. If something goes wrong, switch back to a known-good profile first, then identify the specific difference.

Good profile management means keeping the source, configuration data, and runtime state distinct. Separate remote updates from local changes, and verify connections after switching profiles. This keeps your setup traceable and easy to roll back when proxies change, the client is upgraded, or you move to another device.