Reference 12-minute read

Clash Subscription Formats Explained: Base64, YAML, and Universal Links

Compare the structure of Clash YAML subscriptions, base64 share links, and universal subscription formats, including client compatibility and fields that may be lost during conversion.

Separate encoding, links, and configuration files

A “Clash subscription” is not a single format. A server may return a complete Clash YAML file, a text list of share links, or that same text wrapped in base64 encoding. All three may be imported through one URL, but clients follow different parsing paths after receiving the response.

Base64 causes the most confusion. It only encodes bytes as printable characters; it does not define node fields or determine which protocols a client supports. A set of ss://, trojan://, or vmess:// links arranged one per line and then base64-encoded is commonly called a “base64 subscription.” After decoding, the meaningful data is still each individual share link.

Clash YAML is a structured configuration file. Along with nodes, it can carry proxy groups, routing rules, DNS settings, listening ports, rule providers, and TUN parameters. Universal subscriptions usually only deliver nodes; the client template or converter supplies the policy structure and routing behavior.

Format Typical opening or structure What it can describe Primary use
Clash YAML proxies:、proxy-groups: Nodes, proxy groups, rules, DNS, TUN, and more Use directly as a Clash or mihomo configuration
Plain-text share links ss://、trojan:// Connection parameters for one node Copy nodes between clients
Base64 subscription A sequence of letters, numbers, and encoding characters Usually multiple share links in encoded form Distribute a collection of nodes through one subscription URL
Provider-specific JSON { or client-defined fields Depends on the server and target application A specific client or API integration

Why Clash YAML is more than a node list

A runnable Clash YAML configuration usually includes at least proxies, proxy-groups, and rules. The first stores node parameters, the second defines manual selection, automatic latency testing, or failover policies, and the last determines which policy group handles each connection.

mixed-port: 7890
allow-lan: false
mode: rule

proxies:
  - name: HK-Trojan-01
    type: trojan
    server: edge.example.net
    port: 443
    password: example-password
    sni: cdn.example.net

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - HK-Trojan-01
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

This configuration sets the mixed proxy port to 7890 and creates a manual selection group named PROXY. Real subscriptions may also include rule-providers, proxy-providers, dns, sniffer, tun, and persistent cache settings. These are beyond what a single share link can express.

A full configuration is not the same as a proxy provider

mihomo configurations can reference remote node collections through proxy-providers. The main configuration keeps the DNS settings, rules, and proxy groups, while the remote URL updates only the nodes. This structure separates local routing logic from the remote node source.

proxy-providers:
  airport-a:
    type: http
    url: https://sub.example.net/token
    path: ./providers/airport-a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

The remote content is usually provider YAML. Its top level may contain only proxies:, so it is not a complete configuration that can start the core on its own. If a provider file is imported into a client that accepts only full Profiles, the usual result is missing ports, proxy groups, or rules, followed by a configuration validation error.

YAML is sensitive to indentation and data types

  • Indent with spaces; do not mix in Tab characters.
  • Port 443 is usually a number, while passwords, names, and server addresses are usually strings.
  • If a name contains a colon, hash sign, or leading or trailing spaces, quote it.
  • true and the string "true" have different meanings and cannot be swapped arbitrarily.
  • Duplicate node names can become ambiguous in proxy groups, so deduplicate names before converting.

How base64 subscriptions and universal share links are organized

Universal subscriptions commonly contain one URI per line. Each protocol defines its own server, port, authentication, and extension parameters within the URI. Shadowsocks commonly uses ss://, Trojan uses trojan://, VMess commonly uses vmess://, and VLESS uses vless://. mihomo supports more protocol types, but support varies across older Clash cores and different graphical clients.

ss://[email protected]:8388#SS-01
trojan://[email protected]:443?sni=cdn.example.net#Trojan-01
vless://[email protected]:443?type=ws&security=tls&host=cdn.example.net#VLESS-01

The fragment at the end of a link is usually used as the node name. Query parameters may store TLS, SNI, WebSocket paths, Host, transport, or fingerprint settings. Implementations differ in parameter names and default values. A client recognizing a URI prefix does not necessarily mean it fully understands every extension field.

Base64 decoding may reveal another encoded layer

After decoding the subscription, a VMess link may still contain a base64-encoded JSON object; Shadowsocks user information also has several URI representations. Process each layer in order: decode the subscription body, identify the protocol on each line, then pass it to the appropriate protocol parser. Repeatedly decoding the entire body can damage the original links.

  1. Fetch the subscription response and keep a copy of the original text.
  2. Check whether it begins with proxies:, a protocol URI, or a JSON structure.
  3. Only attempt decoding when the content actually matches base64 character patterns.
  4. Split the decoded content by line, remove blank lines, and identify each protocol.
  5. Check that node counts, names, ports, and TLS parameters are intact.

Client compatibility depends on the core and import path

When the same subscription behaves differently in two clients, the URL is usually not the problem. The differences may come from core protocol support, client-side preprocessing, or the import path. Clash for Windows 0.20.39 is no longer maintained, and its Profiles page is primarily designed for Clash configurations. mihomo-based clients generally parse a wider range of protocol fields, but whether a graphical client accepts a raw universal subscription still depends on its own subscription module.

Importing a full YAML configuration

In Clash for Windows 0.20.39, the usual path is “Profiles” → enter the subscription URL at the top → “Download.” After importing, check that the profile card appears, then open “Proxies” to verify the proxy groups and nodes. If the nodes appear without the expected rules, the server may have returned a node collection processed through a client template rather than the original full YAML.

In 2.x graphical clients using the mihomo core, the path is often “Subscriptions” → “New” → “URL.” Names vary by client, but the checks are the same: whether the update returned HTTP 200, whether configuration validation passed, whether the number of proxy groups is expected, and whether the core reloaded successfully.

Port numbers are not part of the subscription nodes

7890, 7891, and 9090 often appear in Clash configurations, but they serve different purposes. 7890 is commonly the mixed HTTP and SOCKS entry point, 7891 is used for SOCKS in some older configurations, and 9090 is commonly the external control interface. Universal share links describe remote proxy nodes; they do not decide which ports the local client listens on.

That is why converting a universal subscription to YAML often requires the converter to inject mixed-port, proxy groups, and rules. Even when the nodes are identical, two conversion results can route traffic differently because they use different templates.

What format conversion actually does

“Subscription conversion” usually involves four steps: identify the input, parse the nodes, map the fields, and apply an output template. The input may be full YAML, provider YAML, a base64-encoded link collection, or plain-text URIs. The output may be Clash YAML, mihomo YAML, or subscription text readable by another client.

Converting a universal subscription to Clash YAML

This is the most common path. The converter parses each share link into a proxies entry, then creates proxy groups and rules from a template. At a minimum, verify these fields:

  • Protocol type, server address, port, and authentication details.
  • Whether TLS is enabled and whether SNI or servername is preserved.
  • Transport methods such as WebSocket and gRPC, along with their path parameters.
  • The UDP setting, certificate verification bypass, and client fingerprint parameters.
  • Whether node names are encoded correctly and whether duplicate names receive automatic suffixes.
  • Whether the target is using legacy Clash syntax or mihomo extensions.

Converting Clash YAML to a universal subscription

A reverse conversion will always lose configuration-level information. Share links can carry node connection parameters, but not proxy-groups, rules, rule-providers, DNS, TUN, sniffing, or listening ports. Even if another client shows the same number of nodes after import, that does not mean the two configurations are equivalent.

Converting full YAML to provider YAML

This step usually extracts only proxies and outputs a file referenced by proxy-providers. Routing rules and proxy groups from the original configuration are not automatically added to the main configuration. The main configuration must also use use: to place the provider in the intended proxy group; otherwise, the nodes may download successfully but still be unavailable for selection in the interface.

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - airport-a
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

Field loss usually occurs in these six areas

1. Protocol extensions have no equivalent in the target

The source format may contain client fingerprints, Reality public keys, short IDs, ECH, congestion control, or transport-specific parameters that have no equivalent target fields. A converter may ignore them or write extension keys the target client does not recognize. The result is often not an immediate error: the node appears, but connections time out.

2. Rules and proxy groups are replaced by the template

When converting full YAML, a tool may extract the nodes first and then apply its own template. The original DIRECT, REJECT, failover groups, and rule order are replaced. Clash rules are matched from top to bottom, so changing their order changes the result. For example, placing GEOIP,CN,DIRECT before a domain-specific proxy rule may send the connection directly before that rule is reached.

3. Node names are used for filtering

Many templates use regular expressions to build groups such as “Hong Kong,” “Japan,” or “Low Multiplier” from node names. If flags, spaces, or region abbreviations change during conversion, a filter may shrink from 30 nodes to none. Compare the actual members of each proxy group before and after migration, not just the total subscription count.

4. Boolean values and defaults change

When a source link omits a parameter, two clients may apply different defaults. UDP, TLS verification, SNI derivation, and the transport Host may all depend on default behavior. If the converter writes an explicit value, connection behavior may differ from the original client.

5. DNS and TUN remain entirely in the old configuration

Successfully migrating nodes does not mean the system proxy path has migrated. Fake-IP address pools, DNS upstreams, domain sniffing, routing exclusions, and TUN auto-routing are local settings. Universal subscriptions do not carry these fields. After switching clients, check “Settings” → “System Proxy,” “Settings” → “TUN Mode,” and the DNS configuration instead of assuming the old client's state carries over.

6. Subscription update mechanisms differ

A full YAML file can carry fixed nodes directly; a provider has its own interval and cache path; and a graphical client may maintain its own update schedule. In the example, interval: 3600 means a request every 3,600 seconds, while a health check with interval: 600 runs every 600 seconds. They are different tasks.

A migration workflow you can verify

The safest approach to format conversion is not to “import with one click and immediately route all traffic,” but to keep the old configuration and compare results in stages. This workflow applies when moving from a universal subscription to mihomo YAML, as well as when switching configurations between two Clash graphical clients.

  1. Record a baseline. Note the original client’s total node count, frequently used proxy groups, system proxy port, DNS mode, and TUN status.
  2. Identify the input. Confirm whether the response is full YAML, provider YAML, plain-text URIs, or base64 text.
  3. Choose the target. Determine whether the target core is legacy Clash or mihomo, and avoid generating fields unsupported by that core.
  4. Convert the nodes first. Check the server, port, protocol, TLS, SNI, transport layer, and names before touching the rules.
  5. Apply the template next. Add proxy groups, rules, DNS, and listening ports, then verify that all referenced names match.
  6. Validate the configuration. Check parsing errors before reloading the client, paying particular attention to YAML indentation, duplicate keys, and missing proxy groups.
  7. Test with limited traffic. Disable TUN first and enable system proxy only. Confirm browser traffic before testing DNS and TUN.
  8. Compare real-world behavior. Test a direct-connection domain, a proxied domain, a blocked domain, and a UDP scenario to confirm that rules match as expected.

If nodes appear normal after conversion but all connections time out, extract one node and compare it with the source link. Check the port, SNI, TLS, and transport path. If only some websites fail, focus on rule order and DNS. If system applications bypass the proxy, check the system proxy or TUN instead of continuing to change the subscription format.

Choose the format based on the intended use

  • Need to reproduce the full routing setup: Use a complete YAML configuration compatible with the target core, preserving its rules, proxy groups, and DNS settings.
  • Only need to move nodes between clients: Use universal share links or a base64 subscription and let the target client manage its own policies.
  • Want to maintain local rules long term: Keep the main configuration fixed and update nodes remotely through proxy-providers.
  • Need mihomo extension protocol support: Select mihomo explicitly as the conversion target instead of falling back to the legacy Clash field set.
  • Source format is unclear: Inspect the response body first, then decide whether to decode or convert it. Do not chain multiple converters blindly.

In short, base64 handles text transport, share links describe individual nodes, and Clash YAML manages the complete proxy behavior. Conversion can carry fields across formats, but it cannot preserve information the target format cannot express. Distinguishing these three layers before migrating greatly reduces cases where nodes import successfully but fail to work, rules disappear, or DNS behavior changes unexpectedly.

Install the client and verify the subscription

Choose the right platform first, then follow the guide to import the subscription and check proxy groups, system proxy, and DNS.

Go to downloads View the guide
Download Clash