Clash Subscription Formats Explained: Configuration Types, Compatibility, and Conversion Principles

Subscriptions, configurations, and encoding are different layers

When troubleshooting a Clash subscription, the first step is not finding a converter. Start by separating the link, the server response, and the client configuration. A subscription link is only an access point. After the client requests it, the server may return a complete YAML configuration, a YAML file containing only proxies, a line-by-line list of share links, or Base64-encoded text. The file extension at the end of a link usually cannot reliably identify the response type.

A complete Clash configuration describes an executable traffic-handling path. In addition to proxies, it may include listening ports, proxy groups, rules, rule providers, DNS, TUN, sniffing, and configuration providers. A proxy subscription only answers “which proxy entry points are available”; it cannot determine which policy group should handle a domain or replace the device’s DNS and traffic-capture settings.

Common responses fall into four categories:

Complete configuration: You will typically find proxies, proxy-groups, and rules. After import, these can form the basic execution chain for rule mode.
Proxy provider configuration: The main body is often a proxies array referenced by proxy-providers in the main configuration. It may not run independently as a complete configuration.
Generic share-link list: Each line contains a protocol link such as ss://, trojan://, or vmess://. Direct import depends on the client’s subscription parser.
Encoded text: Base64 is only a way to transport text. After decoding, you still need to determine whether the result is a link list, YAML, JSON, or an error page returned by the server.

Identify the configuration type from the response

Inspect the actual body returned by the subscription request rather than relying only on the description shown on a webpage. Browser developer tools, client update logs, or command-line tools that display response headers and bodies can help. If authentication is required, avoid pasting the full URL into public logs, screenshots, or online analysis pages, because query parameters may contain long-lived access credentials.

First confirm that the response is a configuration, not a webpage

When a subscription URL has expired, authentication has timed out, or access is rate-limited, the server may return an HTML login page, error page, or verification page. If the body begins with <!doctype html> or <html>, do not continue parsing it as YAML. A successful HTTP status alone does not prove that the body is a valid configuration; some services use a normal webpage to explain errors.

Check the top-level YAML fields

A relatively complete Clash configuration may have the following structure. The exact fields vary by core and use case, but proxy-group references and rule targets must resolve correctly:

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: Tokyo-01
    type: trojan
    server: edge.example.invalid
    port: 443
    password: example-password
    sni: edge.example.invalid

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Tokyo-01
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,DIRECT

proxies defines the proxies, proxy-groups organizes proxies or other policy groups into selectable policies, and the final part of rules refers to a policy group, proxy name, or built-in action. If a rule points to PROXY, the configuration must contain a policy group with that name or another valid target. Names are sensitive to characters and spaces, so casual renaming during conversion can break references.

Identify link lists and encoded content

If decoded line-by-line text contains many protocol prefixes, it is usually a proxy-link subscription. The links carry server, port, authentication, and some transport parameters, but generally do not include a complete rule system. Some links store the display name in the fragment identifier; if a parser handles percent encoding or character sets differently, imported proxy names may be garbled or duplicated.

You cannot identify Base64 solely because text looks like a string of random characters. First rule out compressed data, JSON, HTML, and server messages, then use a decoding method that matches the character set. After decoding, perform format detection again; successful decoding does not mean the resulting configuration is usable.

Observed characteristics	Likely type	Next step
proxies, proxy-groups, and rules all present	Complete Clash or Mihomo YAML	Check core-field compatibility and references
Only a proxies array	Proxy provider content	Reference it from the main configuration through a provider, or add policies and rules
Each line starts with a protocol link	Generic proxy subscription	Use a parser that supports the relevant protocols to generate proxy entries
The body starts with an HTML tag	Login or error page	Check the URL, authentication, status code, and redirects
YAML or links appear only after decoding	Encoded subscription wrapper	Continue identification using the decoded content

Compatibility boundaries between Clash, Clash Meta, and Mihomo

“Clash format” is not one permanently fixed version. The original Clash core established a widely used YAML structure; Clash Meta extended it with additional protocols, rules, DNS, TUN, and routing capabilities, and later projects adopted the Mihomo name. Many current clients use Mihomo as their core, while their interfaces or subscription providers still use Clash as a general label.

Compatibility usually means that a newer core can read more legacy fields. It does not mean that every Mihomo configuration can be handed back to an older core. If a configuration uses proxy types, transport parameters, rule syntax, or DNS options unknown to the older core, startup may fail with field errors or silently ignore some settings. Choose the conversion target based on the core actually running, not merely the client’s name.

Proxy protocols and transport parameters

