A subscription link is a dedicated address that a client uses to retrieve remote server configurations. Instead of entering server addresses, ports, protocols, and authentication details one by one, you can import the link into a compatible client to fetch the current server list, names, and required parameters. For VPNRH, the subscription link is also the entry point for retrieving VPNRH configurations.
It is not an ordinary webpage link or a download address meant for public sharing. A link usually contains a random credential that identifies subscription access, so anyone who obtains it may be able to read the associated configuration in a compatible client. Use it by copying it from the user panel, importing it only into a trusted client, updating it when needed, and resetting it if you suspect exposure—not by posting it in public chats, forums, or screenshots.
What a subscription link contains
Visually, a subscription link is usually a long string beginning with a secure web address, followed by a random path or access credential. Opening it directly in a browser may show unreadable text, trigger a configuration download, or be blocked by the browser. That does not mean the link is broken: it is designed to be read by a proxy client, not displayed as a webpage.
After a client requests the link, the server returns a machine-readable configuration. The exact format depends on the client ecosystem: it may be an encoded server collection, YAML, JSON, or a client-specific configuration. The configuration typically includes server names, addresses, protocol types, authentication parameters, and group information. Because Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC use different field structures, a client being able to open a subscription link does not mean it can correctly run every protocol included in it.
| Object | Primary purpose | Where it belongs | Suitable for sharing? |
|---|---|---|---|
| User panel account | View plans, server access, and account settings | VPNRH user panel | No |
| Subscription link | Let a client retrieve server configurations remotely | The client’s subscription or remote configuration section | No |
| Single-server link | Import one configuration for a specific protocol | The client’s link import section | No |
| Local configuration file | Save a snapshot of a configuration retrieved at a particular time | The client’s configuration folder or import page | Remove authentication details before handling it |
Subscription links and single-server links are not interchangeable. A single-server link usually describes one server and starts with a protocol name, while a subscription link points to an updatable collection. Pasting a subscription URL into an “Import Single Server” field may produce a format error. Conversely, adding a single-server URL to a “Remote Subscription” field will not provide a complete server list.
Get it from the user panel
Start by entering the VPNRH user panel through the official site entry point, then open the subscription or client section. Copy the complete address provided by the panel; do not delete parameters manually or try to guess the subscription path from the browser address bar. No email address is required to create an account—you can start with a username and password. After completing your account setup, use the panel to access the configuration entry associated with your current plan.
- Enter the user panel and confirm that you are signed in to the account you intend to use.
- Open the subscription or client download section and choose a configuration format compatible with your target client.
- Use the page’s copy function to avoid missing characters at the end of the long address.
- Switch to the client and paste it into the subscription, remote configuration, or configuration provider section.
- Run an update, review the server list, then select a server and enable the connection.
- ✅ The link came from the VPNRH user panel—not search results, group files, or someone else’s forwarded message.
- ✅ The copied content includes the complete address, path, and following parameters.
- ✅ The import field is labeled subscription, remote configuration, or import from URL.
- ✅ The client explicitly supports the protocols and configuration format used by the subscription.
- ❌ Do not paste the subscription link into online decoders, speed-test tools, or unfamiliar conversion websites.
- ❌ Do not expose the complete link in support-ticket screenshots, screen recordings, or public logs.
How to import it on desktop and mobile clients
Menu names vary by platform, but the import process is broadly the same: create a remote subscription, enter a name and URL, save it, update the configuration, and select a server. What matters is the client’s core capabilities, system permissions, and proxy mode—not whether the button is called “Add Subscription.”
Windows and macOS
Desktop clients usually place subscription controls under Configuration, Subscription Management, or Configuration Files. After pasting the link, run an update and confirm that the new configuration is active. Some clients finish downloading but remain on the previous configuration. If the server list does not change, check the selected configuration name and reload it.
When first enabled on macOS, the system may ask you to add a network configuration or allow a related extension. This permission lets the client manage network traffic; it does not replace subscription import. If the client has servers but webpages still use the original network route, check the system proxy, virtual network mode, and the client’s main switch.
Android and iOS
Mobile clients usually require you to create the remote configuration inside the app. The system will then ask you to confirm network configuration permissions. If switching apps causes the connection to stop, review the system’s background-running restrictions for that client. If the subscription updates but servers will not start, first check protocol support, system permissions, and the current network environment.
Format compatibility varies considerably between iOS clients, so the same link may be parsed differently by different apps. Android clients may also use different cores. Choose a client based on the compatibility guidance shown in the panel, rather than assuming that “supports subscriptions” is enough.
Command-line and router environments
Command-line cores and router environments usually require a more specific configuration format. Some tools can reference a remote subscription directly, while others require conversion to a format they understand. Because conversion involves authentication parameters, do not hand it to an unfamiliar web service. The safer approach is to use a format natively supported by the client or convert it in a trusted local environment while restricting configuration-file permissions.
How often should you update a subscription?
There is no fixed update schedule that suits everyone. An update simply rereads the current configuration from the server; it is not continuous speed testing, and refreshing more often does not make the connection faster. If the client already has a usable configuration and the servers work normally, repeated refreshes are unnecessary. Update when the configuration changes, the server list looks abnormal, or the client has not been used for a long time.
Use an event-driven update routine: update after the first import; update before connecting if the list is clearly outdated; update when the service announces a configuration change; and update before troubleshooting after multiple connection failures. If the client supports refreshing at startup, enable it according to your habits, but avoid repeatedly making manual requests from multiple devices in a short period.
Updating a subscription replaces server information in the remote configuration, but it usually does not correct split-tunneling rules you wrote yourself or guarantee that the currently selected server still exists. If connection behavior changes after an update, check the policy-group selection, rule mode, and local overrides. For modified configurations, keep custom rules separate from the remote subscription so an update does not overwrite them.
Understanding direct, relay, and IEPL routes
Server names in a subscription may identify a region, city, or route type. Direct means the client connects straight to the destination server; the path is simple, but performance depends more heavily on the public route from your local carrier to the destination region. A relay route first reaches an intermediate access point and then forwards traffic to the exit, with the aim of improving inter-network routing and peak-hour performance. An IEPL dedicated line generally uses a private transport path between the access and exit points, unlike a normal direct public-internet route.
These labels describe network paths, not protocols. Trojan or VLESS can run on different route architectures, while Hysteria2 and TUIC use different transport designs. When choosing a server, evaluate “route type” and “protocol compatibility” separately: the client must support the protocol before the route itself can be meaningfully compared.
Server names or groups may change after a subscription update. If a custom rule is tied directly to a full server name, a name change can invalidate it. A safer approach is to point everyday rules to a policy group and choose the current server within that group. This avoids editing application rules one by one after each configuration update.
| Route type | Route characteristics | Check these first when troubleshooting |
|---|---|---|
| Direct | The local network connects directly to the remote server | Local carrier routing, protocol reachability, and the route to the destination region |
| Relay | Traffic reaches an access point first, then is forwarded to the exit | Access-region selection, policy group, and whether the subscription is up to date |
| IEPL dedicated line | The access and exit points use a private transport path | Client compatibility, entry-point reachability, and route-group selection |
Check DNS and split tunneling after import
A connection being established does not mean every request follows the expected route. The client may control only browser proxy traffic, or it may manage more application traffic through virtual network mode. Split-tunneling rules determine which domains or addresses use the proxy and which stay direct. DNS settings determine who resolves domains and which route carries those queries.
A DNS leak usually means traffic follows the proxy route while domain queries are still sent to the local network’s resolver, exposing information about the queries or producing results that do not match the exit region. Start by confirming that the client’s DNS mode is enabled, then check whether the system retains other resolution paths. Browser-encrypted DNS, system resolver settings, and client DNS may coexist; conflicting settings can produce inconsistent results.
Split-tunneling issues often come from rule priority. Clients generally match rules from top to bottom. If a broad direct rule appears before the target rule, the later proxy rule will never apply. After changing rules, reload the configuration and test sites that should stay direct as well as sites that require cross-border access. Do not rely solely on the client’s status icon.
- ✅ Confirm that the active configuration is the recently updated remote version, not an old local copy.
- ✅ Confirm that the policy group has selected an available server rather than an obsolete name.
- ✅ Confirm that the client’s proxy mode matches your expectations, including rule mode or global mode.
- ✅ Confirm that DNS queries are handled by the client according to its configuration.
- ✅ Check whether the browser or system has a separate proxy setting that conflicts with the client.
- ❌ Do not equate “subscription updated successfully” with “every application is now covered.”
How to reset and check a leaked link
If a subscription link appears in a public screenshot, shared document, code repository, terminal history, or untrusted device, treat it as exposed. Deleting the public copy is not enough because the link may already have been cached or copied. The correct response is to reset the subscription credential in the user panel so the old link expires, then import the new link on trusted devices.
- Stop forwarding or testing the old link, and delete its complete contents from public locations.
- Open the VPNRH user panel and use the subscription reset function to generate a new access address.
- Delete the old subscription from every trusted client, then import the new link and update the configuration.
- Check configuration files, clipboard sync, terminal history, and cloud documents for the old address.
- Check whether any client still references the old configuration. If necessary, clear the local cache and import it again.
After a reset, the old link should no longer work as a valid entry point. If a device can still display the old server list, it may simply be reading a local cache; that does not mean the old subscription can still update. Run a manual update to confirm: the old address should fail to retrieve a new configuration, while the new address should work normally. Once confirmed, delete the old local configuration copy.
When submitting troubleshooting details, handle sensitive fields carefully. You can include the error type, client platform, protocol name, and symptoms, but mask the subscription URL, authentication parameters, and complete server information. If logs contain a remote configuration URL, redact it in a local copy before submitting it through the official support channel.
A troubleshooting order for common errors
When a subscription will not update, first distinguish between “the configuration cannot be retrieved” and “the configuration loads but the servers will not connect.” The first is usually related to link integrity, network requests, credential status, or format compatibility. The second is more likely to involve protocol support, server status, system permissions, DNS, or split tunneling. Mixing these categories often leads to repeated client reinstalls without identifying the cause.
Address or format is invalid
Check that you copied the complete link and did not include quotation marks, spaces, or line breaks. Confirm that you pasted it into the remote subscription field. If the client requires a specific format, select the matching version in the panel instead of modifying URL parameters yourself. A link opening in a browser does not prove that the client supports its returned format.
Update succeeded but no servers appear
First confirm that the client is showing the new subscription rather than an older configuration with the same name. Then check for filters, hidden groups, or parsing warnings. Some clients ignore parts of a configuration when they encounter unsupported fields. Use a client or compatible configuration supported by the panel instead of deleting protocol fields manually.
Servers appear but the connection fails
Update the subscription, switch servers, and confirm system permissions in that order. Then check protocol support and the network environment. If only one protocol fails while others work, focus on the client core version and protocol compatibility. If every server fails to connect, check the system proxy, virtual network permissions, and local network restrictions.
Websites work but some apps do not use the route
This is usually a proxy-coverage or split-tunneling issue. A browser may follow the system proxy while other apps connect directly. For broader coverage, use the client’s supported virtual network mode and recheck direct rules, target-domain rules, and DNS settings. After changing them, test different types of applications separately to confirm which rules match.