Clash Subscription Formats: Base64 Proxy Lists, YAML Configs, and Share Links

Subscription URLs vs. subscription contents: distinguish the endpoint from the data

A Clash subscription is usually an HTTPS URL. It provides a way to fetch a configuration, but that does not mean the response will meet Clash or mihomo's configuration requirements. The same service may offer a generic proxy subscription, a Clash config, and formats for other clients. Some services also return different content depending on request parameters or the client's User-Agent.

To identify the format, check the response body downloaded by the client, not just the URL suffix. A link without a .yaml suffix may still return a complete YAML config; a URL with that suffix may return an HTML page if your login has expired. An HTTP 200 status only means the server returned a response—it does not prove the config is valid.

Three common formats: share links, Base64 lists, and YAML

A share link is not a complete set of proxy rules

A share link can describe a proxy, but it usually does not specify “which domains should bypass the proxy” or “which policy group handles the final match.” TLS, SNI, and WebSocket paths are proxy connection settings; DOMAIN-SUFFIX, GEOIP, and MATCH are Clash routing rules. They operate at different levels, so a proxy link cannot automatically provide a complete set of rules.

Link formats also differ by protocol. A common vmess:// format encodes a JSON object; ss:// has several historical formats; and vless:// often carries transport settings in query parameters. Treating every link as the same kind of Base64 string can lead to missing or misread fields.

Base64 is an encoding, not encryption

A “Base64 subscription” usually encodes a list of proxy links as a single block of text. Decoding restores the text; it does not add policy groups or make an unsupported protocol supported. Some content uses URL-safe characters or omits trailing padding, so the presence or absence of an equals sign alone does not tell you whether it is Base64.

Proxy passwords and subscription credentials may be embedded in the encoded content. Publicly sharing the original subscription, its decoded contents, or a full QR code could expose the same credentials. Use local text tools for troubleshooting, and redact authentication fields before sharing screenshots.

What mihomo can load directly—and when conversion is needed

mihomo is the project name used after Clash Meta. For the config file import path, the clearest input is YAML that matches its config structure. A complete config needs a working outbound proxy and routing logic; a proxy provider file is for use with proxy-providers in a main config. The fact that both files are YAML does not make a provider file a complete config.

• Your provider offers a Clash Meta or mihomo config: Use that format first, and check that the client's core supports the specific protocols and fields in the subscription.
• Your provider offers only Base64 or line-by-line URIs: First check whether the GUI client supports that import method. If it doesn't, use a trusted converter to generate the format you need.
• You're using a proxy provider: Use a provider format supported by your current mihomo version. Support for other payload formats may vary by version; YAML with a top-level proxies list makes proxy fields easy to inspect.
• You see “unsupported proxy type”: Check which core is actually running, the proxy type, and the client's release notes. A successful conversion does not mean the running core supports the protocol.

TUN is not a format-compatibility switch. TUN mode routes traffic through a virtual network interface, while subscription parsing happens when the config loads. Enabling TUN will not fix YAML parse errors, unsupported proxy fields, or missing policy group references.

Complete YAML configs and proxy providers: two different jobs

Here's a mihomo config to illustrate the structure. It provides direct access only, with no remote proxies or account details. 7890 is the mixed proxy port in this example; if another process is already using it, choose a free port and update the settings of any apps that use it.

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

proxies: []

proxy-groups:
  - name: Select Outbound
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Select Outbound

proxies stores explicitly defined proxies, proxy-groups organizes selectable outbounds, and rules determines which outbound handles each connection. The Select Outbound name in the rule must match the policy group name. A proxy list alone, without the expected policy groups and routing rules, cannot reproduce the behavior of a complete config.

The main config references the provider file

To keep your own rules when updating proxies, separate the proxy list from the main config. This example uses a local file provider at ./providers/nodes.yaml. Merge it with the rest of your main config; don't use it to replace an existing file as if it were a complete config.

proxy-providers:
  Subscription Proxies:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: Select Proxy
    type: select
    use:
      - Subscription Proxies
    proxies:
      - DIRECT

rules:
  - MATCH,Select Proxy

The local file should have a top-level proxies list in its YAML, populated with proxy definitions supported by the current core. Relative paths are resolved from the core's working directory, which may differ from the config file's location in your file manager. GUI clients may also use a separate data directory; check the runtime logs and the client's data directory settings.

