Clash Config Files and Subscriptions

Profiles, Config Files, and Subscription Links

In Clash clients, a Profile usually refers to a configuration the core can load, along with the client’s record for managing it. The configuration itself is typically written in YAML, commonly using the .yaml or .yml file extension. The management record may store details such as a display name, subscription URL, and automatic update schedule; these details are not necessarily part of the configuration file.

A subscription link is a way to retrieve content, not a proxy node. When a client requests the link, the server may return a complete Clash configuration or just a list of nodes. A successful import only means the client received content it could recognize; it does not, by itself, confirm that nodes work, rules are correct, or traffic is being routed through the client.

How the Three Main Sections Work Together

A useful way to read a config is to follow its outbound references: proxies defines nodes, proxy-groups organizes nodes or other policies into groups, and rules determines which outbound handles each connection. Some configs also use proxy-providers to supply nodes, so an empty local proxies section is not necessarily an error.

proxies: Node connection settings

A node typically includes name, type, server, and port, along with the authentication and transport fields required by its protocol. The node name is used to reference it elsewhere. If you change a name, update its references in proxy groups too; changing it in only one place can cause a “proxy not found” loading error.

The provider determines a node’s exit location, authentication details, and server port. Don’t use the client’s local listening port as the node’s server port, and don’t infer the protocol from a node’s name. Labels such as “Hong Kong” or “Backup” are just names; they do not affect protocol selection.

proxy-groups: Manual and automatic selection

• select: Choose a member manually. Useful when you need to pin traffic to a specific exit.
• url-test: Automatically selects a member based on tests against a specified URL. The test result is not the same as a file download speed test.
• fallback: Checks members in order and uses the first available one.
• load-balance: Distributes connections according to the supported strategy; it does not simply combine bandwidth across a single download connection.

Rules reference a proxy group by name, not “the node currently selected with the mouse.” For example, if a rule points to the “Web Exit” group, check that group and the selections in any groups beneath it. Switching nodes in an unrelated proxy group will not change the outbound used by that rule.

rules: Evaluated from top to bottom

Common rule types include exact domain matching with DOMAIN, domain suffix matching with DOMAIN-SUFFIX, IP range matching with IP-CIDR, and the catch-all MATCH. In rule mode, the first matching rule usually determines where traffic goes. Put specific rules before broader ones, and place MATCH last.

DIRECT and REJECT are built-in outbounds for direct connections and rejected connections, respectively. The final field in a rule can also be the name of a defined proxy group. Names must match exactly, including spaces, capitalization, and punctuation; a full-width comma that looks similar cannot replace the regular comma used in rules.

Check YAML Structure with a Minimal Config

Here’s a direct-connection example to illustrate the structure. It has no remote proxy nodes and cannot be used as a remote proxy service. The example sets the HTTP and SOCKS mixed listening port to 7890, disables LAN access, and uses a manual group to connect a rule to the built-in direct outbound.

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

proxies: []

proxy-groups:
  - name: Manual Exit
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Manual Exit

1. proxies: [] means no nodes are defined in this section. A proxy group can still reference the built-in DIRECT.
2. DOMAIN-SUFFIX,example.com,DIRECT matches the example domain and its subdomains. This illustrates the syntax; it does not indicate how any particular service should be routed.
3. 192.168.0.0/16 is a private address range; no-resolve means this IP rule will not actively trigger a domain lookup.
4. Connections that don’t match the rules above go to “Manual Exit,” which has only a direct member in this example.

Use spaces for YAML indentation, not tabs. This example uses two spaces per level. Leave a space between a key’s colon and its value; wrap names containing special characters such as # in quotes. When troubleshooting, start with the line number in the log, then check the indentation and closing quotes on the preceding line.

Import a Subscription and Verify It

Using the common Clash Verge Rev interface as an example, open “Subscriptions,” paste the provider’s full subscription URL into the link field, and import it. Button labels may vary between releases, but distinguish between adding a subscription, updating its content, and activating a config: adding one does not switch the active runtime config.

1. Check the response format. Use a subscription endpoint identified by the provider as Clash or mihomo. If the result is a login page, an error message, or a string of encoded node URLs, don’t treat it as a complete YAML config.
2. Name the Profile. After importing, give it a clear local name so you can tell it apart from other sources in the list.
3. Activate the intended config. Select the Profile and wait for the core to finish loading. If an error appears, check the logs first; don’t repeatedly import the same URL and create duplicate entries.
4. Check the proxy groups. Open “Proxies” and confirm the expected group exists and has selectable members, then choose the exit you need.
5. Verify traffic routing. Start with one routing method, such as the system proxy. Open the target app and establish a new connection, then check its matched rule and outbound in the connection log.

