What is a subscription link? In simple terms, it is an address generated by a subscription service for a compatible client to read. When the client accesses it, it can retrieve node names, server addresses, ports, protocol parameters, and some grouping information supplied by the service. It is not the client itself or a single fixed route; more precisely, it is the synchronization point between the client and the service configuration.
When using one for the first time, you typically only need to copy the subscription address from the service dashboard, then choose “Import from link” or a similarly named option in the client. After a successful import, the client converts the remote configuration into locally selectable nodes. When the service adds routes, adjusts connection parameters, or retires old nodes, you can update the subscription to receive those changes instead of entering every item manually.
What a subscription link contains—and what it does not
The core of a subscription is connection configuration. Common fields include a server domain or address, connection port, encryption or authentication parameters, transport method, node label, and group hints. Different protocols require different fields, so the client must genuinely support the relevant protocol. “Supports subscription import” alone does not mean every node will connect.
| Content category | Usually included? | What it does | Common misconception |
|---|---|---|---|
| Node connection parameters | Included | Tell the client where to connect and which authentication and transport methods to use | Similar node names do not mean the exit location or route quality is identical |
| Protocol configuration | Included | Describe the parameters required for connections using Shadowsocks, VMess, Trojan, VLESS, Hysteria2, or TUIC | A client can recognize a link without fully supporting every protocol it contains |
| Groups and sorting | Depends on the format | Help the client display regions, purposes, or automatic-selection groups | Server-side groups do not automatically cover every local routing rule |
| Client software | Not included | Requires the user to install compatible software separately | Copying the subscription address does not establish a network connection |
| Local system permissions | Not included | Requested by the system and client when a proxy or tunnel is enabled | A subscription service cannot replace the user’s confirmation of system permissions |
A protocol name is not the same as a route type. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC describe how the client communicates with the access server; IEPL dedicated routes, relays, and direct connections describe the network path from the access point toward the exit. These are different layers.
A direct route reaches the remote access server directly through the local network. The path is simple, but performance depends more on carrier interconnection. A relay route first connects to a nearby entry point, then uses a relay network to reach the exit, which is generally intended to improve cross-network paths. An IEPL dedicated route is a specific enterprise-grade cross-border transport arrangement; the word “dedicated” in a node name alone cannot confirm the actual network structure. Check the provider’s explanation and compare stability at different times instead of judging by the protocol name alone.
Get your subscription from the service dashboard and store it securely
Get the subscription address from the service dashboard, official client, or an entry explicitly provided by the service. Do not use obscure “converter” pages found in search results or paste the address into random online testing tools. Subscription links often contain tokens that identify account configuration. Anyone holding the link may be able to read the same node information, so manage it like a credential rather than sharing it as an ordinary webpage link.
- Sign in to the relevant service dashboard and find the subscription, client configuration, or import configuration section.
- Choose a compatible format for the client you plan to use. If the dashboard separates a general subscription from client-specific configurations, choose the version that matches your client.
- Copy the complete address, making sure nothing is missing from the beginning, end, or query parameters. Automatic truncation in chat apps, line wrapping, and extra spaces can all cause import failures.
- Switch directly to the client to complete the import. Do not pass the address through public short-link services, QR-code generators, or online text-processing pages first.
- After importing, check the subscription name and node list, then run an update. Seeing nodes does not mean the connection has been verified.
- ✅ The address came from the service dashboard or an explicitly provided client entry point
- ✅ The copied content retains the complete path and parameters
- ✅ The subscription format matches the client’s capabilities
- ✅ Update first after importing, then select a node for a connection test
- ❌ Publish the subscription address in a forum, support-ticket screenshot, or public code repository
- ❌ Submit it to an unknown online conversion service for “decoding”
If you need to transfer it between your own devices, prefer a controlled local method or a trusted end-to-end sync tool, and clear temporary records afterward. Take screenshots carefully too: a QR code can still contain the complete subscription address, so hiding the surrounding text does not hide the QR code’s contents.
How client imports differ across platforms
Button labels may differ across platforms, but the workflow is broadly the same: install a compatible client, add a subscription, paste the address, update it, then choose a node or policy group. What matters is the client’s supported scope, system proxy method, and background-running limits—not which menu contains the button.
Windows and macOS
Desktop clients usually provide a subscription management window where you can save multiple sources and update them manually. After importing, you still need to select an operating mode. System proxy mode mainly handles apps that follow the system proxy settings; virtual network adapter or tunnel mode covers more traffic, but requires system permission and may conflict with other network tools.
macOS clients can also be affected by system extensions, network filters, and wake-from-sleep behavior. If a node still appears connected after wake but webpages will not load, disconnect and reconnect first, then check for leftover proxy settings in the system. On Windows, check whether the system proxy remains enabled after the client exits when similar behavior occurs.
Android and iOS
Mobile platforms generally use the system-provided VPN interface to handle traffic. After importing a subscription, the system will ask you to confirm network configuration permission. Once the client enters the background, power-saving policies, background restrictions, and network changes can affect long-lived connections. If the connection does not recover when switching between Wi-Fi and cellular data, establish a new session instead of repeatedly deleting the subscription.
Some mobile clients recognize links from the clipboard, while others require manual pasting on the subscription management page. When scanning a QR code with the camera, confirm that it came from your own service dashboard. Do not scan unknown configurations shared by others, as their server, DNS, and routing settings may differ from what you expect.
Linux and router environments
Linux clients may use a graphical interface or run as a core program with a configuration file. A desktop system proxy affects only software that follows that setting; command-line programs often need environment variables configured separately, or a transparent proxy and virtual network adapter setup. If importing succeeds but terminal requests still use the local exit, the traffic-handling scope differs—it does not usually mean the subscription is missing content.
Router environments require closer attention to architecture, kernel capabilities, DNS forwarding, and firewall rules. After importing a subscription on a router, the configuration affects other devices on the same network, so keep a restorable backup before making changes. For an initial subscription test, connecting one endpoint first is usually easier to troubleshoot than modifying the entire network.
What updating a subscription changes
Updating a subscription requests the service configuration again and syncs node additions and removals, address changes, protocol parameter changes, or group changes locally. It usually does not automatically modify all rules written by the user, nor does it necessarily replace client-level DNS, logging, interface, or startup settings. The exact scope depends on the subscription format and client implementation.
There is no single update schedule that fits every situation. When nodes work normally, frequent updates are unnecessary. Updating makes more sense when the service dashboard reports route changes, the node list differs from the dashboard, existing nodes remain unable to connect, or a new client needs to parse the configuration again. If the client supports automatic updates, enable them according to your actual usage; frequent refreshing is not a way to improve speed.
Watch for local changes before and after an update. Some clients let you edit node names or connection parameters, but the next subscription refresh may overwrite those changes. Keep routing rules that must persist in the client’s supported local rule, override, or separate configuration layer rather than modifying remote entries managed by the subscription.
Check in this order when an update fails
- Confirm that the subscription address still comes from the current service dashboard, not an old backup or a link that has already been revoked.
- Check whether the link was truncated, especially its trailing parameters and special characters, and whether spaces were added during copying.
- Temporarily disconnect the current proxy, then try the update again to rule out a faulty node blocking the subscription request.
- Check whether the client supports the format returned by the service. If the dashboard offers a dedicated format, copy it again from the corresponding entry point.
- Update the client core and import again. An older core may not recognize newer protocol fields.
- If it still fails, record the error message and troubleshoot through the service’s support channel. Do not submit the complete link publicly.
If the update reports success but the list does not change, the service content may simply be unchanged, or the client cache may not have refreshed. Return to subscription management to check the update time, then reopen the node list. Deleting all local configuration should be a last resort, because it may also remove custom routing and override content.
Why routing rules and DNS affect the result
Completing a subscription import does not mean all traffic will use the same node. Rule mode decides whether traffic is proxied, sent directly, or denied based on domains, address ranges, applications, or rule sets. Global mode usually sends more connections through the current node and is useful for briefly checking whether rules are missing a match, but the right long-term mode depends on the destinations and local network requirements.
A common scenario is that a browser works normally while one application cannot connect. The application may not follow the system proxy, may use a network protocol the client does not handle, or may be classified as direct by the routing rules. Conversely, if local websites also become noticeably slower, the rules may be too broad and sending traffic that should stay direct through a remote exit.
DNS resolution can also operate before or during rule evaluation. If a domain is resolved by the local network while the actual connection leaves through a remote node, the result may not match the exit region. A DNS leak usually means that resolution requests that should follow a controlled path are still sent to a local resolver, exposing query targets or causing an incorrect regional result. This is different from a subscription link leak and requires separate handling.
- ✅ In rule mode, confirm that the target domain matches the expected policy
- ✅ Use global mode briefly for comparison to determine whether routing is the cause
- ✅ Keep DNS resolution and traffic exits consistent within the client’s supported scope
- ✅ Start a new connection after switching nodes instead of reusing an old session
- ❌ Assume the subscription has failed as soon as the exit looks unusual
- ❌ Run multiple clients that handle network traffic at the same time for comparison testing
To verify the exit, use this site’s network check to view the current address and basic network information. If the connection succeeds but access fails, rules stop working, or resolution behaves unexpectedly, follow the sequence in troubleshooting and check each layer. Change only one condition at a time—for example, switch only the node or only the operating mode—so you can identify what caused the change.
What to do after a subscription link leak
If a subscription link has appeared on a public page, shared document, public support ticket, code repository, or untrusted conversion tool, treat it as exposed. Deleting the public message alone is not enough, because the content may already have been cached, forwarded, or scraped. The correct approach is to reset the subscription link in the service dashboard or contact support to revoke the old token, then import the new link into your own clients.
- Stop using or distributing the old link, and delete public copies you control.
- Reset, revoke, or regenerate the subscription credential in the service dashboard. If there is no such option, handle it through a support ticket.
- Remove the old subscription source from your clients, then import the new address and update the nodes.
- Check your other devices so they do not continue requesting the revoked subscription.
- Confirm that public screenshots, QR codes, and configuration backups do not retain a recoverable copy of the old address.
Resetting a subscription link usually changes the credential at the configuration-distribution layer; it does not mean the client will automatically obtain the new address. Devices that imported the old link must be updated one by one. If a device is temporarily inaccessible, wait until it can be updated safely rather than sending the new link through a public chat history.
A complete beginner troubleshooting sequence
When you see a problem such as “imported but unusable,” the most effective approach is not to keep switching software. Check configuration delivery, protocol compatibility, route connectivity, traffic handling, routing rules, and DNS resolution in that order. Until each earlier layer is confirmed, results from later tests can be misleading.
- ✅ The subscription address in the service dashboard is still valid and was copied in full
- ✅ The client supports the protocols and transport parameters used by the subscription
- ✅ The nodes are visible after updating and an actual connection option can be selected
- ✅ System proxy or tunnel mode is enabled for the intended use case
- ✅ Routing rules send the target request to the expected node
- ✅ DNS requests and target traffic use a consistent, controlled path
- ✅ When a route behaves unexpectedly, compare direct, relay, and other available nodes
If the node list is empty, check the subscription format and address completeness first. If nodes are present but the handshake fails, check protocol support, system time, and network reachability. If the connection succeeds but an application does not use the node, check traffic-handling mode and the application’s proxy settings. If only some websites fail, inspect routing and DNS. This is faster than repeatedly removing the client and helps prevent local rules from being lost.
For questions during initial setup, see this site’s Guides for the basic dashboard-to-client workflow, or view the route list to understand regions and route types. When choosing a node, geographic distance is not the only factor; local carrier paths, access methods, relay quality, and the destination service’s location all affect real-world performance.