Clash Subscription Formats: YAML Configs, Base64 Proxy Lists, and Conversion

Check the subscription response, not just the URL suffix

A subscription URL is the address a client uses to fetch content; the URL itself does not determine the content format. The same URL starting with https:// might return Clash YAML that can be loaded directly, or a block of Base64 text. Some URLs may even open a login page or display an error. If an import fails, first determine whether the URL is unreachable or its response is unsupported by that import option. This is more useful than repeatedly changing the subscription name.

You’ll commonly encounter three types of content: a complete YAML config, an encoded proxy list, and single-proxy share links such as ss://. They carry different kinds of information, so they are not interchangeable just because they all contain proxies. This matters especially for proxy groups and rules: a proxy list describes available connections, while a complete config also determines how traffic is routed through them.

Complete YAML: routing settings as well as proxies

Clash config files commonly use the .yaml or .yml extension. The proxies key defines proxies, proxy-groups defines groups for manual selection or automatic testing, and rules determines how traffic is matched in rule mode. Fields such as mixed-port set the local listening port. YAML uses indentation to express hierarchy, so both list-item hyphens and field indentation affect parsing.

Here’s a minimal snippet to illustrate the structure. 127.0.0.1:1080 represents a SOCKS5 upstream already running on your machine; without that service, this example won’t provide a working external connection. 7890 is the local mixed port in this example, not a port that every client uses by default.

mixed-port: 7890
mode: rule

proxies:
  - name: Local demo
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: Manual Select
    type: select
    proxies:
      - Local demo
      - DIRECT

rules:
  - MATCH,Manual Select

In rule mode, MATCH in this example sends connections not matched by another rule to the “Manual Select” group. If DIRECT is selected in that group, those connections go direct. After importing a real config, check that the client shows the expected proxy groups and rule count—not just that the proxy list appears. If the config uses proxy-providers, also confirm that the provider URL can be updated and that your client and its core support the fields used.

“YAML” describes a file syntax; it does not guarantee that the contents form a complete, runnable config. For example, YAML containing only proxies: may work as a proxy provider but may not route traffic as a standalone config. Conversely, a complete config with DNS, rules, and proxy groups may still load if it has no .yaml extension, provided the client reads it as YAML and the content is valid.

Base64 proxy lists: decode first, then identify the protocol

Base64 is a text-encoding format, not a proxy protocol. A typical Base64 subscription contains multiple share links on separate lines, encoded together as one string. After decoding, check the protocol prefix and parameters on each line; don’t paste the encoded string directly into config.yaml. Putting encoded text under proxies: won’t automatically turn it into YAML proxy objects, either.

This type of list can usually provide server addresses, ports, authentication parameters, and proxy names, but it does not include Clash proxy-groups, rules, or local mixed-port settings. If your client has a dedicated proxy-subscription option, it may parse the list and add the proxies to your existing config. If it only offers config import, you’ll need a suitable Clash config or convert the list locally and add proxy groups and rules. The exact option name depends on your client’s interface.

• Starts with proxies:: Treat it as YAML and check indentation, fields, and compatibility with the target core.
• One long string of encoded characters: First confirm that it is Base64, then inspect the decoded lines. Don’t guess based on the URL’s filename.
• Decodes to multiple links such as ss://: This is a proxy list, not a ready-to-use routing config.
• Returns HTML or a login prompt: Check subscription access, sign-in status, or whether the URL has expired. Changing the file extension won’t change the response.

One case is easy to mistake: a single share link may encode some parameters internally, but it still describes just one proxy. The presence of Base64 characters doesn’t make it a “Base64 subscription.” Look at the outermost content: is it an encoded list of links on multiple lines, or one share link with a protocol prefix?

Single-proxy links: share a connection, not a complete subscription

Prefixes such as ss://, vmess://, and trojan:// identify share links for different protocols. A link usually represents one proxy. Even if a client can detect and import it from the clipboard, the link won’t specify which proxy group to use, which domains should go direct, or how DNS should be configured. After adding a proxy manually, check that the active config’s proxy groups reference it.

