How subscription conversion works — the mechanics, the uses and the risk you should not ignore

"Subscription conversion" is a step many people cannot avoid: the provider only offers v2ray format, the client wants Clash format, and a conversion service sits in between.

This explains what it does, what the risks are, and how to use it less — or not at all.

Why the thing exists

Different clients eat different formats:

What a conversion service does:

Where the risk lies

Concretely:

Also, the configuration a converter returns contains a rule template. If the template's origin is not trustworthy, arbitrary rules can in principle be inserted — pointing certain domains at a particular node, for instance.

When conversion is genuinely needed

First check whether you actually need it:

Plenty of people do not realise their provider already has a Clash-format link. Look carefully in the dashboard; there are usually buttons for several formats on the subscription page, or appending ?flag=clash to the same link yields Clash format.

Cases where conversion genuinely helps:

• The provider really does only offer v2ray base64, and your client cannot read it
• You need to merge several subscriptions in different formats into one
• You want a ready-made rule template, and the provider's config has no rules

Safer alternatives

Option 1: write your own config and pull nodes with proxy-provider

If your provider offers Clash format, the cleanest approach is to write the main config yourself (groups and rules entirely under your control) and pull nodes through proxy-providers:

proxy-providers:
  main:
    type: http
    url: "your subscription URL"
    interval: 3600
    path: ./providers/main.yaml
    header:
      User-Agent: ["clash.meta"]
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: "PROXY"
    type: select
    use: [main]
    proxies: ["AUTO", DIRECT]
  - name: "AUTO"
    type: url-test
    use: [main]
    interval: 300
    tolerance: 50

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Only your client ever sees the subscription URL; no third party is involved.

See managing and merging multiple subscriptions.

Option 2: use the client's extended config

The provider's Clash config has thin rules? You do not need conversion — top them up locally with the Merge extended config:

prepend-rules:
  - RULE-SET,my-proxy,PROXY
  - RULE-SET,my-direct,DIRECT

rule-providers:
  my-proxy:
    type: http
    behavior: domain
    url: "rule set address"
    path: ./ruleset/proxy.txt
    interval: 86400

Rule sets are public domain lists containing nothing private, so hosting them elsewhere carries no risk.

Option 3: self-host a converter

If you genuinely need conversion but would rather not hand your nodes to anyone, run your own. Common open-source implementations start with a single Docker command:

docker run -d --name subconverter \
  --restart always \
  -p 25500:25500 \
  a-converter-image

Then use http://127.0.0.1:25500/sub?... as the conversion address.

The benefit of self-hosting: node information never leaves your own machine. The cost is a service to maintain.

If you must use a third-party converter

"Generate once" is the key idea: letting the client request the conversion address indefinitely means giving a third party ongoing access to your nodes. Convert once, take the YAML, save it locally and maintain it yourself — the exposure is a single moment.

Inspecting the result

Once you have the converted config, look at three places at minimum:

1. Anything suspicious in the rules section

rules:
  - DOMAIN-SUFFIX,an-unfamiliar-domain,a-specific-node   # ← be wary of this

A normal rule template does not point a specific domain at one particular node.

2. Extra nodes in the proxies section

Compare against the node count in your original subscription. Where did any extras come from?

3. Where the rule-providers urls point

Rule set addresses should be public rule repositories, not odd-looking domains.

On "your subscription URL is a credential"

Worth restating:

So:

• Do not post it in public groups, forums or issue trackers
• When sharing screenshots of the client, blur the subscription field
• Do not import it on a device you do not trust
• Reset it in the provider's dashboard the moment you suspect a leak

In short

• First check whether your provider has a Clash-format link — they probably do, and then you need no conversion at all
• A conversion service sees all of your node credentials, which is its biggest risk
• Prefer proxy-provider plus a local config, so the subscription URL touches no third party
• Use public rule sets for rules; those contain nothing private, so third-party hosting is fine
• If conversion is unavoidable, self-host — or at minimum "generate once" rather than requesting indefinitely

Related: managing several subscriptions and the Merge extended config.

Related docs

Config Basics The YAML structure of a Clash config — what each of the eight top-level fields does

A Clash / Mihomo config taken apart from top to bottom — ports, mode, DNS, proxies, proxy-groups, rules and rule-providers — with a minimal working config you can paste straight in.

2026-08-021280 words3 min read

Config Basics The five proxy-group types — select, url-test, fallback, load-balance and relay

What each policy group actually does, when to use it, the parameters that matter, plus a grouping structure you can copy wholesale and Mihomo's include-all and filter options.

2026-07-291335 words3 min read

Config Basics Extending a subscription with Merge, so your edits survive updates

Editing the downloaded config gets undone at the next update. How Clash Verge's extended config works: prepend/append/override syntax, merge order, and a set of useful snippets.

2026-07-091192 words3 min read