A subscription link is an address generated by a subscription service for compatible clients to read. When the client accesses it, it retrieves route names, server addresses, ports, protocol parameters, group information, and more, then organizes them into a list of routes you can select and connect to. You do not need to copy nodes one by one, but you should protect the address like account credentials rather than treating it as an ordinary web link.
The subscription link itself usually does not establish a network connection. The client handles the handshake, encryption, routing, and DNS processing, using protocols such as Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC described by the subscription. Understanding this distinction explains many common situations: opening the subscription address in a browser does not guarantee client compatibility, and a successful import does not mean all system traffic is following the intended route.
What exactly does a subscription link contain?
At first glance, a subscription link is simply an HTTPS address. From the client’s perspective, it is an updatable configuration endpoint. The client requests content from that endpoint, and the server returns a set of routes based on the subscription status. The response may be an encoded node list, YAML, JSON, or a client-specific configuration. These formats are not automatically interchangeable, so the same service may provide different endpoints for different clients.
A single-node link is not the same as a subscription link. Content beginning with ss://, vmess://, trojan://, vless://, hysteria2://, or tuic:// usually describes one specific route. A subscription address returns multiple routes at once and lets the client fetch them again after server-side changes. Some subscriptions encode multiple single-node links together, while others provide a complete policy configuration.
| Content type | Primary purpose | Update method | What to watch for |
|---|---|---|---|
| Single-node link | Import one specified route | Usually requires retrieving and importing it again | Does not include the full route set |
| Universal subscription | Provides a route list for compatible clients | The client fetches the subscription again | Split-routing rules may be managed separately by the client |
| Client-specific subscription | Provides routes, groups, and policy settings | Updated through the corresponding client | May be incompatible when imported into another client |
| Local configuration file | Stores imported settings or manual rules | Maintained locally by the user | Does not automatically receive server-side changes |
Protocols and route types should also be understood separately. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC describe communication methods and their parameters. IEPL, relay routes, and direct routes mainly describe how traffic reaches an overseas exit. IEPL typically carries the cross-border segment over carrier-managed dedicated resources; a relay route enters through an intermediate gateway before reaching the exit; a direct route reaches the overseas server directly from the local network. A subscription link can include all of these route types, but it does not remove their differences in routing, congestion behavior, or suitability for different uses.
Get it from the dashboard and store it securely
To get a subscription link, sign in to the service dashboard and open the download or subscription section. Choose the format that matches your current client, then use the copy button. Do not rely on search results, forwarded chat messages, or short links from other people. VPNGP works with a username and password, with no email address required; the link obtained from your own dashboard corresponds to your current subscription.
If the dashboard offers both a universal subscription and a client-specific configuration, prioritize the option explicitly supported by your client’s documentation. A dedicated configuration may include policy groups, DNS settings, and rule providers; a universal subscription is easier to move between clients but may contain only nodes. Renaming a dedicated format with another file extension does not convert it.
- ✅ Confirm that the address comes from your own VPNGP dashboard and check the selected client format.
- ✅ Prefer “Import from URL” or “Add subscription” in the client instead of parsing parameters manually.
- ✅ Give the subscription a local name that identifies its source so it is easier to select correctly later.
- ✅ After importing, clear temporary text, shared clipboard contents, and screenshots containing the full link.
- ❌ Do not forward the subscription address as if it were an ordinary download link.
- ❌ Do not submit the full subscription address to online conversion tools from unknown sources.
HTTPS protects the transfer from ordinary plaintext interception, but it does not make the address safe to publish. As long as the full token remains valid, anyone who obtains the link may be able to read its configuration. Browser history, cloud clipboards, terminal command history, and automatically synced notes can all widen the exposure. A safer approach is to copy the link directly from the dashboard into a trusted client and delete intermediate copies afterward.
How to import on five platforms
Button names vary by platform, but the core process is the same: choose a compatible client, add a remote subscription, paste the link, save and update it, then select a route and connect. After importing, also check the system proxy, virtual network interface, and split-routing mode. Seeing node names alone does not prove that the network is being handled as intended.
Windows
In a Windows client, find the subscription or configuration management section, choose the option to add a URL, paste the link, and run an update. Then confirm that the newly imported configuration is active, and enable the system proxy or TUN mode as needed. The system proxy mainly handles apps that follow proxy settings; TUN mode processes more traffic through a virtual network interface, but may require higher privileges and can conflict more easily with other network-filtering software.
If a browser works but a desktop app does not, first determine whether the app ignores the system proxy. Do not repeatedly delete the subscription. Check the client mode, bypass list, and system routes instead. Test again after switching modes to distinguish a node problem from a local traffic-capture problem.
macOS
Importing on macOS is similar to Windows: add the URL from the remote configuration or subscription section. After saving, allow the client to create the required network configuration and confirm that the menu-bar status matches the policy selected in the client. Some apps follow the system proxy, while others need a virtual network interface to be captured. “Connected” in the client and “all app traffic is using the route” are therefore two different conclusions.
If a system update or client upgrade revokes network-extension permission, the old subscription usually remains, but connections may fail. Check system permissions and extension status first instead of immediately resetting the subscription link.
Android
Android clients generally support importing from the clipboard, adding a URL, or scanning a QR code. After adding it, update the subscription, select a node, and authorize the VPN connection. If you need per-app routing, specify which apps should use the route and which should connect directly. After changing the app list, check that the rules still match your actual needs.
Battery-saving policies may pause the client process, causing the connection to fail after switching apps or the system to establish the network again. Check the client’s background permissions and the system’s battery management instead of using subscription updates as a keep-alive mechanism. The subscription supplies configuration; background policies determine whether the client can keep running.
iOS
iOS clients usually import subscriptions by pasting the address, opening a supported URL, or scanning a QR code. On the first connection, the system asks for permission to add a network configuration. If the subscription QR code is displayed on the same device, copying the address is often more convenient than scanning. After copying, avoid leaving the full link in a cross-device clipboard for an extended period.
If importing produces nodes but not the expected policy groups, a common reason is that you used a universal node subscription while the client requires a dedicated configuration. Return to the dashboard and choose the matching format instead of manually adding unfamiliar rules in the client.
Linux
Linux offers both graphical clients and command-line cores. A graphical client can usually add a remote subscription directly; in a command-line environment, you may need to download the configuration first and have the core read a local file. When running a download command, remember that the shell history may preserve the full parameter, so do not place the subscription address directly in shareable scripts, logs, or public configuration repositories.
When running as a system service, also confirm that the service account can read the configuration file, that DNS and routing commands have the required permissions, and that proxy variables in the desktop session match the system service configuration. The most common Linux misdiagnosis is that the core is running while apps still use the old environment variables or DNS path.
Post-import verification order
Was the subscription updated successfully?
Is the current configuration active?
Can the target route establish a connection?
Is the system proxy or virtual interface enabled?
Do split routing and DNS behave as expected?How often to update, and what updates change
There is no fixed update schedule that applies to every client. Automatic updates depend on client settings, configuration format, and runtime status. Some clients check only at startup, some support background fetching, and others rely entirely on manual updates. A more reliable rule is to update when the dashboard reports route changes, the node list is clearly outdated, the current route stops working, or the service asks you to refresh it.
During an update, the client revisits the original subscription address and refreshes the route set with the latest remote content. Node names, server addresses, protocol parameters, groups, and remote rules may all change. The exact scope depends on the format: a universal subscription containing only nodes usually does not manage local split routing, while a complete configuration may overwrite policy groups, DNS, and rule settings within that configuration.
This is why manual changes are easy to lose. If you edit nodes generated by a remote subscription directly, the client may rebuild the configuration from server-side content during the next refresh. Long-term local rules should go in an override, merge, or local configuration layer explicitly supported by the client. If the client offers none of these, keep a rule backup that does not contain subscription credentials.
- ✅ Before updating, confirm that you are working with the correct subscription to avoid same-name configurations overwriting each other.
- ✅ After updating, review added, removed, and renamed routes, then select your policy again.
- ✅ Keep local split routing in a client-supported override layer and document each rule’s purpose.
- ✅ If the node list looks abnormal, refresh it manually before deciding whether to import again.
- ❌ Do not use repeated refreshes to solve system permissions, routing conflicts, or background-pausing issues.
Verify routing and DNS after importing
A client showing latency or “connected” only means that a particular test request succeeded. It does not mean every app is using the expected path. First define the goal: full traffic capture, domain-based split routing, or routing only for selected apps. Each goal requires different checks, so do not stop after checking the exit address.
Split-routing rules generally use domains, IP addresses, apps, or rule sets to decide between direct and proxied connections. When rules are matched from top to bottom, a broad rule may intercept a request before later rules can take effect. Domain rules can also be affected by DNS resolution: if the client sees only the resolved IP while the rule specifies a domain, the result may differ from what you expect.
A DNS leak usually means that a query which should have been resolved through a controlled path was sent to another DNS resolver. This is not the same as intentionally sending some traffic directly according to the rules: direct DNS can be a deliberate configuration choice, while a query leaving the tunnel unexpectedly is what needs investigation. Check whether the client uses system DNS, proxy DNS, encrypted DNS, or virtual resolution, and confirm that the query path matches the split-routing goal.
| Symptom | Check first | Do not do this first |
|---|---|---|
| Nodes are visible but cannot connect | Protocol compatibility, system time, network permissions, and route status | Repeatedly import the same subscription |
| The browser works but other apps do not | System proxy, TUN mode, and the app’s own proxy settings | Assume the subscription content is wrong |
| Some domains do not follow the routing rules | Rule order, domain resolution, and cache | Only switch nodes without checking the rules |
| Local changes disappear after an update | Remote configuration scope and the override mechanism | Continue editing nodes that will be replaced by the refresh |
| The update reports that the format cannot be parsed | Subscription type and the formats supported by the client | Only change the file extension |
Route selection should also follow the intended use. Direct routes have a simpler structure, but their cross-border segment is more exposed to public-network routing. Relays can improve the entry path but add an intermediate hop. IEPL focuses on how the cross-border segment is carried. In practice, configure split routing and DNS correctly before comparing routes. Otherwise, changing the node, protocol, traffic-capture mode, and DNS all at once makes it difficult to identify what caused the difference.
How to reset and recover after a leak
If a subscription link has been posted publicly, sent to unrelated people, submitted to an untrusted conversion page, or recorded in a log that cannot be withdrawn, treat it as a credential leak. Deleting the public copy is not enough because the link may have been copied or cached. Deleting the configuration from a local client also does not invalidate the old address.
- Sign in to the VPNGP dashboard and use the subscription reset or regeneration option to invalidate the old address.
- Delete the old remote subscription from your own clients so they stop requesting an address that is no longer valid.
- Get a new link in the matching format, import it again, and confirm that the configuration updates normally.
- Check your other devices and replace any configuration that still references the old address.
- Clear the full old address from browser history, clipboard sync, terminal history, notes, and screenshots.
- Review split routing, DNS, and local overrides again so that incorrect settings are not carried into the new configuration.
Resetting a subscription usually changes the credentials used to access the configuration; it does not automatically repair local rules in the client. If you changed DNS, the system proxy, or routing while troubleshooting, check each item again after reimporting. For users with multiple devices, leaving one device unchanged may cause continued update failures, but that is not a reason to restore the old link.
If you only deleted the local subscription and the link was never exposed, you usually do not need to reset it. Copy it again from the dashboard and reimport it. The key question is not whether the client still contains the link, but whether an untrusted party may have obtained the full address. This avoids unnecessary configuration migration while ensuring that a real leak is cut off promptly.
Common questions and final checks
Is it normal for a subscription address to open as a block of characters in the browser?
This is usually normal. Subscription responses are designed for clients and may be encoded, or may return YAML, JSON, or a collection of node links that is not intended for browser reading. What matters is whether the client supports the format and can parse it correctly after import. Do not submit the full response to an online decoder just to make it easier to read.
Can I import a subscription link into multiple clients at the same time?
That depends on the service rules and format compatibility. Even if multiple clients can read the same address, their implementations of policy groups, DNS, rule providers, and protocol features may differ. When moving between platforms, select the corresponding format from the dashboard instead of assuming the original address will behave identically everywhere.
Why are there fewer routes or different names after an update?
A remote subscription reflects the configuration currently provided by the service. Route maintenance, gateway changes, naming cleanup, or format changes can alter the list. First confirm the update time and subscription source, then check the dashboard notes. Do not judge completeness by node count alone, and do not treat an old cache as a valid configuration indefinitely.
Which is safer, a QR code or a text link?
Both usually carry the same credentials; the risk depends on how they are displayed and stored. QR codes can be captured from a screen, while text can enter clipboards, history, and sync tools. Choose the method that minimizes intermediate copies, and clear temporary content after importing. That matters more than comparing the formats themselves.
Will updating the subscription change the current route?
If the current route is removed, renamed, or moved to another policy group in the new configuration, the client may return to its default selection. If the route remains, the behavior depends on how the client merges updates. Check the active policy after refreshing instead of assuming the previous selection will remain.
- ✅ The subscription source, format, and client are compatible.
- ✅ The current configuration is active, and the traffic-capture method meets the app’s needs.
- ✅ The split-routing rules explain which requests connect directly and which use a route.
- ✅ The DNS query path matches the split-routing goal.
- ✅ Local overrides and remote subscriptions are stored separately so updates do not overwrite each other.
- ✅ The full link is stored only in controlled locations and reset immediately after exposure.