Clash Subscription URL Import Guide: Format Recognition & Conversion

Subscription links aren't all the same

A lot of people paste a subscription link straight into a client and end up with either an import failure or an empty node list. The client usually isn't at fault — the link's format simply doesn't match what the client expects. Subscription links roughly fall into three categories, and identifying the type first can save most of the troubleshooting time.

The first is a native Clash config link: requesting this URL returns YAML text directly, containing fields like proxies, proxy-groups, and rules — essentially a full Clash config file generated on demand by the server. This type is the least hassle for Clash and Clash Meta (mihomo core) clients: import and use, no conversion needed.

The second is a generic share-protocol aggregate link: the response is a bunch of vmess://, ss://, trojan://, and ssr:// node links concatenated together and then Base64-encoded as a whole. This format was originally designed as a common exchange format for clients like V2rayN and Shadowrocket. The Clash core itself doesn't understand it and it must be converted into YAML first.

The third is a relay link generated by a subscription conversion service: the user first feeds the original subscription into an online conversion backend, which then outputs a new URL — visiting that new URL returns YAML that Clash can read. The user experience is the same "direct import" as the first type, except there's an extra conversion server in between, and continued updates depend on that server staying online and working.

How to quickly identify the link type

If you're not sure which type you have, the simplest approach is to paste the link into a browser's address bar and see what the raw response looks like, then judge by the following:

• If the response starts with or contains proxies:, proxy-groups:, rules: and is readable key-value structure — that's native Clash YAML, use it directly.
• If the response is one long block of jumbled letters and numbers, with a length that's a multiple of 4 and possibly one or two trailing = signs — it's most likely a Base64-encoded node list that needs conversion.
• If you can visually see a large number of vmess://, ss://, trojan:// prefixes — that's an unencoded generic share-link aggregate, which also needs conversion.
• If the Content-Type response header is text/yaml or application/x-yaml, it's almost certainly a native Clash link; if it's text/plain, you'll need to check the content to decide.

If a browser isn't convenient, just paste the link into the client and try importing it once — most clients show an error message on failure, such as "unable to parse config" or "unsupported format," which can serve as a secondary clue.

Where to import on each client

Client interfaces differ quite a bit across platforms, but the import logic is essentially the same everywhere: "paste URL → name it → save and download."

Windows / macOS desktop clients

Look for an add-new entry on the config or subscription management page, paste the subscription URL, give it a recognizable name, and the client will immediately fetch the content once confirmed. If the client supports a custom update interval, it's worth setting it to every 12–24 hours to avoid stale node info from missed manual updates.

Android clients

On Android, there's typically an add button in the config or subscription list on the main screen, supporting either pasting a URL or scanning a subscription QR code. Scanning is handy when sharing from a computer to a phone, avoiding typos from manually entering a long link.

iOS clients

Most iOS clients rely on either the system share sheet or in-app pasting; some also support a Safari extension that detects subscription links on a page and imports them with one tap, skipping manual copy-paste entirely.

Converting generic share formats into a Clash config

If you've confirmed you have a vmess:///ss://-style aggregate link, there are generally two ways to handle it.

The first is using a subscription conversion service: pass the original subscription link as a parameter to a conversion backend, which parses each node's info and regenerates a Clash-readable YAML file, then hands the resulting URL back to the client as the new subscription. This barely requires any manual work, but it depends on the conversion server staying online long-term — if the service stops or gets rate-limited, the subscription fails along with it.

The second is manual local conversion: decode the Base64 content back into a plain-text node list, then rewrite each entry according to Clash's proxies field structure. Taking a Shadowsocks node as an example, a minimal Clash proxy entry looks roughly like this:

proxies:
  - name: "example-node-01"
    type: ss
    server: example.example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"
    udp: true

The upside of manual conversion is not depending on a third-party server; the downside is that it's easy to make mistakes or miss fields once you have a lot of nodes, so it's generally only recommended for a small number of nodes where you want long-term stability. For everyday use, a native Clash link or a reliable conversion service is still the better choice.

Worth mentioning here: Clash Meta (mihomo core) supports a wider range of protocols than earlier Clash cores, natively recognizing newer protocol nodes like Hysteria, TUIC, and VLESS — in many cases these no longer need any extra conversion and can be imported directly. If certain nodes consistently fail to be recognized on an older-core client, check first whether that client is actually running the Meta core.

Checklist for an empty node list after import

If you've confirmed the link type and even done the conversion, but the node list is still empty after import, work through the following steps in order — this usually pinpoints the issue.

1. Confirm the link itself is still valid. Open it in a browser to check whether it returns content properly, rather than a 404 or blank page — an expired plan or exhausted data allowance on the provider's side will take the subscription endpoint down directly.
2. Check for User-Agent restrictions. Some subscription servers judge the client type from the request header and reject requests from browsers or clients not on an allowlist. In that case, a link failing to open in a browser doesn't mean the subscription itself is dead — go by the update result inside the client instead.
3. Check the config format version. If the subscription content uses new fields or new proxy types the client doesn't support yet, parsing may skip the whole thing silently — updating the client version often fixes this.
4. Rule out a system-proxy loop. If the device already has a global proxy or TUN mode enabled, the request that fetches the subscription itself also gets routed through the proxy. If the active proxy node is down at that moment, the subscription update request fails right along with it — try turning the proxy off and updating the subscription manually to confirm.
5. Check the update timestamp. Clients usually show when the subscription was last updated. If the timestamp hasn't changed, the update request never actually succeeded — go back and check the first four steps one by one instead of repeatedly tapping the update button.

Habits that keep a subscription usable long-term

Getting a subscription imported successfully is just the first step. A few habits help over the long run: set a reasonable auto-update interval for each subscription so node info doesn't go stale; back up the raw subscription link text somewhere locally in case a config gets deleted by accident; if using multiple devices, stagger their update times a little to reduce simultaneous requests hitting the subscription server at once; and if every node stops working, check whether the subscription has expired before assuming the client itself is broken or switching providers.

Once these become habit, subscription-related issues can usually be self-diagnosed within a few minutes, without having to figure it out from scratch every time.