A subscription link is a tokenized address. The client fetches it and decodes it into a server list: server address, port, protocol, encryption method, and transport parameters are all inside. That makes it two things at once — a source of configuration and an account credential.
Most people treat it like an ordinary URL: copy it, paste it, forget it. Then they switch devices, a server dies, or someone else sees the link — and only then does it become clear that this string needs managing. The five sections below break it down — what it is, where to get it, how to import it, how often it updates, and what to do if it leaks — with concrete steps for each.
Subscription link anatomy: four layers of data and one token
The skeleton of a subscription link is plain: a domain, a path, and one token parameter.
https://sub.example.com/summit/2024/client/subscribe?token=9f2c8a1e4b7dThe domain and path are set by the server; the token is a random string tied to your account, usually a UUID or a 32-character hex value. The server validates the token first, then generates the node list for that account's status (whether the plan is active, whether data is used up). A wrong token returns 403 or an empty list; a valid token on an expired plan can also return an empty list.
The response comes in one of two common formats. One is Base64-encoded multi-line URIs: decode it and each line is a single node, prefixed with ss://, vmess://, trojan://, vless://, hysteria2://, or tuic://. The other is YAML, which Clash and Mihomo clients read; it has three sections: proxies, proxy-groups, and rules.
Take any node line apart and you'll see four layers of data:
- Protocol and credentials: the encryption method and password for Shadowsocks, the UUID for VMess and VLESS, the password for Trojan, the password for Hysteria2 and TUIC.
- Entry address: the server domain or IP plus port. It may be a direct entry or a relay entry; the two look identical in the client, but the actual path differs.
- Transport parameters: path and host for WebSocket, serviceName for gRPC, SNI and ALPN for TLS; TUIC also carries a congestion-control algorithm.
- Token: it exists only in the subscription link itself and is never written into any node line. That's why sharing a single node leaks little, while sharing the whole subscription link hands over your account.
| Aspect | Subscription link | Single-node link |
|---|---|---|
| Content | A list of servers that changes with account status | One fixed server |
| Format | An HTTPS URL that returns Base64 text or YAML | A single-line URI such as ss:// or vmess:// |
| How it updates | The client pulls on a schedule; server-side changes sync automatically | Replaced by hand; a new entry means re-importing |
| If leaked | Works as an account credential and can be reused long-term | Affects one server, but can still be reused |
| Best for | Multiple devices, servers that change often | Quick tests, one fixed machine |
Where to get it: legitimate sources and high-risk sources
A subscription link legitimately appears in only three places: your own account panel with the provider, a server panel you built yourself, and an official backup domain from the provider. Any other source deserves a question mark first.
Provider panel
With VPNQF, for example, you log in to the panel and copy the full link or save the QR code from the subscription page. Creating an account here takes only a username and password — no email address — so subscription links are never sent by email, which removes one leak channel; the trade-off is that if you lose the link you go back to the panel to copy it again rather than digging through your inbox.
Self-hosted server
When you build your own with a panel, the subscription entry usually sits on a "Clients" or "Subscription" page, and the generation rules depend on the panel's configuration: some generate one master subscription per user, others generate one per protocol. The upside is that you hold the token yourself; the cost is that you handle server maintenance and certificate renewal.
High-risk sources
The problem with "public subscriptions" passed around forums, group chats, and public repos isn't that they're necessarily malicious — it's that you can't verify anything: whose server your traffic crosses, whether they log destinations, when the link will die. These addresses usually stop working within days and are strictly disposable; they don't belong on a device you use every day.
- ✅ Copy from your own account panel, then check that the domain is the provider's main domain or an official backup
- ✅ Store the link in a password manager or an encrypted local note, not in a chat window
- ✅ When you switch devices, fetch it again from the panel instead of reusing a link from an old screenshot
- ✅ If the main domain fails to resolve, switch to the backup subscription address instead of searching for a "latest working subscription"
- ❌ Don't use public subscriptions of unknown origin; you can't confirm whose server your traffic crosses
- ❌ Don't post the full link in group chats, public repos, or ticket screenshots
- ❌ Don't run your link through a third-party "subscription converter"; the converter service receives the original address
How to import: paths for five platforms
Whatever the client, importing follows the same five steps; only the location of the entry point differs.
- Copy the subscription link from the panel, or save the QR code.
- Open the client and find the "Subscription", "Profiles", or "Config" section.
- Create a new entry, paste the link, and give it a name you'll recognise — by purpose or by device.
- Save, then hit "Update" once manually and confirm the node list isn't empty.
- Connect through one server, open a page that shows your exit IP, and confirm the exit is no longer your local network.
| Platform | Common clients | Import entry point | Watch out for |
|---|---|---|---|
| Windows | v2rayN、Clash Verge | Subscription group settings / Profiles → New | You have to click Update again after pasting, or the list stays empty |
| macOS | ClashX Meta、Stash | Menu bar → Profiles → Managed Profiles | The first import asks for network permission; if you deny it, the fetch fails |
| Android | v2rayNG、Clash Meta | Side menu → Subscription settings | Background running must be allowed, or scheduled updates won't run |
| iOS / iPadOS | Shadowrocket、Stash | Home → Add subscription | App Store availability varies by region |
| Router | OpenClash、PassWall | Config file subscription | Router memory is limited; with many nodes, keep only the groups you use |
Three checks after importing
First, the node count matches what the panel shows; if it's short, the fetch was incomplete — update again. Second, connect through any server, open a page that shows your exit IP, and confirm the exit has changed. Third, don't take the latency numbers in the client too seriously: that's a single handshake from your device to the entry, and it says little about real download speed or peak-hour performance. Relay routes whose entry point is in mainland China often show low latency, but speed depends on exit bandwidth.
One more thing people overlook: DNS. If a Clash-style subscription includes a dns section, check that the nameserver entries aren't your local ISP's resolvers; with local resolution, domain lookups travel outside the tunnel — the classic DNS leak. Default client configs aren't right for every network, and a minute of checking after import saves a lot of troubleshooting later.
How often it updates: client schedule and server-side changes
A subscription isn't a live push. Add a server in the panel and it won't appear in the client immediately; it waits for the next fetch, or for you to click update. So "how often does it update" is really two questions: how often the client pulls, and when the server side changes.
Default client intervals
Clash and Mihomo clients read the profile-update-interval response header from the server, commonly 24 hours; v2rayNG, Shadowrocket, and similar clients offer their own auto-update toggle and interval per subscription entry. 24 hours is enough for daily use; if servers change often you can drop to 6 hours, but don't push it to every few minutes — servers usually rate-limit fetches, and once you hit the limit the client just reports a failed update, which makes diagnosis harder.
When the server side changes
- Servers are added or retired, so the node count changes.
- The entry address changes, for example a new relay entry or a new domain.
- Certificate rotation, with TLS parameters updated along with it.
- The plan expires or data runs out, so the list empties or keeps only an informational node.
When every node times out, the right order is to update the subscription manually once, then check whether a single server is at fault. If the list looks fine after updating but you still can't connect, the problem is the route or your local network, not the subscription.
What you can pull depends on the server pool tied to your account. VPNQF subscriptions cover 90+ countries and 220+ routes, with no limit on simultaneous devices, and a 60-day money-back guarantee if you're not satisfied.
After a leak: token reset and the order of damage control
The token in a subscription link is a credential. Anyone who has it can pull the same node list and use your data without your username or password. This service doesn't limit simultaneous devices, so someone else using it won't kick you offline — but the data comes from the same pool, and the usage counts against your account.
If you find the link posted publicly, work through the steps below in order. Note that changing your password first won't help — a new password doesn't invalidate the old link.
- Reset the subscription token in the panel, or click "Reset subscription URL". This makes the old link return an error immediately, and every client still using it fails to update.
- On each device, delete the old subscription entry, paste the new link, and update manually once.
- Watch data usage for a day or two and confirm there's no unusual growth.
- Then trace the leak: a screenshot, a chat log, or an online converter service.
Common misconceptions and a self-check list
Myth 1: a subscription link is a node link
No. A subscription link points to a list; a node link is one line in that list. The former changes with account status, the latter is one fixed server that has to be re-imported when the entry changes.
Myth 2: updating a subscription uses plan data
It doesn't. What comes back is a piece of text, usually a few KB to a few tens of KB — about the same as loading a web page — and it isn't counted against your plan.
Myth 3: if the link opens, the servers work
Not necessarily. Pulling a config only proves the token is valid and the account is in good standing; whether a server actually connects takes a real connection to find out. Conversely, a link that won't open doesn't always mean a dead token — first check whether your local network can reach that domain.
- ✅ The subscription link lives only on your own devices and in your password manager
- ✅ Import it separately on each device, with a name that includes the device or purpose, so you can match things up at a glance when troubleshooting
- ✅ Keep the 24-hour auto-update on; when you can't connect, update manually once before diagnosing
- ✅ When you change devices or suspect a leak, reset the token in the panel first, then re-import
- ❌ Don't paste the full link into chats, screenshots, or public repos
- ❌ Don't forward the subscription link to a friend to "borrow"; the data and the responsibility both sit on your account