Clash Profiles Getting Started: Subscription Links, Local YAML, and Switching Between Configs

Profiles and subscriptions

In a Clash client, a profile is generally a configuration that can be selected and loaded. It may come from a remote subscription or a YAML file on your computer. Along with the config itself, a profile may store client metadata such as its source URL, last update time, and update interval. The core reads the processed configuration—not the profile card shown in the interface.

Knowing the difference helps clarify three actions that are often confused: importing adds a config to the list; updating fetches its contents again; activating passes a config to the core to run. A successful import doesn’t mean the profile is active, and a successful download doesn’t mean the core accepted the new contents.

Be sure to distinguish a full subscription from proxy-providers. A full subscription may define ports, DNS, groups, and rules. A proxy provider mainly supplies proxies, which the main config references in its proxy groups using use. rule-providers supply rule sets, not proxy nodes.

Importing a subscription URL

Check the format it returns

The same provider may offer subscriptions in several formats. A proxy list intended for another app may not work as a complete Clash YAML config. Choose a format explicitly labeled for Clash or mihomo when available. If it includes protocols such as VLESS or Hysteria2, make sure the core your client actually uses supports them—don’t assume compatibility just because the app has “Clash” in its name.

1. In your client, open the “Config” or “Profiles” page and use the option for importing from a URL. The button may be labeled “New,” “Import,” or “Add,” depending on the client; follow the current interface.
2. Paste the full URL without leading or trailing spaces, quotation marks, or punctuation added by a chat app. Give the profile a descriptive name, such as “Home network” or “Travel backup.”
3. After importing, check the update time and select the profile to activate it. Check the logs for parsing failures, unknown fields, or errors referencing proxy groups.
4. Open the proxy groups and confirm that proxies are listed, then test a new connection that clearly uses the relevant group. For now, avoid changing DNS and TUN at the same time; that makes the source of any problem harder to identify.

If an import fails, inspect the response

If the error mentions YAML but the response starts with <html>, you may have downloaded a login or error page instead. HTTP 401 and 403 errors often indicate expired authorization or access restrictions; 429 usually means you’ve hit a rate limit. Check the subscription source first. Don’t keep retrying the update or disable TLS certificate verification just to bypass the error.

Local profiles and a minimal example

A local profile is useful when you need fixed rules, want to keep a config offline, or are learning what the fields do. Create a UTF-8 encoded file named profile-local.yaml, indent with spaces, not tabs. Here’s a minimal example to show the structure: it listens on localhost port 7890, offers a single direct option, and includes no remote proxies.

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

proxy-groups:
  - name: Select manually
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Select manually

• mixed-port: 7890 provides HTTP and SOCKS proxy access. The port number is just an example; not every client uses 7890.
• allow-lan: false prevents other devices on your local network from using the proxy. Keep this setting for an initial setup to reduce network exposure.
• mode: rule enables rule mode; the final MATCH catches connections that didn’t match an earlier rule.
• Select manually is a proxy group name and must match exactly wherever a rule references it. This example ultimately selects DIRECT, so traffic still connects directly.

After importing the file as a local config, the client may still override the listening port, operating mode, or DNS settings. When troubleshooting, check the original file, client settings, and runtime config—not just the YAML. For core fields and compatibility, see the core configuration reference.

If mihomo is installed and executable on your system, run the syntax check below from the file’s directory. A successful check only means the core can load the config; it doesn’t confirm that proxies are reachable or that the desktop system proxy is enabled.

mihomo -t -f ./profile-local.yaml

Setting the auto-update interval

For everyday profiles whose proxies don’t change often, start with an auto-update interval of once every 24 hours. For services that frequently change their proxies, try every 6 hours if your provider recommends it. These are starting points, not measured performance results. More frequent updates won’t lower the latency of existing proxies and may trigger rate limits on the provider’s servers.

Check the unit before entering a value

• If the client uses minutes, enter 1440 for 24 hours; if it uses hours, enter 24.
• For mihomo HTTP proxy providers, interval: 86400 means 86,400 seconds, or 24 hours. This field is not the GUI’s profile update interval.
• A provider’s health-check interval, health-check.interval, controls how often proxy status is checked—not how often the subscription is downloaded again.
• Don’t assume 0 always means updates are disabled. Clients may interpret it differently; use the clearly labeled auto-update switch whenever possible.

