Clash Subscription Formats: Base64 Links, YAML Configs, and Universal Subscriptions

1. Subscription URLs, Encoding, and Config Formats

A “subscription link” is simply an endpoint for retrieving content, not a fixed file format. The same HTTPS URL may return different content depending on request parameters or the client identifier: a list of proxy share links, a Clash YAML config, or a config for another client. Whether the URL ends in .yaml does not tell you if it can be imported directly.

Keep three layers distinct: the URL retrieves the content, Base64 encodes bytes as text, and the config format describes proxies, groups, and rules. Base64 is neither encryption nor a proxy protocol. Decoding a subscription restores its original text; it cannot conjure routing rules that were never there.

2. What Base64 Proxy Links Preserve

A typical proxy subscription joins multiple share links, one per line, then Base64-encodes the resulting text. Some protocols also use Base64 inside the share link, so there may be two layers: the outer subscription encoding and the inner protocol encoding. Seeing vmess:// or ss:// after one decode does not mean all proxy parameters have been expanded.

Common Fields in Share Links

• Connection credentials: Server, port, password or UUID, and the encryption method required by the protocol.
• Transport settings: TLS, SNI, WebSocket path and Host, gRPC service name, and more. What’s included depends on the protocol and share-link format.
• Display name: Proxy labels are often stored in the URI fragment, percent-encoded.

For example, two proxies may both connect on port 443, but one uses standard TLS while the other also requires a specific WebSocket path. If a converter keeps only the server, port, and password, the second proxy may fail its handshake. The same port does not mean the connection settings are identical, and 443 alone is not evidence that TLS is enabled.

Proxy share links usually don’t include a complete DNS policy, rule order, TUN routing, or automatic proxy groups. When converting this kind of subscription to a Clash config, converters often apply a template. So groups like “Auto Select” or “Region” in the new config may come from the template, not the original subscription.

Inspect Content Safely

Use a trusted client’s config preview or a local editor to inspect the response. If you need to decode it, use a local tool and avoid writing the full content to public terminal logs. Passwords, UUIDs, and subscription tokens remain sensitive after decoding. When troubleshooting, share only the structure and error line numbers with credentials removed.

3. Full YAML Configs vs. Proxy Providers

YAML is a way to represent data; it doesn’t mean a file is complete. Clash-family configs typically define proxies with proxies, organize selection methods with proxy-groups, and route connections with rules. This sample config shows how the three relate. The example domain and password are not valid for real connections.

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

proxies:
  - name: Example Proxy
    type: trojan
    server: edge.example.com
    port: 443
    password: example-password
    sni: edge.example.com
    skip-cert-verify: false

proxy-groups:
  - name: Manual Select
    type: select
    proxies:
      - Example Proxy
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,Manual Select

Here, 7890 is the local mixed HTTP/SOCKS proxy listening port, not the remote proxy port. The final MATCH rule sends any connection not matched earlier to “Manual Select.” If a conversion changes a group name without updating rule references, the config may fail to load.

proxy-providers Require a Main Config

Proxy providers separate proxy updates from the main config. A standard mihomo YAML provider file usually has a top-level proxies: list. The main config declares it under proxy-providers, then references it from a group using use. A file containing only a proxy list is not a main config with rules and groups already in place.

Some clients can add default groups when importing proxy-only content, but that’s an importer feature—not a guarantee that every client supports it. Before choosing a remote config, check whether the endpoint expects a “full config” or a “proxy provider.” To keep custom rules, consider using a main config with a provider or a client-supported override mechanism, rather than repeatedly editing a file that subscription updates will overwrite.

4. Fields Commonly Lost During Subscription Conversion

Conversion usually follows three steps: parse the source, generate intermediate proxy data, and output the target format. Any field that a step doesn’t recognize may be ignored, renamed, or replaced with a default. Producing YAML only means the tool generated text; it doesn’t mean the target kernel can connect using the original parameters.

