What is a subscription link? How to get, import, and update it
A practical guide to subscription links: what they are, where to find them in your account panel, how to import them, when they update, what leaks mean, and how to reset them.
What is a subscription link? In simple terms, it is the entry point clients use to retrieve remote node configurations. The service organizes available routes, protocol parameters, and required connection credentials into data the client can parse. The client fetches that data from the link and turns it into a selectable node list. It is not a bookmarked webpage or an ordinary download link, nor is it the same as a specific route.
For people using cross-border networking tools for the first time, the relationship between an account, a subscription, and a node is often confusing. The account manages service status; the subscription delivers configuration to the client; and the node is the server endpoint selected to establish a connection. Understanding these three layers makes importing, updating, troubleshooting, and handling leaks much clearer.
What a subscription link contains
A subscription link usually combines a service address with an unpredictable identifier. After the client sends a request, the server uses that identifier to return the relevant configuration. The response may be encoded or formatted as YAML, JSON, or a client-specific format, so seeing garbled text, a long string, or structured data after pasting the address into a browser is not necessarily an error.
Configuration usually describes node names, server addresses, ports, transport methods, protocol types, authentication fields, and connection parameters such as TLS. Some subscriptions also include groups, policies, or routing rules, depending on the format and the client. A subscription is not a proxy protocol; it is a configuration-delivery mechanism. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are examples of protocols or protocol combinations a client may recognize.
| Object | Primary purpose | Where it is usually stored | What to watch for |
|---|---|---|---|
| Account | Check service status, retrieve configuration, and request support | The provider’s account panel | Protect login credentials and verify that you are using the correct panel |
| Subscription link | Distribute and update route configuration for clients | The account panel and the client’s subscription list | Treat it as sensitive credentials; do not share it publicly |
| Node configuration | Provide the server and protocol parameters needed for an actual connection | The client’s local configuration | Expired configuration may still be displayed but may no longer connect |
| Routing rules | Decide which requests connect directly, use the proxy, or are blocked | The client’s local rules or a rules subscription | Updating route subscriptions does not necessarily change local rules |
It is important to distinguish a route subscription from a rules subscription. The former provides connection nodes; the latter provides matching rules for domains, IPs, or application traffic. A client can use both, but they solve different problems. If a route subscription updates successfully while split-tunneling rules remain wrong, some websites may still use the wrong egress; conversely, correct rules cannot repair invalid node credentials.
Conclusion: A subscription link is an entry point for distributing configuration, not a node itself or a connection switch. The client must first fetch and parse the configuration successfully, then select a node and operating mode before network requests are routed according to the rules.
How to get a subscription from your account panel
Get the subscription address from the provider’s official account panel, not from chat history, search results, or configuration shared by someone else. After signing in, common entry points include “Subscriptions,” “Client configuration,” “Quick import,” and “Connection information.” The exact wording may vary by panel version, but copy-link, client-import, and subscription-reset options are usually located near one another.
Before copying, confirm the required format. Some panels offer a universal subscription, while others output different formats for different clients. Choosing the wrong format usually causes a parsing error, empty subscription content, or missing protocol fields—not simply a slow connection. In that case, return to the panel and select a compatible format instead of manually deleting or changing the identifier in the link.
- Use a trusted entry point to open the account panel, and check the browser address and secure connection status.
- Open the subscription or client-configuration area, then choose a format compatible with your platform and client.
- Use the panel’s copy function to obtain the complete address, avoiding missing characters at the end during text selection.
- Switch directly to the target client to complete the import. Do not paste the address into a group chat, shared notes page, or public document first.
- After importing, run one manual update and confirm that the client displays node names and protocol types.
- ✅ The link comes from the official account panel, not a screenshot or text forwarded by someone else.
- ✅ The copied content includes the complete protocol scheme, domain, path, and identifier.
- ✅ The selected subscription format matches a format supported by the client.
- ✅ After a successful import, you can refresh it manually and see a clear update time or success status.
- ❌ Do not publish the subscription address as an ordinary URL in forums, support-ticket screenshots, or code repositories.
How to import subscriptions into clients on each platform
Button locations differ across platforms, but the workflow is broadly the same: create a subscription configuration, paste the address, save and update it, then select a node to connect. Do not paste a subscription address into a “single-node import” or “scan node QR code” field; those entry points usually accept one specific protocol configuration and cannot process a remote subscription.
Windows and macOS
Desktop clients usually place subscription management under Configuration, Subscription Groups, or Profiles. When creating a remote configuration, give the subscription a recognizable name, paste the address, and run an update. After importing, check the log or status bar to confirm that the content was fetched and parsed successfully—not merely that the address was saved.
Desktop systems also require attention to proxy mode. The system proxy is generally suitable for browsers and apps that follow system settings; virtual network interface mode can handle more traffic but requires the appropriate client permissions. A subscription provides route parameters; it does not automatically decide which apps should connect directly or through the proxy.
Android
Android clients often place remote subscriptions under Configuration, Groups, or Profiles. After pasting the address, update the list first, then grant the system permission required to establish a VPN connection. If the client supports per-app routing, check whether the target app is included in the proxy scope. If the subscription updates successfully but the app remains inaccessible, also check per-app routing and DNS settings.
iOS and iPadOS
On these platforms, clients generally import subscriptions through a remote-configuration or subscription entry and request permission to add a system VPN configuration on the first connection. System authorization only means the client may create a network tunnel; it does not confirm that the subscription is valid. After importing, check the node list, update time, and connection log.
| Platform | Common entry points | What to check after importing | Common omission |
|---|---|---|---|
| Windows | Subscription management, remote configuration | Update log, system proxy, or virtual network interface status | The subscription was saved but never updated |
| macOS | Profiles, subscription groups | System authorization, proxy mode, and node list | The app is still using the old configuration |
| Android | Configuration, groups, remote subscriptions | System VPN permission and per-app routing | The target app was set to connect directly |
| iOS / iPadOS | Remote configuration, subscriptions | System VPN configuration and update time | The subscription was imported but the connection was never started |
Client compatibility cannot be judged solely by the words “supports subscriptions.” The client must also parse the protocols and transport parameters used inside the subscription. For example, a client may be able to request the subscription address but not recognize Hysteria2 or TUIC configurations; it may support VLESS but not the specific transport combination used by the server. In such cases, some nodes may be missing, and logs often show entries such as skipped, unknown type, or parse failure.
How to tell the import is complete: The client has successfully fetched the remote content, parsed the nodes correctly, displayed recognizable protocols and route names, and produced normal logs after the connection starts. Seeing only “subscription saved” is not enough.
How often to update a subscription
There is no automatic update interval shared by all clients. The schedule depends on client settings, system background restrictions, and the server response. Some clients check at launch, some support periodic refreshes, and some mobile systems do not run them as expected in the background. As a result, there may be a delay between routes being changed in the panel and the new configuration reaching the local client.
The most reliable approach is to manually update the subscription and reselect a node whenever node names, route status, or configuration differs from the panel. Disconnecting and reconnecting alone usually continues using the local cache and may not trigger a remote fetch. Clearing the client cache should not be the first step, because it may also remove local rules and custom groups.
What the client actually does during an update
An update usually requests the subscription address, validates the server response, decodes or parses the configuration, writes it to the local database, and then replaces or merges the old list with the new one. Failure at any stage can leave the old nodes visible. Some clients retain the last successful configuration so a brief network issue does not empty the list, which is a common reason nodes remain visible after an update fails.
If routes have changed in the panel but the client remains completely unchanged after a manual refresh, check the subscription format, client logs, system time, network connectivity, and local cache in that order. Do not refresh repeatedly in quick succession; repeated requests cannot fix an incompatible format and may bury the original error beneath later log entries.
How to troubleshoot subscription failures and import errors
Break troubleshooting into three categories: request failure, parse failure, and connection failure. They occur at different stages and require different remedies. A request failure means the client did not receive the configuration; a parse failure means it received content but could not recognize it; a connection failure means the configuration reached the client, but the node handshake or local network path has a problem.
| Symptom | Likely stage | Check first | Recommended action |
|---|---|---|---|
| Network error or request timeout | Requesting the subscription | Current network, address integrity, and system time | Test on an available network and copy the complete address again |
| Empty response or unrecognized format | Parsing configuration | Subscription format, client version, and protocol support | Select a compatible format in the panel and import it again |
| Nodes are present but none can connect | Establishing the connection | Client logs, local firewall, and network restrictions | Switch routes first, then use the handshake error to narrow down the cause |
| Only some nodes are missing | Parsing or filtering | Protocol compatibility and group-filter conditions | Check skipped entries in the log and the client’s capabilities |
| Some websites still use the local egress after connection | Routing and DNS | Operating mode, matched rules, and DNS settings | Review routing logs and run a DNS leak test |
IEPL dedicated lines, relay routes, and direct routes describe network paths, not subscription formats. A direct route reaches the remote endpoint through the local network; a relay route first enters an intermediary node and then continues to the destination egress; IEPL is a dedicated network solution for specific cross-border transmission scenarios. These routes are usually imported in the same way; the main differences occur in server-side routing and the actual transmission path.
When the connection succeeds but access results are unexpected, inspect routing and DNS next. Global mode sends more traffic through the proxy, while rule mode selects a path based on domain, IP, or application matches. If DNS queries leave through an unintended network egress, DNS leaks may occur, causing resolution results to differ from the proxy egress. Repeatedly updating the subscription cannot fix this; adjust the client’s DNS mode and routing rules instead.
- ✅ First determine whether the error occurred during fetching, parsing, or connecting.
- ✅ Check status codes, format errors, and protocol messages in the client log.
- ✅ After a manual refresh, confirm that the update time actually changed.
- ✅ Check system time, proxy mode, routing rules, and the DNS path.
- ❌ Do not reinstall the client, delete rules, and reset the subscription all at once before identifying the cause.
What happens after a subscription link leak
A subscription link should be managed like an access credential. Anyone with the complete address may be able to read the node configuration associated with it and fetch it repeatedly until the link expires. If the service uses the subscription to identify usage rights, a leak may also lead to unusual traffic consumption, repeated fetches, or further distribution of the configuration. HTTPS protects the transfer in transit, but it cannot stop someone who receives the link from using it.
Common leak scenarios include posting complete client logs publicly, submitting screenshots that show the subscription address, uploading configuration files to a public code repository, saving the original address in shared notes, or retaining it in browser sync history. The priority is not to delete local chat history and continue using the link; reset the subscription credential in the panel so the old address stops working.
- Stop copying or testing the leaked address to avoid expanding its reach.
- Open the official account panel and use the reset-subscription or regenerate-link function.
- Delete the old subscription from every personal client and import the new address generated by the panel.
- Update manually and confirm that the new subscription returns configuration normally.
- Verify that the old address can no longer retrieve valid configuration; if it still works, contact support.
- Remove the original link from public pages, shared documents, screenshots, and logs.
After a reset, clients that imported the old link will not automatically learn the new address. Even if old nodes remain locally, they may lose connection capability after the server-side credentials change. Replace the subscription on each device instead of resetting it only in the panel. If a device is temporarily unavailable, record it for follow-up so it does not retain an invalid configuration indefinitely.
Security conclusion: After a subscription address is exposed, reset it, replace it, and verify that the old address no longer works. Deleting messages, clearing browsing history, or updating the old subscription cannot change the fact that the link has already been exposed.
How to maintain subscription configurations
Reliable subscription use does not require constant configuration changes, but it does benefit from clear management habits. Give subscriptions recognizable names that distinguish the service and purpose; review logs before and after updates instead of watching only node-count changes; when changing clients, copy the address again from the account panel rather than extracting it from an old client cache; and when contacting support, provide only the error type, the stage where it occurred, and the necessary log entries.
If the client supports local rule overrides, clearly distinguish settings supplied by the subscription from those you maintain yourself. Updating a subscription may replace remote nodes and groups, while local DNS, routing, per-app rules, and system proxy settings are often stored independently. When a problem appears, first identify which layer changed. This prevents subscription issues from being mistaken for route issues and avoids repeatedly resetting credentials to fix a DNS problem.
- ✅ Keep the account panel as the only trusted source for the subscription.
- ✅ When node information changes, update manually before evaluating route status.
- ✅ Before changing clients, confirm protocol and subscription-format compatibility.
- ✅ Periodically check whether clients you no longer use still retain the old configuration.
- ❌ Do not put subscription links in public scripts, public repositories, or shared tutorials.
Ultimately, subscription links solve a configuration-synchronization problem. Get them from the account panel, confirm client compatibility during import, distinguish remote configuration from local cache during updates, troubleshoot connection issues through requests, parsing, handshakes, routing, and DNS, and reset and replace the link immediately after a leak. Once this workflow is clear, most cases of “the subscription updated but still does not work” can be diagnosed accurately.