What Is a Clash Profile? Config Files and Managing Multiple Configurations

Profiles, config.yaml, and Runtime Configuration

A Profile is a configuration managed by the client. It can come from a local YAML file or a remote subscription URL. In addition to its configuration data, a Profile typically includes management details such as its name, source, and last update time. Switching Profiles changes the configuration source and content; it does not reinstall the client or change your operating system’s network settings.

config.yaml is a common configuration filename, not a fixed identity shared by every Profile. When running the Clash or mihomo core directly, you can specify a configuration file. In Clash Nyanpasu, the client may combine subscription content, client settings, and overrides into a runtime configuration for the core to load. As a result, the original content shown in the Profile list may not exactly match what the core ultimately reads.

Item	What it contains	Where to check
Profile	Name, source, configuration content, and management details	The client's Profiles page
Source YAML	Proxies, proxy groups, rules, and other configuration fields	The config editor or exported source file
Runtime configuration	Fields processed by the client and passed to the core	Runtime configuration viewer and core logs
Client settings	System proxy toggle, interface options, and client-specific settings	The client's Settings page

When troubleshooting, first identify which layer you changed. If editing the source YAML has no effect, it may not have been reloaded, or a client setting or override may have replaced the same field. Changes to a temporary runtime file may work for the current session but be lost when the client regenerates it during the next switch, update, or restart.

How Local Configs, Remote Subscriptions, and Overrides Work

Local Configs: Fixed Inputs You Can Reproduce

Local configs are useful for testing rules, reproducing issues, and keeping offline copies. After importing a file, check whether the client copied its contents or kept a reference to the original; don't assume that editing the file on your desktop will update the client. You can verify how it handles files by renaming one, importing it again, and comparing the contents.

Remote Subscriptions: Configs Updated on a Schedule

A remote Profile typically stores a subscription URL and fetches its contents again when you update it manually or on a schedule. If the subscription returns a complete Clash YAML, it may include proxies, proxy-groups, and rules. Plain text containing only proxy URIs is not a complete Clash configuration, and changing its extension to .yaml will not convert it.

Before editing proxies or rules in a remote Profile, consider what will happen at the next update. If the update replaces the source content, your manual changes will be overwritten. Keep personal rules in a separately maintained override, or save the subscription as a local Profile and edit that instead; the local copy will no longer receive updates from the original subscription.

Overrides: Keep Personal Changes Separate

Overrides add or modify fields on top of an input configuration—for example, by adding a LAN direct-connection rule or setting a consistent log level. Available merge methods, script APIs, processing order, and scope depend on the client version. Don't assume scripts for other clients work as general-purpose Clash Nyanpasu interfaces, or that list fields are always merged by appending.

Create a Local Profile You Can Test

The YAML below is for testing import, switching, and rule loading; it does not include a proxy server. Save it as UTF-8-encoded local-check.yaml, then add it from the local file import option on the Profiles page. Select the Profile and confirm that it has loaded. The option's name may vary by version, so use the file import action shown in your current interface.

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

proxy-groups:
  - name: Local-Choice
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN,example.com,DIRECT
  - MATCH,Local-Choice

mixed-port: 7890 sets the shared HTTP and SOCKS port for this example; it is not the default port for every client version.
allow-lan: false prevents LAN access. Don't use this example as a shared proxy configuration for your local network.
mode: rule sets rule mode. If the client manages the mode separately, check the value in the interface and the effective runtime value.
Local-Choice contains only the built-in direct and reject targets. Importing it successfully does not provide access to remote proxies.

After loading the Profile, confirm that Local-Choice appears on the proxy groups page and select DIRECT. To test the local HTTP proxy port, run the command below. This test does not depend on the system proxy toggle and does not confirm that all browser traffic is being routed through the proxy.

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

Check the connection log alongside the command output. example.com should match the domain direct-connection rule. If the connection to the port is refused, check whether the core is running and which port it is actually listening on before blaming the subscription.

Naming and Switching Between Multiple Profiles

Distinguish Profiles by Source, Purpose, and Status

Choose names that make each Profile's scope clear. A useful format is “source-purpose-status,” such as Subscription-A-Daily-Stable, Local-Rule-Test, or Subscription-B-Backup-Check. Don't include the full subscription URL or account tokens. Put dates in backup filenames instead of adding a new, nearly identical name to the Profile list every day.

Record the current state. Note the active Profile, selected proxy group member, rule mode, actual port, and the system proxy and TUN states. For example, if the port changes from 7890 after switching, update any apps that use a manually configured proxy.
Check the target Profile. Update a remote Profile and confirm that its content downloads successfully. For a local Profile, check YAML indentation and rule targets, and make sure every referenced proxy group exists.
Switch Profiles. Select the target Profile on the Profiles page and wait for the client to finish loading it. Check the core logs for parse errors, unsupported fields, or port conflicts.
Recheck proxy groups. Two Profiles may both have a group named “Proxy” but contain different members. Check which specific proxy is selected instead of relying on the group name.
Test a new connection. Make a new web request and check its rule, proxy chain, and destination in the connection log. Seeing the Profile selected in the list is not enough to confirm that traffic is taking the expected route.