Update tasks may not run on time while your computer is asleep, the client is closed, or the network is unavailable. Once you’re back online, check the “Last successful update” time. After changing the subscription URL, run an update manually to confirm it works. An enabled auto-update switch alone doesn’t mean the file is up to date.

A checklist for switching profiles

Most desktop clients activate only one main profile at a time. Having three profiles saved in the list doesn’t mean all three providers’ proxies are loaded into the same group. Switching profiles may apply new rules, DNS settings, and proxy groups together. System proxy settings and TUN permissions are usually managed by the client, though, and may not change with the profile.

1. Note the current state: Record the current profile name, operating mode, selected proxy, and the status of the system proxy and TUN switches.
2. Select the new profile: Confirm the interface shows it as active, then check the core logs for load failures. If loading fails, the client may keep using the previous config.
3. Check the proxy groups: A client may remember a selection for a group with the same name, but the previous proxy may not exist in the new config. Don’t assume it’s still selected.
4. Confirm the proxy port: If an app is manually configured to use 127.0.0.1:7890 but the new runtime config listens on port 7897, make the settings match.
5. Start a new connection: Close and reopen the test page or app connection, then check the connection log for the matched rule and proxy. Existing long-lived TCP connections may not be recreated immediately after a switch.

If the browser works after a switch but the terminal doesn’t, check the terminal’s environment variables before changing subscriptions. On Linux, run the command below to view common proxy variables. The output may contain internal addresses, so remove sensitive details before sharing logs.

printenv http_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY

The system proxy setting mainly affects apps that honor it. TUN routes more connections through a virtual network interface and requires the appropriate service or permissions. Switching profiles doesn’t grant TUN permissions. Compare the two approaches in the TUN mode guide and check each setting.

What to check when merging configs

If you really need to use multiple sources in one config, use a main config with proxy-providers or a merge feature explicitly supported by your client. Don’t concatenate two complete YAML files: duplicate top-level keys may be rejected or overwrite each other, and the result won’t automatically combine their proxies and rules.

Rule order matters more than rule count

Rules are generally matched from top to bottom. If you append a custom rule after MATCH,DIRECT, the fallback has already caught the connection, so later rules won’t behave as expected. If the client offers separate options for prepending and appending rules, check where they end up in the generated config—not just whether the editor says they were saved.

Also, a regular full subscription may not work directly as a proxy-providers resource; providers need a node format supported by the core. Merge tools may replace entire arrays instead of appending to them. Add one source at a time, then check the runtime config for proxy counts, group references, and the final rules after the load test passes. This makes problems easier to trace than pasting in multiple sources at once.

Backups, recovery, and common issues

Don’t back up only the subscription URL

A subscription URL can help you download remote content again, but it won’t fully restore custom rules, client overrides, or proxy group selections. Save a backup when the config first works and before making major rule changes; label each copy with the date. Keeping a known-good local config makes recovery more reliable.

• Config files: Save local YAML files, usable snapshots of remote configs, and each profile’s source and update time.
• Custom layers: Save override files, merge scripts, and rule resources you maintain. Don’t rely only on copies of generated runtime files.
• Client settings: Record listening ports, system proxy and TUN settings, and update intervals. Prefer the client’s built-in export feature when available.
• Protect your data: Backups may contain proxy passwords, subscription tokens, or controller API keys. Store them in a restricted-access folder and use secure storage when syncing them to other devices.

Why did my rules revert after an update?

The most common reason is that you edited the remote profile itself. Move your changes to a separate client override layer, then check whether the generated config retains the rules. Don’t make long-term edits to a temporary runtime file; it may be regenerated when the client restarts, switches profiles, or updates.

Why doesn’t my local config update automatically?

A locally imported profile usually contains only the file contents, with no remote source. Some clients copy the file instead of continuously reading it from its original path, so changes to the file on disk may not take effect right away. Check whether your client supports file linking. If it doesn’t, import the file again or edit it through the client, then reload the config.

Can’t connect after restoring an old config?

First confirm that the core loaded the old profile successfully. Then check whether the subscription has expired, the system clock is correct, and the port is available. Restoring a config can’t bring back proxies removed by the provider or restore system permissions. Troubleshoot in this order: config loaded → proxy port → rule match → proxy connectivity. This is usually more effective than toggling several settings at once. For more help, see the subscription FAQ.