Whether a proxy works depends on whether the core implements the relevant protocol and parameter combination. Even when two subscriptions contain the same protocol, their field names and supported ranges for TLS fingerprints, Reality, HTTP/2, gRPC, QUIC, and other extensions may differ. When a converter does not recognize a field, the usual result is not “automatic compatibility” but a dropped field or a proxy that can no longer connect.

Rule provider behavior types

rule-providers contains more than a remote file URL; it also defines behavior, format, update interval, and storage path. Common behaviors include domain, ipcidr, and classical. A domain set cannot be used directly as an IP network set, while a classical rule set can carry entries with type prefixes. A RULE-SET reference in the main rules must match the provider name.

DNS and TUN belong to the local execution environment

DNS and TUN settings are closely tied to the operating system, permissions, network interfaces, and client implementation. Server information in a proxy subscription can move between devices, but copying an entire TUN interface name, route exclusion list, DNS bind address, or system-proxy setting often carries assumptions from the source device to the target. A desktop configuration may not suit a server, and an Android client may let its interface manage VPN permissions while ignoring some desktop-oriented fields.

Six things to check before converting a subscription

The goal of conversion is to map source data into a structure understood by the target core, not to compress everything into a file that merely “imports.” Before starting, check at least these six items.

Confirm the target core. Record whether the client uses Mihomo, a traditional Clash-compatible core, or a mobile client with its own parsing layer. The same subscription can produce different results in different clients.
Confirm the source scope. Determine whether the source is a complete configuration, a proxy collection, or a single share link. A converted proxy collection will usually still need the main configuration to provide policies, rules, and DNS.
List protocols and key fields. Check authentication, TLS, SNI, transport method, UDP support, and extension parameters for each proxy type. After conversion, compare representative entries rather than only counting proxies.
Check name references. Proxy groups can reference proxies and other proxy groups, while rules reference policy targets. Any renaming, deduplication, or character normalization must update every reference consistently.
Check rule semantics. Rule order affects the result because Clash matches from top to bottom and stops at the first match. Reordering rules during conversion can change the traffic path.
Separate remote and local settings. Proxies and remote rules can update on a schedule; ports, the control interface, DNS, TUN, LAN listening, and authentication are usually better maintained by a local template.

Why conversion can fail even when the proxy count matches

The proxy count only proves that the parser created the same number of entries; it does not prove that every entry retained all parameters. A converter may preserve the server and port while dropping the SNI, transport path, or protocol extensions. It may also append suffixes to duplicate names, leaving existing policy groups pointing to the old names. Validate representative proxies across different protocols and inspect handshake-stage errors in the connection logs.

Why rules cannot be merged by simple text concatenation

Appending two rule lists can create ordering conflicts. For example, a broad domain rule near the top may match first and prevent a later specific rule from taking effect; IP rules may also trigger DNS resolution, depending on the rule type and parameters. When merging, establish priority first: local exceptions usually belong in more specific positions, broad rules and the final fallback should come later, and the configuration should retain one clear, controllable final destination.

Credential boundaries when using online converters

A subscription URL usually grants access to the proxy configuration it serves. Submitting the full URL to a third-party conversion service effectively gives that service access to the subscription response. A safer approach is to use a local conversion workflow in a trusted environment or the target format explicitly provided by the subscription provider. If an intermediary is unavoidable, understand its request method, logging policy, and caching behavior, then rotate the access credentials afterward if the provider supports it.

Build a verifiable, reversible conversion workflow

A reliable workflow keeps remote proxies, the local main configuration, and generated output separate. When the subscription updates, only the data source changes; verified DNS, TUN, and rule structures remain intact.

Step 1: Capture a source snapshot

Save one original response and record the retrieval time, response type, and target core. The snapshot helps rule out changes in the subscription source during troubleshooting. Restrict file permissions when saving it, since it may contain proxy authentication details.

Step 2: Parse without rewriting

First have the parser produce a structured result, then inspect the detected protocols, proxy names, and fields. Do not add rules or perform bulk renaming at this stage. If a proxy type cannot be recognized, resolve the source-to-target protocol compatibility issue first rather than hiding the error in a later template.

Step 3: Map into the local main configuration

Bring the proxies into the main configuration as proxy-providers or explicit proxies data, then define policy groups in the local main configuration. With a provider, a policy group can reference the proxy collection through use, reducing the manual work needed to update its member list after each subscription change.

proxy-providers:
  remote-set:
    type: http
    url: https://config.example.invalid/profile.yaml
    interval: 21600
    path: ./providers/remote-set.yaml
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