Switching Profiles usually affects new connections; existing connections may not move over right away. For a reliable test, close and reopen the test app, or use the client's connection-closing feature. Closing connections can interrupt downloads, meetings, and other long-lived sessions, so save your work first.

Multiple Profiles, Multiple Proxies, and TUN: What's the Difference?

A single Profile can contain multiple proxies organized into groups such as select and url-test. Switching from proxy A to proxy B usually doesn't require a new Profile. Switch Profiles when you need a different set of rules, DNS settings, or subscription source.

A typical desktop client instance provides its core with one final runtime configuration at a time. Having three Profiles in the list does not mean their rules are automatically combined. To combine multiple sources, use a configuration composition method explicitly supported by the client, and check for conflicts among proxy names, group names, and rule targets.

Routing Traffic and Selecting a Configuration Are Separate

System proxy: Affects apps that follow the operating system's proxy settings. Some apps use their own proxy settings or ignore the system proxy entirely.
TUN mode: Routes traffic through a virtual network interface. It requires operating system permissions and correctly configured DNS and routes.
Profile: Supplies the proxies, rules, and other settings the core uses to handle connections. It is separate from the traffic-routing options above.

If an app still connects directly after you switch Profiles, first check whether its traffic appears in the core's connection log. If not, check how traffic is being routed into the core. If it does appear but uses the wrong destination, check the mode, rule order, and selected proxy group. Don't keep toggling TUN just to troubleshoot a rule-matching issue.

Make Minimal, Compatible Overrides

Keep long-term overrides small and specific. For example, add a single rule for direct access to your LAN instead of copying and editing an entire subscription. Reference proxy group names you have confirmed exist. If Profiles use different group names, configure them separately or explicitly check whether the target exists in your processing logic.

# Insert near the start of the rules list, not after MATCH
- IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

This is a rule snippet, not a complete Profile you can import on its own. It only covers the example subnet 192.168.50.0/24; if your LAN uses 192.168.1.0/24, adjust it to match your routing table. no-resolve means the rule won't trigger a DNS lookup just to match this IP rule; it does not disable all DNS queries.

Test on a copy of your stable Profile and keep the original as a fallback.
Change one type of field at a time—for example, rules first, then DNS. Don't adjust the port and TUN settings at the same time.
Check the final runtime configuration to confirm that field values, list order, and rule targets are as expected.
Run a subscription update and check again to confirm that the override consistently reapplies your personal changes.

Clash, Clash Meta (mihomo), and their different versions do not support exactly the same fields. If you see an “unknown field” error or an unsupported rule type, note the core name and version, then check compatibility in the YAML Reference. Renaming a Profile file won't resolve differences in core capabilities.

Back Up and Restore Configurations in the Right Order

Back Up More Than Just the YAML

A restorable backup should include the configuration, overrides, and any necessary client settings. Save remote URLs too, but store them separately in encrypted storage. A subscription link alone can't preserve proxies later removed by the provider; a source YAML backup alone may miss personal overrides that are actually in effect.

Source config: Export a stable Profile, for example local-check-2026-09-27.yaml.
Overrides and associations: Save scripts and rule snippets, along with notes on which Profiles they apply to.
Environment details: Record the client and core versions, listening port, and system proxy and TUN states.
Sensitive data: Check for subscription tokens, proxy passwords, API keys, and certificate files. Never upload them to a public repository.

To restore, import the source config first and confirm it parses. Then restore overrides and check the final fields. Enable the system proxy or TUN only if needed. When moving to another computer, don't blindly reuse the old machine's network interface names, absolute paths, or LAN addresses. If rule sets or proxy providers rely on remote downloads, confirm the new machine can access them.

Troubleshooting: What to Check First

Symptom	Check first	What to do
Traffic still behaves like the old config after switching	Load logs, current runtime rules, existing connections	Confirm the Profile loaded successfully, then test with a new connection
Rules disappear after a subscription update	Whether you edited the remote source directly	Move personal changes to an override or local Profile
Proxy group not found	Whether the rule target exactly matches the group name	Check capitalization, spaces, and group names after subscription updates
Core won't start	First parse error, field compatibility, port conflicts	Revert to a stable Profile, then restore changes one at a time
Only some apps are affected	Whether connections reach the core, and the app's own proxy settings	Check the traffic routing path first, then rule matching

For reliable Profile management, keep a fallback copy, separate the subscription source from personal changes, and check the runtime state after switching. The config describes how traffic should be handled, the client organizes and loads it, and the system proxy or TUN routes traffic into the core. Troubleshooting these three layers is more effective than repeatedly reimporting the subscription.