A protocol prefix helps identify a link, but does not guarantee compatibility. The original Clash and Clash Meta (mihomo) support different protocols and config fields. For example, don’t assume that the original Clash can use a vless:// link directly. Even with mihomo, check the actual core version, protocol parameters, and the client’s import capabilities. “The client can’t recognize the share link” and “the core doesn’t support fields in the converted proxy” are separate issues; record errors for each step when troubleshooting.

Converting formats: preserve fields and add routing logic

Conversion is more than renaming .txt to .yaml. When converting a proxy list to a Clash config, each link must at least be mapped to a corresponding proxies object. You’ll then need to decide on proxy group names, group membership, and how to handle rules. Exporting a complete YAML config as a proxy list works in the opposite direction and discards information: proxy groups, rules, DNS settings, and local ports usually won’t be included with individual proxy links.

Check these four areas before converting

1. Protocol fields: Check the server, port, authentication method, and any required transport or TLS parameters. One missing field can leave a proxy visible but unable to connect.
2. Proxy names: Check for duplicate names after conversion. If proxy groups refer to proxies by name, a duplicate or renamed proxy may no longer match the intended entry.
3. Groups and rules: Confirm that the converted output actually includes proxy-groups and rules. If it only generates proxies, treat it as a proxy list, not a complete config.
4. Target core: Choose an output format for the Clash or mihomo core you plan to run. A conversion tool can generate fields that your current core still may not parse or support.

For regular updates, distinguish between a one-time converted file and a config that refreshes with its subscription. Copying subscription content into a local YAML file saves a snapshot of the proxies at that point in time. Changes to proxies or credentials upstream won’t update the local file. If you use the client’s config URL update feature, check that the expected groups and rules remain after an update. If you use proxy providers, check that they update successfully and that the proxy groups referencing them still work.

Check conversion results in three steps: first, see whether the client can load the YAML; next, confirm that proxy groups list the expected proxies; finally, test routing with a real connection in rule mode. A successful load only means the current client parsed the config—it doesn’t prove that proxy parameters, upstream services, or routing rules are correct. Note the selected group member before testing, then compare it with the connection log afterward. This helps avoid mistaking a misselected DIRECT route for a subscription issue.

When import fails, troubleshoot the content, parsing, and connection in order

Step 1: Did the content load?

When importing a URL from the client’s “Profiles” page, first check that the address is complete, your account still has access, and the update didn’t return a network error. A page opening in your browser doesn’t guarantee the client will receive the same config content: a login page, redirect notice, or expiration message is not YAML. Check the beginning of the response when troubleshooting, and keep subscription URL tokens out of screenshots.

Step 2: Can the content be parsed in the expected format?

If you see a YAML error, check for tabs in the indentation, missing spaces after colons, and list items at the wrong level. If the import shows proxies but no rules or proxy groups, check whether the source was a proxy list to begin with. For an unknown protocol or field error, note the client version and core name, then compare them with the subscription’s target format. Repeatedly renaming the file won’t fix core compatibility issues.

Step 3: Do the proxies and routing work?

Once proxies appear, confirm that the expected proxy group includes them, then check which rules match in rule mode. The system proxy usually handles apps that follow your system proxy settings. Some clients offer TUN mode to capture other traffic, but TUN permissions, DNS, and routing require separate configuration and won’t be added by converting a subscription. If a proxy connects but app traffic still doesn’t use the expected group, check the client mode, system proxy or TUN status, and the rule that actually matched.

Choosing a format is straightforward: for routing settings that are ready to load, get a complete YAML config compatible with your core. To add a batch of proxies to an existing config, use a supported proxy-list or proxy-provider option. To share one connection, use its protocol-specific link. Identify the content first, choose the appropriate import option, then check groups, rules, and connection results to distinguish format issues from network problems.