proxy-groups:
  - name: PROXY
    type: select
    use:
      - remote-set
    proxies:
      - DIRECT

This example illustrates the structural relationship. In actual use, the provider response must meet the target core’s requirements; adjust the health-check URL, update interval, and storage path for the network environment. If the source returns a complete configuration rather than provider-format content, placing its URL under proxy-providers alone will not make the core extract proxies automatically.

Step 4: Perform three levels of validation

Syntax layer: Confirm that YAML indentation, list nesting, quotation marks, and field types are correct. Names containing colons, hash signs, or other special characters should be quoted.
Reference layer: Confirm that every proxy or provider referenced by a policy group exists, every rule target exists, and rule-set names match their providers.
Runtime layer: After startup, inspect configuration loading, provider updates, DNS queries, proxy handshakes, and rule-match logs, then test both direct and proxied traffic.

Step 5: Enable DNS and TUN one at a time

First validate proxies and rules through a standard system proxy or an explicit proxy port. Then enable advanced DNS settings, and test TUN only when needed. Changing proxy format, DNS, and TUN simultaneously makes connection failures difficult to isolate. Add one group of variables at a time and keep the last known-good configuration.

Troubleshooting import failures and missing proxies

A subscription update reports a parsing error

First determine whether the error occurred during download or YAML parsing. For download failures, check the status code, redirects, authentication, and response body. For parsing failures, inspect indentation, colons, list markers, and character encoding around the reported line. YAML uses spaces to express nesting; tabs or misaligned indentation can prevent the entire file from loading.

No proxies appear after import

Confirm that the response is actually a proxy collection. If the file contains only a proxy-providers definition, it describes how to fetch proxies later; it does not mean that proxies already exist in the current file. If the file contains only a rule set, it will not generate proxies. Also check whether the client provides separate entry points for importing a complete configuration and importing a proxy subscription.

Proxies exist but the policy group is empty

A static policy group’s proxies list must contain proxy names, while a provider-backed policy group must reference the relevant provider through use. If a converter changes proxy names without updating group references, the client may report that the target does not exist. For regex-based policy groups, also check the filter expression; an overly strict filter can exclude every proxy.

The configuration starts, but every connection fails

First bypass complex rules and test connectivity by selecting one proxy directly. Check the system clock, server-name resolution, port reachability, TLS server name, and transport parameters. If only one protocol fails, compare its extension fields before and after conversion. If every proxy fails at once, check subscription expiry, the network route, DNS, and whether system-proxy capture is active.

Rule-mode traffic takes an unexpected route

Enable rule logging and confirm which rule actually matched. Do not infer the result only from entries that “should exist” in the rule file, because an earlier rule may already have matched. Check that rule sets updated successfully, behavior types are correct, policy targets point to the intended group, and the final fallback rule was not placed too early.

The same subscription behaves differently on different devices

Compare client version, core name, core version, and the subscription import path. Some clients perform their own conversion before import, while others pass YAML directly to the core. Mobile devices may also restrict background updates, VPN capture, and local-file access. Export the effective configuration from both sides or inspect startup logs instead of comparing only the subscription URL.

Can a Base64 subscription be used directly as a Clash configuration?

Not based on the encoding method alone. After decoding, it may contain line-by-line proxy links, YAML, or other text. The client must support both the decoded content format and the protocols it contains.

Can a Mihomo configuration be imported directly into an older Clash core?

Basic fields may be compatible, but Mihomo extensions for protocols, rules, DNS, and TUN may not be recognized by an older core. Remove or map fields according to the older core’s supported range, then revalidate rules and connectivity.

Do the original rules need to be preserved after subscription conversion?

It depends on the conversion target. If you only need proxy data, the local main configuration can manage rules centrally. If you are migrating a complete configuration, preserve the relationships between rule order, rule sets, and policy targets; do not copy only the rule text.

Why do subscription updates overwrite manual changes?

When you edit a downloaded subscription file directly, the next update usually writes the remote content over it. Put device-specific settings in a separate main configuration, reference remote proxies through a provider, or use the client’s supported override mechanism.

Final checklist for identifying subscription formats

After conversion, follow one consistent review path: confirm that the response is not a webpage error, identify its actual content type, verify the target core, sample-check protocol fields, validate proxy and policy-group references, inspect rule order, and test DNS and TUN separately. When something fails, return to the earliest layer where the anomaly appeared instead of repeatedly switching converters.

For most long-term setups, the most reliable structure is not to pack every option into a remote subscription, but to separate frequently changing proxy data from device-specific local settings. This lets you receive subscription updates while keeping verified rule chains, ports, DNS, and traffic-capture settings intact.