Clash, Clash Premium, and Clash Meta (now called mihomo) do not support exactly the same fields. A “Clash” target in a converter may also produce output for an older kernel. With mihomo, choose an output target that explicitly supports the protocols and fields you need. A filename containing Meta doesn’t prove compatibility, and the desktop client version alone doesn’t tell you what its kernel supports.

5. Convert and Import a Subscription Step by Step

1. Prefer native output. If your provider offers a Clash or mihomo config tailored to your current kernel, use it directly to avoid extra parsing steps. Don’t run a working YAML config through another converter.
2. Check the downloaded content. Confirm whether the response is proxy text, YAML, a login page, or an error page. A successful HTTP response doesn’t guarantee that the content is a config. Content beginning with <!DOCTYPE html> usually can’t be loaded as a subscription.
3. Use a trusted conversion environment. If conversion is necessary, prefer a locally run tool or a conversion endpoint from a trusted provider. Online converters may have access to your original subscription token and proxy credentials.
4. Choose the target kernel and template. First confirm the required protocols can be output, then select a rules template. If you only need a proxy list, make sure the output is suitable for a proxy provider instead of replacing the main config.
5. Test the new config. Keep your working config and import the conversion result as a separate config. Check the config validation results before starting the kernel. If an error appears, use the logs to find the cause; don’t overwrite your only working file.
6. Check the final active config. A client may apply global overrides, merges, or scripts. Check the processed group names, rules, DNS, and ports—not just the downloaded YAML.

The source subscription URL in a conversion URL usually needs to be encoded as a parameter. If the source URL contains & or #, concatenating it directly may truncate the token or turn part of it into another parameter. Use the tool’s input field or standard URL-encoding feature. Don’t repeatedly encode the entire URL by hand, and don’t post the generated URL in a public discussion.

6. Four Checks After a Successful Import

1. Proxy Count and Key Parameters

Suppose the source subscription has 12 proxies but the converted config has only 9. First check protocol support, region filters, and deduplication settings. Then spot-check at least one working proxy’s server, remote port, SNI, and transport settings. Matching counts still don’t prove every field made it through, and renaming may affect name-based rules.

2. Config Syntax and References

YAML indentation uses spaces, not tabs. For errors such as proxy not found, check references within groups and rule targets. For parse errors, start at the logged line and the line above it; check indentation, colons, and quotes. Quoting proxy names with special characters correctly can prevent ambiguity.

3. Latency, Real Requests, and Rule Matching

A successful latency test only means that test request received a response; it doesn’t prove every site is reachable. First verify browser requests through the system proxy, then check the connection panel for the matched rule, selected group, and final proxy. Once the basic connection works, configure TUN if you need to handle apps that ignore the system proxy. This keeps routing, DNS, and format issues from getting mixed together.

4. Check Whether Updates Overwrite Your Changes

Manually update the subscription once and check that your custom rules remain, proxy providers update, and groups can still select proxies. For an HTTP provider, interval: 3600 sets the update interval in seconds—one hour. A desktop client may have a separate subscription refresh schedule; don’t confuse it with the proxy health-check interval.

7. Format Choices and Common Questions

Why Can’t I Import a Subscription After Decoding Base64?

Decoding restores the content; it doesn’t assemble a Clash config. Once you have a list of proxy URIs, you need a client that supports importing share links or a conversion to proxy definitions the target kernel can read. Changing the file extension to .yaml doesn’t change the content’s structure.

Can I Convert Another Client’s JSON Directly to Clash?

It depends on whether the converter supports that specific structure. For example, sing-box JSON may describe not only outbound connections but also its own DNS and routing logic. Even if proxy parameters can be converted, routing semantics may not map one-to-one. Check proxy migration and rule reconstruction separately; “supports JSON” doesn’t mean it supports configs from every client.

For Long-Term Use, Should I Choose a Full Config or a Proxy Provider?

If you want to use your provider’s preset rules as-is, a native full config takes fewer steps. If you need to maintain custom routing over time, a main config paired with a proxy provider usually makes updates easier to isolate. If you only have a Base64 proxy subscription, consider a conversion with a clearly defined target. Whichever approach you choose, keep the original subscription URL, check kernel compatibility, and verify the result with real connections and rule matches.