Clash Subscription Formats: YAML, Base64 Links & Converters

1. Check the response before choosing an import method

Clash clients generally need YAML configs compatible with their current core. A Base64-encoded proxy list or a single proxy link is not a complete config. A downloaded file named “subscription” or ending in .yaml is no guarantee it can be imported. The actual format depends on the response body and whether the client supports parsing or converting it.

A subscription URL is an entry point for retrieving content, not a format in itself. The same URL may return different content depending on request parameters or the User-Agent: a browser might show proxy links while a client receives YAML, or vice versa. So check separately whether the URL opens in a browser and whether the Clash client can load the config.

2. Clash YAML: what nodes, proxy groups, and rules do

YAML is a serialization format; a Clash config is a set of fields defined by the core. Valid YAML is not necessarily a valid Clash config. For example, an API response with just a message field is valid YAML but contains no usable proxy configuration.

• proxies: Proxy definitions, including the protocol, server, port, and authentication parameters.
• proxy-providers: Proxy providers that load a set of proxies from a file or remote URL.
• proxy-groups: Proxy groups that define how proxies are selected, such as manually, by latency, or through failover.
• rules: Match traffic in order and route it to DIRECT, REJECT, or a defined policy.
• dns and tun: DNS resolution and traffic interception settings; not every proxy subscription includes them.

A minimal example to illustrate the fields

This is a direct-connection config. mixed-port: 7890 means HTTP and SOCKS share a listening port. It has no remote proxies and does not enable the system proxy or TUN; it’s only meant to show how a complete config differs from a proxy list. A client may override fields such as the port in its UI, so check the active config for the values actually in use.

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

proxies: []

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

rules:
  - MATCH,LOCAL

Here, MATCH,LOCAL points to the defined LOCAL proxy group. The common MATCH,PROXY rule also requires a proxy or proxy group named PROXY in the config; it is not a built-in default route. Copying rules without the referenced groups causes errors.

Don’t confuse full configs with provider files

Proxy provider files usually center on proxies: and supply only a set of proxies; rule provider files typically use payload:. Both need to be referenced by a main config, so don’t treat them as complete subscriptions with proxy groups and routing rules. In particular, don’t enter a rule provider URL as a proxy subscription.

3. Base64 and proxy links: decoding is not conversion

Base64 is an encoding, not encryption or a proxy protocol. Traditional subscriptions often list multiple proxy links on separate lines, then Base64-encode the entire text. Decoding it gives you proxy definitions—not proxy groups, DNS settings, or rules.

Some proxy links also use Base64 internally. For example, a common VMess share link encodes the proxy’s JSON parameters after vmess://; Shadowsocks links use several different encoding formats. Don’t confuse the encoding of an entire subscription with the encoding inside an individual proxy link, and don’t keep decoding until the text looks familiar.

1. Check the outer format: If the text already contains links such as ss://, one per line, there’s no need to Base64-decode the entire response first.
2. Decode locally: If you’ve confirmed it’s an encoded proxy list, use a trusted local tool to inspect it. Watch for URL-safe characters and missing padding.
3. Check the fields: Verify the protocol, port, transport, and TLS parameters—not just whether the proxy name appears.
4. Build a config: Map the parsed proxies to fields supported by the target core, then add proxy groups and rules. That’s subscription conversion.

4. Subscription conversion: target cores, templates, and credential risks

Conversion tools typically download the source, parse proxy parameters, and output the target format. If you apply a rules template, the tool may also generate proxy groups and routing rules, or reference remote rule sets. As a result, the same set of proxies can route traffic very differently depending on the template.

Use the format provided by your subscription service

If your subscription dashboard offers options such as “Clash,” “Clash Meta,” or “mihomo,” choose the one that matches your core. Clash Meta is now called mihomo; the legacy Clash core and mihomo don’t support exactly the same fields and protocols. Converter interfaces may also use outdated names, so check the output fields and the documentation for your target core.

