VPN Subscription Day One: How to Get Started After Purchase
Follow the setup flow from purchase and login to subscription import, route selection, connection checks, and troubleshooting.
The most common question on the first day of a VPN subscription is not “Where is the button?” but how to use the service after purchase. What do the dashboard, subscription link, client, nodes, and connection modes each do? The right order is to confirm the plan status, get the subscription from the user dashboard, import it into a compatible client, choose a route that matches the target service, and then check the exit address, DNS, and routing results. Verifying each step in this sequence avoids repeatedly switching between settings.
This guide is for people using a proxy subscription for the first time, as well as users who have imported one successfully but still cannot open certain websites, see the wrong exit region, or find that some apps do not use the route. It explains the difference between account login and subscription import, outlines compatibility across common protocols, and highlights key steps for Windows, macOS, iOS, Android, and Linux.
Separate the dashboard, subscription, and client after purchase
Completing a purchase does not mean a device is already connected. A complete setup has several independent parts: the user dashboard shows the plan and subscription entry; the subscription link delivers node configuration to the client; the client parses protocols, establishes the tunnel, and applies routing rules; and the node determines the actual exit region and route type. If any part is incomplete, the final connection may not work.
The user dashboard manages access; it does not carry traffic
Log in to the dashboard with the username and password used for the purchase, confirm that the plan is active, and find the subscription or client page. NeuVPN does not require an email address; your username and password are enough to get started. After logging in, verify that the plan appears under the current account, then copy the subscription link or use the platform-specific client entry.
If the plan does not appear in the dashboard after purchase, do not keep creating new orders or repeatedly import the same subscription. Sign out and back in, confirm that you are using the original account, and then check the order status. If the status still does not match, submit the relevant order details through a support ticket, but never paste the full subscription link or password into the ticket.
A subscription link is not an ordinary web address
The client requests and parses the subscription link. Opening it directly in a browser may show encoded text, configuration data, a download prompt, or unreadable characters; that does not mean the subscription is invalid. Instead, find “Import from link,” “Add subscription,” or a similar option in the client, paste the link, and run an update.
Updating a subscription and connecting to a node are separate steps. A successful update only means the client retrieved the configuration; you still need to select a node and enable the system proxy, tunnel mode, or the client’s connection switch. Conversely, if an update fails, old nodes that remain in the list may not be the latest configuration for the current plan.
Get the subscription and complete the first import
Keep the first import simple. Do not change DNS, routing rules, protocol parameters, and system network settings at the same time. Establish a connection with the default configuration first, then adjust one item at a time. This makes it easier to tell whether a problem comes from the subscription, the client, or a custom rule.
- Confirm account status: Log in to the user dashboard and check that the plan and subscription entry are visible.
- Choose your platform: Get the client and instructions for Windows, macOS, iOS, Android, or Linux, depending on your device.
- Copy the subscription: Use the copy action provided by the dashboard to avoid missing characters or adding spaces during manual selection.
- Import it into the client: Paste the link in the subscription management area, save it, and run an update manually.
- Choose a node: Start with a route whose target region is clear and whose name is complete; do not enable multiple clients at once.
- Connect: Turn on the client’s system proxy or tunnel mode, then visit a network test page to verify the exit address.
What to expect after importing
Under normal conditions, the client shows a subscription group containing selectable nodes. Node names usually indicate a region, city, entry point, or route type. Clients may display names, sorting, and groups differently, but the core configuration should come from the same subscription.
If the client says “Update successful” but shows no nodes, first check that you imported the subscription address rather than the dashboard page address. Also confirm that the client supports the protocols used by the subscription. Some clients parse only specific formats, so an incompatible format or protocol can produce an empty list even when the network itself is working.
When an update fails, rule out copy errors first
When a subscription update fails, copy the link again from the dashboard, delete the incorrect entry in the client, and paste the full link. Do not complete, shorten, or edit its parameters. You can also temporarily close other proxy software and retry, since another client may have taken over the system proxy and created a loop while the new client tried to update.
A significantly incorrect system clock can also affect protocols that use encrypted handshakes. Let the operating system set the date and time automatically, then update the subscription and reconnect to a node. If the current network restricts a type of transport, switch networks for comparison to distinguish a local network restriction from a subscription configuration issue.
Protocol compatibility determines whether the client can connect
A subscription is not the name of a single protocol; it is a way to distribute configuration. After receiving the subscription, the client must still support the protocols and transport combinations used by the nodes. Common types include Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC. They differ in authentication, underlying transport, congestion control, and client support, so the node name alone cannot confirm compatibility.
| Protocol | Key characteristics | What to check during import | Common limitations |
|---|---|---|---|
| Shadowsocks | Lightweight proxy protocol with broad client support | Encryption method and authentication details must be complete | Supported extensions may vary between implementations |
| VMess | Common in the proxy ecosystem | Transport method, host parameters, and system time | Older clients may lack support for newer transports |
| Trojan | Typically uses TLS for transport | Server name and certificate verification settings | An incorrect system clock can affect the handshake |
| VLESS | Compact authentication structure that supports multiple transports | Security-layer, transport-layer, and flow-control parameters | Older client versions may be unable to parse it |
| Hysteria2 | UDP-based transport scheme | Whether the client core supports the corresponding configuration | The connection may fail when the network restricts UDP |
| TUIC | Proxy transport based on QUIC concepts | Authentication, certificates, and congestion-control settings | Not supported by every general-purpose client |
Users generally do not need to enter protocol parameters manually. The subscription already includes the server address, authentication, and transport settings, and manual edits can break the connection. The key checks are whether the client core supports the protocol and whether the subscription generates the node completely after updating. If a node is missing in one client but appears normally in another compatible client, check parsing support before assuming the route is faulty.
Hysteria2 and TUIC rely on UDP. On office, public, or otherwise restricted networks, UDP may be limited, causing a node to time out while nodes using other transports connect normally. Compare another protocol or route type instead of randomly disabling system security settings.
Choosing between direct, relay, and IEPL routes
Protocols define how the client communicates with a node; route types define the network path used by the traffic. They are not the same thing. One protocol can run over different routes, and one route type can carry different protocols. For a first selection, check the target region first, then the path type, and only afterward confirm protocol compatibility.
| Route type | Path characteristics | Best suited for | What to watch |
|---|---|---|---|
| Direct | The local network connects directly to an overseas node | A simple path with stable cross-border network quality | Changes in the local carrier’s routing have a more direct effect |
| Relay | Traffic reaches a nearby entry point before being forwarded to the target exit | Improving the cross-border path in specific access environments | The entry and exit points must remain compatible |
| IEPL dedicated route | The cross-border segment uses a dedicated link for transport | Situations that prioritize stable cross-border paths and sustained interaction | Local access conditions and the target service can still affect performance |
Choose a region based on the requirements of the target service. For region-restricted content, developer platforms, or online services, the exit country and region usually matter more than the entry location in the node name. A relay route may enter through a nearby location but exit in another region, so use the post-connection exit test as the source of truth.
An IEPL dedicated route does not mean every segment from the device to the target website uses a dedicated link. The device-to-entry segment still depends on the current broadband or mobile network, and the exit-to-service segment depends on the local internet. The main difference is how the cross-border backbone segment is organized. Switching to IEPL may not fix local Wi-Fi packet loss, a target-site outage, or an account region restriction.
Verify the exit address, DNS, and routing after connecting
A client showing “Connected” only means the local connection process did not immediately report an error; it does not mean every app is using the expected route. Check the exit address, DNS resolution, and the actual app. Start with NeuVPN’s network test page, confirm that the exit region matches the selected node, and then test the target website.
The exit address does not match the node region
Refresh the test page first to rule out browser caching. Then verify the node currently selected in the client rather than relying only on the subscription group name. Some clients let different policy groups use different nodes, so the main screen may show a connection while the active proxy group remains on another exit. Automatic selection may also switch nodes based on rules.
A browser proxy extension, another VPN client on the system, or an enterprise network configuration may also override the current exit. During troubleshooting, keep only one connection tool enabled and reopen the browser. Do not run multiple system proxies, tunnels, or acceleration apps at once; they make the traffic path difficult to identify.
What is a DNS leak?
A DNS leak occurs when application traffic uses the proxy route but domain lookups are still handled by the resolver specified by the local network. This can produce results that do not match the exit region and expose queried domains to the local network. It does not mean the node is disconnected, but it can cause incorrect redirects, region-mismatched content, or slow connections.
Prefer the DNS setup provided by the client through the subscription or its rules, and confirm whether tunnel mode takes over domain resolution. Do not replace a resolver merely because its name looks familiar. Clients implement remote resolution, local resolution, encrypted DNS, and virtual-address modes differently; an incorrect combination can block local-network devices or cause some domains to fail.
Global mode vs. split tunneling
Global mode usually sends more traffic through the selected node, making it useful for an initial route test, but it may also send local websites, LAN devices, or software updates over international routes. Split tunneling uses domains, address ranges, apps, or rule sets to decide what goes through the proxy and what connects directly. It is better for daily use, but incorrect rules can make a browser work while an app fails, or send a homepage direct while its API requests use the wrong route.
For the first connection, start with the client’s default split-tunneling settings. If the target service fails, briefly switch to global mode for comparison: if global works but split tunneling does not, focus on rule matching; if neither works, continue checking the node, protocol, local network, and DNS. After testing, restore the mode that fits your needs.
How client behavior differs across platforms
The subscription can be identical, but the network permissions granted to the client differ by operating system. When moving to another device, do not look only for buttons with exactly the same names. Confirm that the platform has allowed the relevant VPN configuration, system proxy, or tunnel permission.
Windows and macOS
Desktop clients commonly offer system proxy and tunnel modes. A system proxy mainly affects apps that follow the operating system’s proxy settings; some games, command-line programs, and apps with their own network stack may bypass it. Tunnel mode usually covers more traffic but requires a virtual network component to be installed or enabled. After switching modes, test the exit again rather than assuming every process is covered.
The first time macOS enables related features, it may ask you to approve a network extension or system permission. If a Windows client cannot start tunnel mode, check permission prompts and the virtual network component status. Do not download supposed repair tools from unknown sources; use the client entry provided in the dashboard and the system’s own permission settings.
iOS and Android
On the first mobile connection, the system displays a confirmation screen to add a VPN configuration or allow the connection. The client can establish a system-level tunnel only after explicit approval. On iOS, supported protocols depend on the app’s core; on Android, background power-saving policies may also affect the client. If the connection pauses when the app goes into the background, check its background activity permission.
Switching between mobile data and Wi-Fi changes the underlying connection. The client may reconnect automatically, or it may retain a connected status while the actual session needs to be re-established. If the target service stops responding after a network switch, disconnect and reconnect before deleting the subscription.
Linux
A Linux client may use a graphical interface, command line, or background service. Subscription parsing, the proxy port, and route takeover are often configured separately. Starting only the core process may not modify the system proxy automatically, and setting environment variables may not cover desktop apps. Check the client documentation to determine whether it provides a local proxy, transparent forwarding, or a tunnel interface.
When troubleshooting in a terminal, avoid saving commands containing subscription addresses and authentication parameters in public logs. If the client runs as a system service, also confirm that the service reads the current configuration rather than another older file in a user directory.
A practical troubleshooting order for common issues
The key to efficient troubleshooting is changing one variable at a time. Do not switch clients, change nodes, edit DNS, modify rules, and reset the system network simultaneously; even if the issue clears, you will not know why. The sequence below starts with the account and configuration, then moves step by step toward the local network and target service.
- Confirm plan status: Log in to the dashboard and check whether an active subscription exists under the current account.
- Retrieve the subscription again: Copy the link from the dashboard, update it in the client, and confirm that the node list is generated.
- Check protocol support: Confirm that the client core can parse and connect to the protocols in the subscription.
- Use one node only: Disable automatic switching and other connection tools, then test a node in the target region by itself.
- Check the system clock: Let the operating system set the time automatically, then perform the handshake again.
- Compare routing modes: Compare the default split-tunneling mode with global mode to determine whether the rules are the problem.
- Change the route type: In the same exit region, compare direct, relay, and IEPL routes to identify path differences.
- Change the access network: Test on another network to identify local restrictions affecting UDP, DNS, or proxy connections.
- Submit a support ticket: Provide the operating system, client name, protocol type, node region, error text, and time of occurrence. Do not submit your password or the full subscription link.
The subscription updates, but every node times out
This indicates that dashboard access and subscription download can complete, but the node connection fails. Check the system clock, client protocol support, and local network restrictions first. Then compare another protocol or route type. If only Hysteria2 or TUIC nodes fail while others work, the issue may be related to UDP conditions on the current network.
Websites open, but apps cannot connect
Check whether the app follows the system proxy and whether the client has tunnel mode enabled. A browser may read the system proxy while command-line tools, games, or standalone apps connect directly. Split-tunneling rules may also fail to cover the domains used by the app. Temporarily switch to global mode for verification, then adjust the matching scope in the rules.
Only a specific website will not open
Confirm that the website itself is accessible, then check whether the exit region meets the service requirements. Clear the site cache and old session before reopening it so it does not continue using region information saved before the connection. If global mode works but split tunneling fails, check the domain rules. If every route fails, the cause may be the target service’s status, account region, or access policy.
Existing nodes disappear after a subscription update
A subscription update replaces the list with the content currently provided by the service. Do not rely on manually edited nodes remaining available, and do not mix an old configuration with the new subscription in the same group. If you need custom rules, place them in the client’s dedicated rule area instead of rewriting subscription-generated nodes.
Maintaining your subscription for everyday use
Even after the connection works, keep the subscription and client maintainable. Use the client’s subscription update function periodically to retrieve current node configuration, and recheck the protocol core and system permissions after a client upgrade. If an upgrade causes problems, read the release notes and review the mode settings before deleting all configuration.
If you suspect that the subscription link has been exposed, handle it through the user dashboard or a support ticket rather than deleting it only from the client. Removing a local entry affects the configuration on that device, not the link’s access status. On a shared device, sign out of the dashboard and clear saved sensitive information after use.
Routing rules also need to adapt to changing use cases. New apps may call different domains, and target services may change their endpoints. When something goes wrong, use the exit test, DNS results, and a global-mode comparison to locate the issue instead of guessing from node names. For developer tools, remember that terminal environment variables, container networking, and the system proxy are not always synchronized automatically.
Getting started after a VPN subscription purchase is essentially about connecting account status, configuration delivery, client compatibility, route selection, and connection verification into one checkable workflow. When something fails, checking subscription updates first, then protocol, node, exit, DNS, and rules is usually more effective than repeatedly reinstalling the client. When requesting help, clearly sharing the platform, client, route, and symptoms also reduces back-and-forth.