use references a provider name, not a proxy name. When you replace the proxy list, keeping the provider name stable means you won't need to update the policy groups and rules in the main config for every proxy name change. For HTTP providers, also configure the remote URL, cache path, and update interval, and make sure the subscription format is suitable for that provider.

When converting subscriptions, check protocol parameters and policy groups

Conversion tools typically do two things: parse proxy data, then apply the results to a target config. The second step may add the tool's preset DNS, rules, policy groups, and ports. So matching proxy counts alone do not prove a conversion is correct; check how the generated config will behave.

1. Check the output type. Distinguish a complete config from a proxy provider output. If you plan to load it through proxy-providers, choose an output designed for providers rather than using a complete main config as a proxy file.
2. Check key connection parameters. Verify the server address, port, authentication details, TLS setting, SNI, transport type, WebSocket path, and Host. For REALITY proxies, retain the required public key and short-id parameters.
3. Check name references. Rule targets, policy group members, and provider names must match. If you rename a proxy, update any policy group that lists it by name. If you rename a policy group, update the rule targets too.
4. Check filtering results. A regex filter may exclude every proxy if proxy names have changed. First check how many proxies are actually in the provider, then confirm that the policy group selected the expected members.
5. Check global settings. See whether the conversion template changes dns, tun, allow-lan, or the controller interface. Don't inspect only the proxies section.

Access controls for self-hosted conversion services

Sending a raw subscription URL to a conversion service gives that service access to the subscription contents. If you host the service yourself, restrict who can access it, require authentication, and avoid writing full request URLs to public access logs. If users can submit arbitrary URLs for fetching, block loopback, private network, and cloud metadata addresses to prevent the converter from being used to access internal networks.

Nested subscription URLs also require URL encoding. If the original URL already contains &, ?, or percent signs, appending it directly to a converter's query string may split the subscription into multiple parameters. Use the tool's form or a proper URL builder; don't try to handle the whole link by manually replacing a few characters.

Troubleshooting import failures: from response body to config validation

Step 1: Make sure the response isn't a web page

Check the client's subscription update logs. If you see a login page, CAPTCHA, access denied message, or HTML tags, first resolve the subscription authorization or server response issue. 401 and 403 usually mean you should check your credentials or access restrictions; for 429, follow the service's guidance and reduce request frequency instead of repeatedly clicking Update.

Step 2: Check the structure and characters

YAML uses spaces for indentation, not tabs. List item hyphens, ASCII colons after fields, and correct nesting all matter. If a proxy name contains a colon or hash, quote it to prevent it from being read as structure or a comment. Don't fix a config by simply deleting the line that triggers an error: the next rule may still reference the deleted item.

Step 3: Validate with the core that's actually running

When running mihomo on its own, use its config test option to check the file. This command assumes a config named config.yaml is in the current directory and mihomo is on your command search path:

mihomo -t -f ./config.yaml

The test can catch config parsing errors and some reference issues, but it does not confirm that remote proxies are reachable. After it passes, check the selected policy in the client, review the connection logs, and make a real request. A GUI client may apply overrides to the config, so check the final effective config—not just the template before the subscription was downloaded.

Rules disappear after updates: separate proxy updates from your local config

A complete subscription config is often regenerated during updates. If you edit rules directly in the downloaded file, the next update may overwrite your changes with the remote version. To keep changes long term, use the client's override or merge feature when available. Another option is to maintain your own main config and use the remote subscription only to provide proxies.

• Just want to import and start using it: Choose a complete mihomo or Clash Meta config explicitly provided by the service, and make sure its policy groups and rules meet your needs.
• Need to keep your own routing rules: Keep your rules and policy groups in your main config, update proxies through a provider, or use a persistent override feature supported by the client.
• Need to change DNS or TUN: Check these fields in the final effective config and see whether the client manages them separately. Avoid maintaining two sets of settings that overwrite each other.
• Moving to another client: Back up both the subscription URL and your local overrides. Copying only the subscription URL usually won't bring over local rules, the proxy selection in the UI, or system proxy settings.

Use a consistent troubleshooting order: check the response format, confirm the import method, check core support, validate references, and finally test the connection. The format describes the data; policy groups and rules control routing; system proxy and TUN send traffic to the core. Separating these layers helps you determine whether to convert the subscription, adjust the config, or troubleshoot the network connection.

For more on config fields, see Advanced Config. If you're unsure how proxies, policy groups, and rules differ, start with the glossary. Keep raw subscription URLs in a controlled location, and include only troubleshooting-related fields in diagnostic materials.