Conversion can’t add protocol support to an older core. If a source proxy uses a protocol or transport parameter the target core doesn’t support, the tool may fail, skip the proxy, or drop fields. Changing the output file extension to .yaml won’t fix a compatibility issue.

What a public conversion service can access

• The source subscription URL, including its path, query parameters, and access token.
• Retrieved proxy credentials, such as server addresses, ports, passwords, and UUIDs.
• Plan details returned by the subscription and access logs related to the conversion request.

HTTPS protects data in transit, but it doesn’t prevent the conversion service itself from reading your input. If conversion is necessary, use a trusted local tool or a self-hosted service. Saving a web page locally doesn’t mean conversion happens locally—check whether it sends requests to a remote backend.

What to check after conversion

Compare the result with the source: check the number of proxies, protocol types, TLS servername, WebSocket ws-opts, gRPC grpc-opts, and whether credentials were preserved. Don’t enable skip-cert-verify across the board just to clear connection errors. Also check whether the template added unfamiliar rule-providers, DNS upstreams, or external controller settings. A successful conversion only means output was generated—not that the config is what you expected.

5. Import and verify a config in a Clash client

First, distinguish between importing a remote config and adding a single proxy. Most Clash GUI clients manage proxies through configs and may not accept arbitrary proxy links directly. The steps below use the “Subscriptions” page in Clash Verge Rev as an example; other apps may call it “Profiles,” and button labels can vary by version.

1. Back up your current config: Save the existing subscription URL, local overrides, and current proxy group selections. Keep the old config while testing the new one so you can switch back if needed.
2. Add a remote config: Open “Subscriptions,” enter the Clash or mihomo subscription URL from your provider, click “Import,” then select the newly added config.
3. Import a local file: If you have a YAML file, use the client’s local config import option. Don’t paste a file path into the remote URL field.
4. Check the parsed result: Open “Proxies” and check that the proxy groups and proxies appear. Then review the logs to distinguish a config load failure from a provider download failure or a proxy connection failure.
5. Test traffic: Check the active listening port, then enable the system proxy and test browsing. If the client is listening on 7890, apps should connect to 127.0.0.1:7890 on your device—not to the subscription server.

The system proxy and TUN determine how traffic reaches the core; they don’t convert a Base64 proxy list into YAML. If an import fails, repeatedly toggling TUN usually just adds more variables to troubleshoot. Get the config loading first, then check traffic interception, DNS, and routing.

For rules you want to keep, use the client’s supported override mechanism. Direct edits to a downloaded remote subscription may be overwritten on the next update. When overrides merge lists, check whether the client prepends, appends, or replaces entries. Otherwise, your custom rules could end up after the final MATCH rule.

6. Import failures: troubleshoot by layer

YAML indentation and field types

Use spaces—not tabs—for YAML indentation. Keep the - on list items; mappings generally use a colon followed by a space. Quote passwords or names containing characters such as colons or hash marks according to YAML rules. Use strings for credentials to prevent numbers or special text from being parsed as another type.

The browser downloads the subscription, but the client can’t update it

Check redirects, certificates, differences in request headers, and whether updates use a direct or proxied connection. If the subscription is only reachable through a proxy and the current config has no working proxy, updates may depend on a connection that isn’t available yet. Try importing a local YAML file from the provider first, then check the remote update path.

Importing a new protocol reports that it isn’t supported

Check the client and core versions on the app’s “About” page; they’re separate version numbers. Record the exact protocol name, core version, and error, then check compatibility. Don’t assume every field is interchangeable just because the installer says Clash. Legacy Clash config, mihomo-specific fields, and client-specific override scripts need to be assessed separately.

Follow this order: check the response → identify the format → check the target core → import the config → test the connection. If you already have compatible YAML, there’s no need to convert it. If conversion is necessary, keep the source and conversion settings so you can compare them and spot missing fields.