Learn what subscription links do, where to find them in the dashboard, how to import and update them, and what to do after a link leak; update timing depends on client settings and service notices.
What is a subscription link? Put simply, it is the entry point a client uses to retrieve node configurations. Instead of entering server addresses, ports, and transport parameters one by one, you copy the link from the service dashboard and let a compatible client parse it. It solves configuration distribution and ongoing updates; it is not itself a network protocol, and importing it does not guarantee a connection.
A subscription link usually contains a path or token used to identify the subscription. When a client accesses the address, the server may return plain text, an encoded collection of nodes, or a configuration format tailored to a specific client. The response can describe route names, protocol parameters, and group information, but the actual fields depend on the server output and the client’s supported formats. Do not treat a link as a publicly shareable web address simply because it looks like an ordinary URL.
Treat subscription links like account credentials. Screenshots, logs, cloud clipboards, and public discussion boards can all retain the complete link; when troubleshooting, mask the identifying portion after the domain.
Manual configuration means entering the required parameters for a single node into a client one by one; a subscription delivers a group of configurations together. After saving the subscription endpoint, the client can request the same endpoint again to retrieve the node list currently offered by the server. Changes to route names, node counts, or parameters generally appear locally only after the client updates the subscription.
This explains how “the web dashboard has changed” and “the client still shows the old list” can both be true: the dashboard shows current server information, while the client may still be using its last saved copy. Exiting the client, switching networks, or restarting the device does not necessarily trigger a subscription refresh. Whether updates happen automatically, and when, depends on client settings and service notices.
A subscription delivers configuration; the connection is actually established by the network core built into or called by the client. If the subscription returns a protocol or field the client cannot recognize, the node may be hidden, importing may produce a format error, or the node may appear but fail to start. Switching to another subscription format can sometimes resolve compatibility issues, but it will not make a client suddenly support a protocol when the required core is missing.
| Protocol or solution | Role in the subscription | What to confirm during import |
|---|---|---|
| Shadowsocks | The configuration usually includes the server, port, encryption method, and credentials. | Whether the client supports the specified encryption method and plugin parameters. |
| VMess | The subscription can deliver identity parameters, transport methods, and related connection fields. | Whether the client core understands the transport combination returned by the server. |
| Trojan | The configuration is usually organized around a TLS connection, target address, and authentication details. | Whether the server name, certificate verification, and transport parameters are parsed completely. |
| VLESS | The subscription distributes combinations of identity, transport-layer, and security-layer parameters. | Do not rely on the protocol name alone; also check the client core version and field support. |
| Hysteria2 | The configuration describes QUIC-based connection parameters and authentication details. | Whether the client on the current platform integrates the required core, and whether the network permits the relevant transport. |
| TUIC | The subscription can deliver QUIC-based node configurations. | The client implementation, certificate settings, and server parameters must match one another. |
A single subscription may contain multiple protocols or only one. The protocol name alone does not reveal route quality. Connection performance is also affected by local access, the transport path, exit load, the target site, and the time of use. Test in your own access scenarios rather than judging only by the protocol label.
VPNPW lets you create an account without an email address; use your username and password to access the dashboard. After activating the relevant plan, rely on the dashboard for the subscription endpoint and available configurations. If multiple client formats are offered, choose the one explicitly matched to your current client instead of randomly trying the longest URL or the one with the most fields.
Desktop clients commonly offer “Import from URL,” “Add subscription,” or a similar entry point, where you can set the subscription name and update options. Mobile clients may import through clipboard detection, the system share menu, or an in-app field. Linux clients vary more widely: some provide a graphical interface, while others rely on configuration files or the command line; subscription conversion and core startup may also be handled by separate components.
On Windows and macOS, a successful import usually still requires selecting an active configuration, node, or policy group. Adding a subscription to a list does not mean system traffic has been handed to the client. On iOS and Android, you may also need to approve a request for the system to create a network configuration. This system prompt establishes a device-side network channel and is separate from whether the service account is active.
Copy the subscription endpoint from the dashboard
→ Add the subscription source in the client
→ Request an update manually
→ Parse nodes and policy groups
→ Select the active configuration
→ Enable the connection mode
→ Check the exit and routing resultsIf a client supports both “Import single node” and “Add subscription,” do not confuse them. A single-node import saves only that configuration at that moment and will not follow later changes to the subscription list. Adding a subscription keeps the remote endpoint so it can be fetched again. Testing a single node temporarily is fine, but for long-term use, remember that it will not turn itself into an updatable subscription.
A local configuration exported from one client cannot necessarily be imported directly into another. Exported files may include local policies, ports, and platform-specific fields. When moving between clients, it is usually better to reuse the compatible subscription format provided by the service dashboard.
Updating a subscription means that the client revisits the remote address and refreshes its local configuration with the response. The automatic update interval is controlled by the client, while server maintenance schedules follow service notices. There is no fixed interval that applies to every client, so do not treat one application’s default as a universal rule.
If the route list is clearly outdated, node names differ from those in the dashboard, or a service notice asks you to refresh the configuration, start with a manual update. If it fails, distinguish the request stage from the parsing stage: request failures are commonly related to network reachability, link status, or system time; parsing failures more often indicate an incompatible format, an abnormal response, or a client core that does not support the relevant fields.
| Symptom | Check first | What to do |
|---|---|---|
| Subscription request times out | Whether the current network can reach the subscription domain and whether the system proxy is creating a loop. | Switch to an available network, disable the faulty proxy handling, and try again. |
| Unauthorized response or invalid link | Whether the link is complete and whether the account dashboard has generated a new endpoint. | Return to the dashboard and copy it again; do not keep using the address in an old screenshot. |
| The list is empty after import | Whether the client supports the returned format and whether the content was treated as a web page. | Choose the matching subscription format or switch to a compatible client if necessary. |
| The update succeeds but old nodes still appear | Whether the wrong subscription group was updated and whether the client retains a cache. | Check the active configuration and reload it according to the client’s mechanism. |
| The node is visible but cannot connect | The protocol core, transport parameters, local network, and system time. | Start with the error category in the connection log, then verify the node and network separately. |
Deleting and re-adding a subscription can rule out some local cache issues, but it should not be the first step. Record the subscription name, client type, and error details first; this often makes the cause easier to locate. Deleting it immediately loses local policies and selection state, and may erase useful evidence that could have been compared.
After importing a subscription, the client still has to decide which requests use a proxy and which remain direct. Common criteria include domains, IP ranges, application processes, and preset rule sets. Global proxy mode is useful for short-term troubleshooting, but it may route local services that should be direct through the proxy. Rule-based routing is better for everyday use, but you need to confirm rule order and the fallback policy.
Rules usually run according to the priority defined by the client. If a domain matches multiple conditions, the result may depend on rule order, rule-set loading status, and the addresses returned by DNS. After changing routing, test the target domain, its resource domains, and related services required for sign-in. Do not judge the whole access flow solely by whether the homepage opens.
A subscription may include DNS suggestions or a client template, but the final lookup path is also affected by the operating system, client mode, browser secure DNS settings, and routing rules. A DNS leak generally means that a lookup intended to use a specified resolution path is still sent through the system’s default resolver or another interface. This can expose where queries are sent or produce DNS results that do not match the selected exit.
To troubleshoot, reduce the variables first: temporarily use the client’s recommended basic configuration and confirm that the subscription, node, and exit work, then gradually restore custom DNS and routing rules. If the basic configuration works but the custom one fails, the issue is usually in rule order, the resolution path, or a local override—not the subscription link itself.
When a route name includes “direct,” “relay,” or “IEPL,” treat these as path descriptions rather than subscription formats. Direct usually means that the user’s network connects straight to an overseas exit node; relay means it first reaches an intermediate access point before continuing to the exit. In industry usage, IEPL generally refers to dedicated-line resources used for cross-border transport, but the actual access scope, scheduling method, and final exit depend on the service’s design.
A subscription can show these names in the client, but the names cannot prove the physical topology. Whether a route uses a relay, how the entry is scheduled, and where the exit is located all require supporting route information from the service provider. Users are better served by testing based on the actual destination, their network, and the time of use rather than equating a label with low latency or a stability guarantee.
A direct path has fewer stages but depends more heavily on the quality of the direct connection from the local carrier network to the overseas exit. A relay can change the first part of the path but adds access and scheduling stages. An IEPL-type route may emphasize its transport path, but reaching a third-party site still passes through the exit network. None has a universal priority outside a specific use case.
After a subscription link is exposed, third parties may read the node configurations it contains, leading to unauthorized use or triggering server-side security controls. Even if the public message is later deleted, the link may remain in caches, notification previews, logs, or historical versions. Deleting the original text alone is therefore not enough to restore security.
If you discover a leak, stop spreading the original link and sign in to the dashboard to see whether it offers a reset or regeneration option. After resetting it, delete the old subscription from all your own clients and import the new link. If the dashboard has no such option, contact support through a ticket and describe the leak, but do not paste the complete address into the ticket title or ordinary message body. Provide only the necessary information through the support process.
Subscription links and usernames and passwords serve different purposes, but neither should be public. When support staff troubleshoot, they usually need the client name, platform, error message, and stage at which it occurred. Providing this context first, then supplying necessary credentials through a controlled process, is safer than sending the complete link directly.
VPNPW does not limit the number of devices that can be online at the same time, but each device should use a compatible client and follow the account and service rules. Different devices can use different client formats; do not assume a local file exported from a desktop client will work on mobile.
It depends on how the client separates remote configuration from local overrides. Some clients store local rules separately, while others replace related content when reloading the configuration. Before making changes, learn the client’s configuration hierarchy and save a restorable local copy.
A node appearing in the list only proves that the subscription content was parsed. You must also confirm that the node belongs to the active policy group, the client’s traffic-handling mode is enabled, system traffic is entering the client, and the protocol core can start. Checking the connection log is usually more effective than repeatedly importing.
Copy it again when the dashboard explicitly generates a new endpoint, the original link has been reset, the link has been exposed, or a service notice requires replacement. Ordinary node changes usually only require a subscription update; there is no need to delete and rebuild the subscription every time.
After completing the configuration, use the checklist below to wrap up. It checks “link works,” “nodes connect,” and “routing behaves as expected” separately, preventing issues from different stages from being mixed together.
The core value of a subscription link is centralized configuration delivery and refresh. The correct process is to get it from the official dashboard, import it with a compatible client, validate requests and connections in stages, and reset the endpoint promptly if it is exposed.