What is a subscription link? A complete beginner’s guide to getting, importing, and updating one

A subscription link synchronizes a server list with a client. This guide explains where to get one, how to import it across platforms, how often it updates, and how to reset it if it is exposed.

What is a subscription link? In simple terms, it is a configuration URL generated by a service dashboard for compatible clients to read. When a client accesses it, the URL provides server names, addresses, ports, protocol parameters, and group information, then organizes them into a selectable server list. You do not need to copy each setting manually, and you can resynchronize changes by updating the subscription.

A subscription link is neither a client nor a single fixed server. Think of it as a continuously updated configuration index: the server provides the content, while the client parses, stores, and applies it. Whether it works depends on the link status, the format supported by the client, the server protocol, and the local network environment. Understanding this relationship makes it easier to diagnose failed imports, stale server lists, and access problems after connecting.

What’s inside a subscription link

A subscription link usually looks like a URL beginning with a web protocol. Opening it directly in a browser may show encoded text, download a configuration file, or return an access-denied message. None of these necessarily means the content is empty: the link is designed for clients, not for reading as a normal webpage.

The content returned by the server generally falls into two categories. One is a collection of single-server URIs, with each record describing one route. The other is a structured configuration that may include proxy groups, split-tunneling rules, DNS settings, and remote resource URLs in addition to servers. After import, each client converts the original fields into its own configuration model, so the interface, group names, and available options may differ between apps.

Configuration section Common contents Client purpose Effect of an update
Server details Server address, port, transport protocol, encryption, and authentication parameters Establish a connection to a remote server Add, remove, or modify available servers
Display information Region names, server labels, and group names Help users filter and switch servers Names and groups may be reordered
Policy information Proxy groups, direct-connection rules, and blocking rules Determine which path each request takes Rule changes may alter the access path
Resolution information DNS mode, resolvers, and domain-matching rules Resolve domains together with traffic-routing rules May correct resolution failures or leak issues

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC can all be protocols used by servers, but they are not subscription formats themselves. A subscription is simply a way to deliver configuration. The client must understand both the outer subscription format and the protocol used by each server; otherwise, the link may import successfully while some servers fail to appear or connect.

Protocols cannot be converted into one another simply by changing their names. Shadowsocks uses a pre-shared key and encryption method; VMess has its own authentication and time-validation mechanisms; Trojan commonly carries connections behind a TLS presentation; VLESS separates authentication from the transport method; and Hysteria2 and TUIC target QUIC-based transport environments. If the client lacks the required core, a successful import does not prove that a server is usable.

Bottom line: A subscription link “delivers configuration to the client,” while the protocol determines “how the client establishes a connection.” Troubleshoot format compatibility and protocol compatibility separately.

Get it from the dashboard and import it into a client

Get the subscription from the provider’s user dashboard. Common options include Subscription, Import to Client, Copy Link, or One-Click Import. Before copying, confirm the target device and client type, since the server may offer different formats for different clients. If the same account shows multiple options, do not judge them by URL length; choose the format explicitly intended for the client you are using.

  1. Open the user dashboard on a trusted device. Go to subscription management or the client configuration area and confirm that the current subscription is still active.
  2. Choose the format for your client. If the dashboard offers both a general configuration and client-specific configurations, follow the software’s guidance instead of routing the link through a third-party converter.
  3. Copy the complete link. Make sure the final characters are included, and avoid repeatedly forwarding it through chat apps, where preview services may read it or message history may retain it indefinitely.
  4. Choose Import from URL in the client. Different apps may call this Subscription, Configuration, Remote Configuration, or Configuration File. The essential action is for the client to read the remote address.
  5. Save it and run an update. Confirm that a server list appears, then select a suitable server and connect. If you see a subscription name but no servers, check the format and update result first.
  6. Verify the exit point and resolution path. After connecting, visit a trusted IP lookup page and check whether DNS requests are following the client settings as expected.

If the client supports QR-code scanning, make sure the code was generated directly by the dashboard. A QR code is only a visual representation of a link or configuration; it does not provide extra security. Once a screenshot enters a shared album, public support ticket, or document, others may still recover its contents.

Import differences across platforms

Desktop and mobile platforms do not handle subscriptions in exactly the same way. Windows clients generally offer more complete subscription management, system-proxy, and virtual-network-adapter modes; macOS is affected by Network Extension permissions and may require authorization in System Settings the first time; Android commonly provides per-app proxy controls and background-operation limits; on iOS and iPadOS, clients must create a system VPN configuration and follow the operating system’s background-task scheduling.

Platform Common import location Key checks Common issue
Windows Subscription management, remote configuration, or Configuration URL System proxy, virtual network adapter mode, and core version The browser works, but other apps still connect directly
macOS Configuration file, subscription, or remote resource Network Extension authorization, system proxy, and existing network tools The configuration imported, but the system extension is not enabled
Android Configuration, subscription link, or clipboard import VPN permission, background operation, and per-app rules Updates or connections pause after switching to the background
iOS and iPadOS Remote configuration, URL import, or dashboard redirect System VPN configuration authorization and on-demand connection rules A server is selected in the client, but the system connection is not established
Routers and gateways Remote configuration URL or converted local configuration Firmware capabilities, protocol core, and rule persistence The subscription exceeds the firmware’s parsing limits