If the actual mixed port is 7890, run the following command in a terminal to explicitly use an HTTP proxy. This helps distinguish an app that ignores the system proxy from an unavailable proxy. The command only tests whether this request passes through the local proxy; it does not verify that TUN or other apps are routed correctly.

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

Use the actual port if it’s different. If the connection is refused, first check that the client is running and the port is listening. If the local proxy connects but the remote request fails, check node authentication, the destination site, and DNS logs. Don’t assume every error means the subscription has expired.

Name and Switch Between Multiple Subscriptions

Most desktop clients can save multiple Profiles, but the core usually loads only one active runtime config at a time. Saving three subscriptions does not automatically combine their rules. Switching Profiles generally replaces the nodes, proxy groups, and rules, while client-wide settings and overrides may remain in effect.

Use Names to Identify Sources and Notes to Record Their Purpose

• Primary work: Keep your everyday work config here, and note any required proxy groups and routing needs.
• Home backup: Save a config from another source and switch to it manually if the primary is unavailable. Keep it as a separate update record.
• Local rule testing: Use a copy of the config to edit rules, rather than overwriting a working remote subscription.

Don’t put a full subscription URL or token in a Profile name. Names may appear in screenshots, logs, or screen shares. When backing up, check what the backup includes: exporting only the YAML may not save remote URLs, scheduled tasks, or the proxy groups’ previous selections.

Four Checks After Switching

1. Confirm the target Profile is marked active and the logs show no loading errors.
2. Check the proxy groups referenced by your rules again; don’t assume selections from the previous config carry over.
3. Keep the system proxy or TUN in the intended state. Avoid changing both the routing method and the subscription at once, so you can isolate problems.
4. Close and reopen the target app’s connections, then check the outbound for a new connection. Existing long-lived connections may not switch to a new node immediately.

If you need nodes from multiple sources at once, consider proxy-providers or an aggregation feature explicitly supported by the client rather than concatenating two YAML files. Duplicate top-level keys, node names, or proxy groups can cause parsing errors or ambiguous references. A complete config subscription is not necessarily valid provider data; confirm the response format first.

Update Intervals and Preserving Local Changes

“Update subscription” and “test nodes” are different tasks. The first fetches remote content; the second probes existing nodes. Updating more frequently won’t automatically reduce latency or make an inactive account work. For a source that rarely changes, start with a daily schedule and adjust it to the provider’s requirements.

A remote update usually replaces the downloaded config content. If you add custom rules directly to the remote file, they may disappear on the next update. For changes you need to keep, use an override or merge feature supported by the client. For a one-off offline test, save a separate local Profile and note that it will no longer update automatically from the remote source.

Check how overrides are merged too. Whether rules are appended, prepended, or replaced depends on the client. If custom rules are appended after MATCH, they won’t match as intended. After saving, check the final rule order rather than just confirming that the line appears in the editor.

Troubleshoot Import Failures and Broken Configs

Download Fails: Check the URL and Retrieval Path

Keep the subscription URL’s original query parameters, include the token, and don’t copy a trailing period added by a chat app. HTTP status codes 401 and 403 often indicate an authentication or access restriction issue; 429 means requests are being rate-limited, so stop retrying. If you need a proxy to update the subscription, keep a working config available to avoid a “no nodes to download nodes” loop.

Parsing Fails: Check the Format and Core Compatibility

If you see a YAML error, first confirm the response body isn’t HTML, then check indentation and colons. If a proxy type or field is unsupported, check the active core and the provider’s requirements; don’t remove authentication fields at random to silence the error. If the config loads but a group member is missing, check that node names, provider references, and group names match.

Loads but Can’t Connect: Check the Actual Outbound

First confirm the outbound mode is rule. In global or direct mode, traffic may not follow the rules in the config. Then check the matched rule, proxy group, and destination in the connection log; if needed, compare with the explicit proxy request above. For more on DNS, system proxy, and TUN settings, see Advanced; for basic routing setup, see System Proxy Guide.

A reliable workflow is to keep a working Profile, then import the new source; verify rules and outbounds before scheduling updates; and put long-term changes in a maintainable override layer. Change one thing at a time to identify whether a failure is in downloading, parsing, selection, or traffic routing.