What Is a Clash Profile?

A profile is a saved configuration in the client

A Clash profile is a configuration managed by the client. It can come from a subscription URL or a local YAML file. FlClash stores, updates, and selects profiles, then passes the effective configuration to the Clash Meta core (mihomo). A profile is neither a single proxy node nor a proxy group.

A complete config can define listening ports, DNS, proxy nodes, proxy groups, and routing rules. For example, mixed-port: 7890 sets a mixed HTTP and SOCKS proxy port; proxy-groups determines how an outbound is selected; and rules determines which outbound handles a connection. Switching profiles can change all of these—not just the selected proxy node.

• Switching profiles: Choosing a different config can change the rules, node sources, and group structure.
• Switching proxy groups: Keeps the current config and changes the node or nested group selected by a particular group.
• Switching traffic modes: Changes how traffic is handled—Rule, Global, or Direct—without automatically switching to another subscription.

Subscription Configs vs. Local Configs

Both types ultimately produce a config the core can read; the main differences are where they come from and how they're maintained. A subscription config is fetched from a remote URL and can be refreshed later. A local config is imported and maintained by you. Whether changes to the original file are reflected in the client depends on how it was imported—don't assume it stays linked to the file on disk.

A subscription URL may not return a complete YAML config

“Subscription” describes how content is fetched, not its format. Some URLs return a complete Clash config; others provide only a list of nodes or a format intended for another client. A successful download doesn't guarantee the config can be activated. Use an endpoint the provider explicitly identifies as compatible with Clash or Clash Meta, and check that its fields and protocols are supported by your client and core.

Query parameters or paths in subscription URLs may contain access credentials. When troubleshooting, share only the error, field names, and redacted excerpts. Never include the full URL in public screenshots, ticket attachments, or config examples.

Before customizing rules, check where your changes are saved

FlClash interface options, config overrides, and remote YAML can all affect the effective config. Editing options and merge behavior vary by version, so don't assume changes to the subscription content will persist. Prefer an override feature explicitly supported by your version. If there's no suitable option, save a local copy and document your changes. With a separate copy, you'll also need to handle remote node updates yourself.

Importing subscriptions and setting update intervals

When importing, distinguish between adding an entry and activating it. A good workflow is: add the subscription → fetch it for the first time → inspect the config → activate it → verify with a new connection. Interface labels may vary across FlClash versions, so follow the feature descriptions below rather than relying on a specific menu path.

1. Add a source: In the profile manager, choose the option to add a URL, paste the full subscription address, and give it a descriptive name.
2. Check the contents: After the first fetch, check that nodes or proxy groups appear. An updated timestamp alone doesn't prove the config is active.
3. Activate the config: Set the new entry as the current profile and check for parse errors, unknown proxy groups, or port conflict warnings.
4. Verify the outbound: Select Rule mode, make a new test request, then check the matched rule and outbound chain on the Connections page.

For everyday use, start with a 24-hour update interval

A 24-hour interval is a convenient starting point, not a requirement of the core. If your provider frequently changes nodes, you could shorten it to 6 hours, following their guidance. If the provider sets a request limit, follow it. Fetching a subscription more often won't increase node bandwidth or fix local DNS or TUN routing issues.

• Check the units: 24 hours equals 1,440 minutes or 86,400 seconds. If the field uses minutes, enter 1,440—not 24—for a daily interval.
• Tell the two update settings apart: Remote profile updates and interval under proxy-providers are separate settings. In a mihomo config, the latter is measured in seconds.
• Check background conditions: Scheduled refreshes aren't guaranteed to run on time if the computer is asleep, the client is closed, or the mobile OS restricts background activity. Refresh manually in the foreground if needed.
• Know which timestamp you're looking at: The last update attempt, last successful update, and subscription expiration date mean different things. A successful update doesn't extend your account's validity.

Name and back up profiles by source, purpose, and date

Once you have three or more profiles, names like “Subscription 1” and “New config” make it easy to pick the wrong one. Use a pattern such as “Provider A – Daily – Remote,” “Provider B – Backup – Remote,” or “Daily rules – Test – Local.” Dates are more useful in backup names, such as “Daily rules – Backup – 2026-11-03.”

A profile name is only for managing entries in the client; it doesn't automatically become a rule target. Rules refer to proxy group names in the YAML. If you rename a group under proxy-groups from “Daily Outbound” to “Main Outbound,” update the rules and other groups that reference it. Renaming a profile in the list usually doesn't affect those references.