“Import successful” only means the client accepted the configuration; it does not mean all traffic is being routed as expected. System-proxy mode usually affects only apps that follow proxy settings. Virtual-network-adapter or system-VPN modes cover more traffic, but are also more likely to conflict with other network extensions, firewalls, or enterprise policies. Verify each app in actual use instead of judging by whether the client icon changes color.

Per-app proxying is another feature with substantial platform differences. Android clients often let you choose which apps use the proxy, while desktop clients rely more on process rules, domain rules, or system routing. Rule order is especially important: if a domain first matches a direct-connection rule, its request will not use the remote route even when a server is connected.

How often does automatic updating run?

There is no universal automatic-update interval across all clients. The actual frequency depends on client capabilities, user settings, operating-system background limits, and server-side policy. Some clients fetch updates only when you click manually; others check at startup, while some let you schedule updates. Mobile operating systems may delay background tasks, so “automatic updates enabled” does not mean an update will always finish at a fixed time.

Do not decide whether an update is needed based only on how long you have been using the configuration. Run a manual update when server names change, an old server stops connecting, the service dashboard reports configuration changes, or no new groups have appeared for a long time. Before updating, note the selected server and custom rules; afterward, confirm that they still exist.

Clients also handle old servers differently. Some fully replace the previous subscription content, some keep a local copy, and others combine manually added servers with subscription servers in one list. If a decommissioned server still appears after an update, first determine whether it belongs to the remote subscription or local configuration, then decide what to remove.

If a subscription request returns an authentication error, first check whether the link was reset, the account status changed, or the copied content is incomplete. For a format error, focus on the client version and subscription format. A network timeout is more likely related to local resolution, the current network path, or temporary inaccessibility of the subscription server. Each error points to a different layer, and repeatedly switching servers usually will not fix the subscription download itself.

Update tip: Use the update time and error log shown by the client as your reference. When servers behave unexpectedly, refresh manually first, then check the format, protocol, and local network instead of guessing at a universal update interval.

Server types, traffic routing, and DNS checks

Server names in a subscription may label routes as direct, relay, or IEPL dedicated lines. These terms describe network topology, not proxy protocols. Direct means the user connects to the destination entry point without an intermediate relay; the path is simpler but depends more on public-internet routing. A relay sends traffic through an intermediate server before forwarding it to the exit, making cross-network paths easier to adjust. IEPL dedicated lines generally refer to enterprise-grade cross-border transport paths organized using international Ethernet private-line resources; their access and landing design depend on the provider’s network.

Network topology can be combined with protocols such as Shadowsocks, Trojan, and VLESS. A server labeled as a relay may still use Trojan, while a direct server may use Hysteria2. When choosing one, first confirm protocol support in the client, then compare routes based on the local network, destination region, and use case. The words “dedicated line” alone cannot prove that a particular connection will be faster.

Traffic-routing rules determine whether a request uses the selected route. Common match criteria include domains, IP ranges, application processes, and rule sets. Rules are usually processed in order: the first match determines whether traffic is proxied, connected directly, or blocked. If an international website still shows a local exit, check whether its domain matched a direct rule first. If a local service takes a distant route, check whether an overly broad proxy rule caught it.

A DNS leak occurs when domain queries are not sent through the intended path, allowing a local resolver to see them or producing results inconsistent with the proxy exit region. It does not necessarily cause connection failures; it often appears as “the webpage loads, but the detected region is wrong.” Check the exit IP, DNS resolver, and client DNS mode together rather than looking only at whether the server is connected.

What to do after a subscription link is exposed

A subscription link usually contains a token that identifies an account. Anyone who obtains it may be able to read the server configuration, and some services also treat it as subscription access credentials. If the link appears on a public page, is submitted to an untrusted tool, or enters a shared record that cannot be withdrawn, treat it as exposed instead of merely deleting it from the local client.

  1. Disable the old link in the service dashboard. Look for an option to reset the subscription, update the token, or generate a new link. The essential step is making the old address invalid on the server.
  2. Generate and copy a new link. Import it only into the clients that need it, and stop using old QR codes, configuration files, or clipboard records.
  3. Delete the old subscription from every device. Remove the remote configuration first, then import the new address so the client does not continue requesting the old link on a schedule.
  4. Check automated devices. Routers, gateways, and backup computers may still store the old configuration and must be updated separately.
  5. Clean up public content. Delete screenshots, support-ticket attachments, documents, and code records containing the complete address. Even after the old link is invalid, reducing credential remnants is still worthwhile.
  6. Recheck servers and rules. Confirm that the new subscription updates successfully and that proxy groups and traffic-routing rules work as expected.

Changing only the subscription name inside the client does nothing, because the actual credential is still the original address. Shortening the old link, turning it into a QR code, or placing it in a local file does not remove the exposure risk. Effective remediation must happen on the server: revoke the old token and generate a new subscription address.

If you have simply changed devices and still control the old one, delete the subscription and configuration from the old client before importing it on the new device. If the device is no longer accessible, resetting the link is safer. After a reset, any other device still using the old address will stop updating and must be replaced individually.

Final takeaway: A subscription link is not a public download URL. Get it from the dashboard and import it directly into a compatible client; when synchronization fails, check the update error; if it is exposed, invalidate the old link and replace the configuration on every device you control.

Start Free