Start with one simple relationship: a subscription provides configuration, a node is a connection endpoint, a protocol defines how data is transmitted, and routing determines where requests go. If you connect but a website won’t load, troubleshoot each layer instead of repeatedly switching clients.
A VPN client may be a system-level tunneling tool or a proxy client that handles traffic through a system network interface. The terms aren’t interchangeable based on name alone. This guide covers general configuration concepts; it doesn’t mean VPNWish supports every protocol or client feature mentioned. Check the control panel and setup guides for current compatibility.
A subscription link is not the same as a plan
A plan covers service benefits and typically defines data allowances, billing periods, and usage terms. A subscription link is the address a client uses to retrieve configuration. It may provide a list of nodes, as well as policy groups, routing rules, and DNS settings, depending on the server’s output and the client’s capabilities.
“Update subscription” usually means fetching the configuration again. It doesn’t renew your plan or necessarily switch your current connection. Some clients keep the previously selected node; others require you to select a policy group again. After updating, check whether the node list changed, make sure the configuration is enabled, and confirm your current exit location.
Subscription links often contain access credentials, so protect them like passwords. Before sharing screenshots or logs with support, hide the full link and any tokens in it. If a link has been exposed, use the reset option in the control panel as soon as possible, then update the configuration on each device.
A link that works with one client may not work with another. Some clients accept a complete configuration file, while others only accept node share links. If importing fails with a format error, check the client name and subscription type in the setup guide. Don’t submit the link to an untrusted online converter.
What do nodes, routes, and exit locations mean?
A node is usually a selectable connection profile in a client, containing details such as a server address, port, credentials, and protocol parameters. A route describes the network path the data takes. An exit location is the public IP address and network location that the destination website sees. They’re related, but not interchangeable.
A node labeled “Japan” might first connect through an entry point in your region or a nearby one, then relay traffic to an exit in Japan. The entry address, node label, and exit location detected by a website may therefore differ. Labels can help you choose, but check the actual connection afterward.
| Term | What it does | What it doesn’t tell you |
|---|---|---|
| Subscription | Delivers nodes or a complete configuration to the client | A successful import doesn’t mean you’re connected |
| Node | Provides the settings for a specific connection | Its name doesn’t indicate whether it’s currently available |
| Route | Carries data from the entry point to the exit | The route type doesn’t determine real-world speed |
| Exit location | The public identity seen by the destination service | A matching location doesn’t guarantee access to content |
| Policy group | Organizes manual selection, automatic checks, or failover | The selected group name may not be tied to a single node |
Choose a location that meets the destination service’s requirements, then compare how the relevant nodes perform. Don’t focus only on the lowest latency in the list: a fast entry-point test won’t help if the exit is congested, and pages or videos may still load slowly. A node with slightly higher latency may work better for sustained downloads.
How to tell IEPL private lines, relay, and direct connections apart
A direct connection usually means the client connects to an overseas server without an additional relay entry point arranged by the provider. The traffic still passes through carrier routes and internet exchanges. “Direct” doesn’t mean a single physical hop or guarantee the shortest path.
A relay adds a forwarding step between the client and the final exit. It can help organize access, carry traffic between regions, or manage connections. A well-planned route may improve performance, while a congested entry point or detour may slow it down. A relay isn’t automatically better than a direct connection.
IEPL usually refers to an international Ethernet private line that may carry traffic within a provider’s network. An IEPL label doesn’t mean the entire path from your device to the destination website uses a private line. Home broadband, wireless networks, entry-point access, and the destination’s response all affect performance.
Treat route types as a way to narrow down your options, not as a speed guarantee. During the hours you actually use the service, compare page loads, playback, and disconnections on the same website or app. Change only the node and keep other conditions the same to identify what makes the difference.
How do protocols relate to client cores?
A protocol defines how the client and server authenticate, transmit, and protect data. The client core implements protocols and handles tasks such as matching rules and reusing connections. Clients with similar-looking interfaces may support entirely different protocols, transport settings, and configuration formats.
- Shadowsocks: An encrypted proxy protocol commonly used to forward TCP and UDP traffic. A particular encryption method works only if both the client and server support it.
- VMess: An authenticated proxy protocol. An incorrect system clock can interfere with authentication, so check that the device’s time is correct before resetting a password.
- Trojan: Typically uses TLS to protect the connection between client and server. Certificate validation and server name settings are both important parameters.
- VLESS: Doesn’t provide payload encryption on its own and is often paired with security mechanisms such as TLS or REALITY. The protocol name alone doesn’t tell you what encryption is in use.
- Hysteria2 and TUIC: Based on QUIC and dependent on UDP connectivity. Nodes using these protocols may fail to connect if the current network restricts UDP.
A newer protocol isn’t necessarily better, and an older one isn’t necessarily worse. Reachability, server configuration, transport routes, and client implementation all affect the outcome. If importing fails, check compatibility first; if connecting fails, check the network, credentials, and transport settings. Don’t disable certificate verification just to clear an error.
TLS can protect the connection between your device and the server, but it doesn’t replace HTTPS on the destination website. Check the website address and certificate warnings as usual. An encrypted connection isn’t a universal solution to every privacy risk.
Rule-based routing, global mode, and TUN
Rule-based mode directs requests to different policies—direct, proxy, or blocked—based on domains, addresses, processes, or regions. Rules are usually matched in order, so an overly broad rule near the top can prevent more specific rules from taking effect.
Global mode usually sends all requests handled by the client through the selected proxy policy. It can help you check whether a problem is caused by routing rules. But “global” doesn’t necessarily cover every app on your device: apps that ignore the system proxy may still connect directly if the client only configures that proxy.
TUN uses a virtual network interface to handle IP traffic. It isn’t a node protocol or an exit location setting. Enabling it may require additional permissions and can conflict with other VPNs, routing tools, or network filtering software. Whether DNS is also handled depends on the configuration.
For everyday use, start with the rules provided by the service. If one app has a problem, switch to global mode temporarily for comparison. If global mode works but rule-based mode doesn’t, check which rules match, the policy group, and DNS. If neither works, check the node and the app’s own requirements. Switch back to your preferred everyday mode when testing is done.
Understanding DNS resolution and leaks
DNS translates website domain names into addresses your device can connect to. A successful lookup doesn’t guarantee the connection will work; an unsuitable address can also cause one website to fail while other sites work on the same node. The browser, operating system, and proxy client may each have their own cache.
A DNS leak generally means that DNS requests aren’t following the expected controlled path and are instead being sent to another resolver. That resolver can see the domains being queried, but this doesn’t mean it can see the contents of HTTPS pages. Whether a request counts as a leak depends on your intended routing policy; seeing a local resolver alone isn’t enough to draw a conclusion.
Check the browser’s secure DNS, system DNS, and client DNS settings together. A leak test shows which resolver handled requests during the test; it isn’t a complete privacy audit. If you route traffic by region, using different DNS paths for local and international sites may be expected.
Don’t change system DNS, browser settings, and client rules all at once. Change one thing at a time and note what happens before and after. Otherwise, even if access is restored, it’ll be hard to identify the actual cause.
A step-by-step process: import, connect, troubleshoot
Once you know the terms, keep “getting the configuration,” “turning on the connection,” and “checking the app” as separate steps. VPNWish users can get a subscription after signing in. Clients are available to download after sign-in, except on iOS, where a valid plan is required. Find client downloads in the setup guides; a subscription link is not an installation file.
- Check your platform and client. Desktop systems may require permission to use a network extension or virtual interface; mobile systems usually ask you to authorize a VPN configuration. Permission prompts vary, so follow your system’s instructions and the setup guide.
- Import the right configuration. Use the client’s subscription or configuration import option and wait for the update to finish. Check that a node list appears before enabling the configuration.
- Choose an exit and connect. Check which node the selected policy group actually uses. Automatic selection may switch exits on its own, so keep this in mind if you need a consistent location.
- Test the app you need. Open a regular webpage first, then try the destination service. The location a website assigns to you may also depend on your account, access permissions, cache, and risk controls, so don’t rely on the public IP address alone.
- Keep useful diagnostic details. Note your operating system, client version, node name, error message, and what you were doing when the issue occurred. Hide credentials before sharing logs, and contact the support team to investigate further.
- ✅ Import error? Check the subscription format and client compatibility before switching routes.
- ✅ Connected, but pages aren’t working? Check the current policy, DNS, and system time, then compare with another node.
- ✅ Only one app is affected? Check whether it follows the system proxy and needs additional traffic handling.
- ❌ A speed test result, node name, or route label doesn’t guarantee that an app will work.
Keep the roles straight: subscriptions deliver configuration, protocols handle communication, nodes and routes determine the connection path, rules direct requests, and DNS resolves domain names. Checking one layer at a time makes it easier to find the cause than reinstalling the client, clearing rules, and changing network settings all at once. It also makes the issue easier to explain to support.