Keep at least one known-good rollback option

• Before making changes: Note the current profile name, traffic mode, selected node, system proxy status, and TUN setting.
• Back up the config: Save the YAML and any necessary override settings. Exporting only the base YAML may omit options saved separately by the client.
• Choose a secure location: Store backups containing node passwords in a restricted folder, separate from public code repositories and shared drives.
• Remove old entries carefully: Confirm the replacement config starts correctly before deleting duplicate entries. Don't leave expired URLs refreshing automatically.

What happens to connections and rules after switching?

Selecting a profile, successfully loading it in the core, and having new app connections use it are three separate things to verify. The client may save your selection before loading the config. If there's a YAML error or a referenced proxy group is missing, the selected state in the UI isn't proof that the switch finished. Check the logs and Connections page as well.

Check new and existing connections separately

Once the new config loads successfully, new connections are generally handled according to the current mode and rules. Don't assume established TCP connections, video sessions, or app connection pools will move to a new node automatically. Some clients close existing connections; others keep them open. It depends on the implementation and how you switch. For testing, make a fresh request first. If needed, use the client's connection-closing feature or restart the app.

Don't conclude that switching failed just because you refreshed a page that keeps its connection open. Check the Connections page for the new request's domain, matched rule, and outbound. Browser caching, connection reuse, and HTTP/3 can make a single refresh inconclusive; opening a new tab doesn't guarantee a new network connection either.

Traffic mode, DNS, and TUN settings may not switch with the profile

System proxy, TUN mode, and some DNS settings may be managed globally by the client or applied to the base YAML through overrides. After switching profiles, don't infer the effective state from tun or dns in the file alone. Check the actual toggles in the UI and the effective config, especially whether the client is still using Global mode.

For example, config A uses mixed-port: 7890, while config B changes it to mixed-port: 7891. If the client doesn't override the port and an app has 127.0.0.1:7890 configured manually, that app will connect to the old port after the switch. Check the system proxy managed by the client and proxy addresses entered separately in apps as well.

Local config example: verify the references first

Here's a minimal direct-connection example to illustrate a local profile. Save it as profile-local-demo.yaml and import it. It contains no remote proxy nodes; all connections matching “Daily Outbound” ultimately use DIRECT, so it can't be used to test whether a remote proxy works.

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

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

rules:
  - DOMAIN-SUFFIX,example.com,Daily Outbound
  - MATCH,Daily Outbound

This example shows two levels of references: “Daily Outbound” in the rules must match the proxy group name, and DIRECT in the group is a built-in outbound in the core. The final MATCH rule catches connections that didn't match earlier rules. Real subscriptions may use nested proxy groups, rule providers, and proxy providers; copying just one section doesn't mean all its dependencies are included.

Use spaces, not tabs, for YAML indentation. If import reports that a port is already in use, first check whether another program is listening on 7890 instead of repeatedly refreshing the subscription. If a proxy or group can't be found, check the spelling and references.

FAQ: The update succeeded, but the config didn't change

I refreshed a backup profile. Why didn't my current connection change?

Updating an entry doesn't activate it. Check whether the updated profile is the one currently active. If you updated a backup profile, it's expected that the running config won't change. Even after updating the active profile, check whether the client reloaded it and whether the content actually changed.

The node names are still there after switching. Did it fail?

Different subscriptions may use the same node names, and the client may restore a previous selection in a group with the same name. Check the profile name, rules, and outbound for a new connection—not just the node name. If a node is renamed or removed, its previous selection may not be restored.

Why didn't my local copy get new nodes from the remote subscription?

A local copy is usually a snapshot of the content at import time. It won't automatically gain nodes when the original subscription changes unless it references an updatable proxy provider. To keep receiving remote nodes while retaining custom rules, use an override method supported by your client or configure proxy providers and their references correctly.

What's the recommended troubleshooting order?

1. Confirm the active profile name and check the most recent successful load in the logs.
2. Confirm whether the mode is Rule, Global, or Direct, and check the current proxy group selection.
3. Check the proxy port, system proxy, and actual TUN status.
4. Make a new connection and verify its rule and outbound on the Connections page.
5. If the issue persists, revert to a verified backup and restore one change at a time.

Good profile management means keeping track of where configs come from, how they're updated, and what's currently running. Start with one profile and verify that it imports and connects before adding backups or test profiles. Check new connections after every switch to avoid confusing old sessions, global settings, and subscription content during troubleshooting.