Which VPN is trustworthy? Before you pay, spot overselling, fake claims, shutdown risks, and use this checklist

Warning signs: Turn marketing claims into questions you can verify

Save the plan details and terms of service, then compare them with what appears in your account dashboard. If the marketing page, checkout, and help docs contradict one another, ask for clarification before paying instead of relying on whichever statement sounds most favorable. These signs are screening prompts, not a verdict on any particular service.

A domain being temporarily unavailable or support not replying right away doesn’t prove the service has shut down. Conversely, a working website doesn’t prove that the routes or support are functioning. Consider connection status, announcements, the account dashboard, and actual ticket outcomes together.

How to check for Overselling: Compare time of day and your local network

Overselling means demand exceeds the resources available to a service. Congestion can occur at the entry point, an intermediate hop, the exit, or on shared bandwidth. One slow download won’t tell you where the bottleneck is: local Wi-Fi, your ISP’s route, the destination site’s speed limits, client rules, or background downloads can all produce similar symptoms.

Keep your device, destination site, and client settings the same during testing, and compare peak and off-peak hours. First check whether the site loads normally without the proxy, then compare different exits. If direct access is also slow, troubleshoot your internet connection first. If only one destination is slow, the issue may be with that service or its route.

1. Pause background downloads and note the connection time, network used, server name, and symptoms.
2. Use the same client to visit the same destination, and compare page loads, video buffering, or file transfers.
3. Try a different exit location, then a different access network, so a local issue isn’t mistaken for service congestion.
4. Send your findings to support and ask whether there’s maintenance, congestion, or a known routing issue.

Low latency doesn’t mean high sustained throughput. Latency measures the round trip for a probe request. Smooth video playback also depends on packet loss, bandwidth, the streaming platform, and connection quality over time.

If several exits repeatedly slow down during the same busy periods and behave similarly on a different local network, that may point to server-side congestion. But client logs alone usually can’t prove the extent of overselling—and shouldn’t be used to make unverified claims about capacity.

Server counts: Distinguish entry points, exits, and configurations

A name in a client may represent a protocol configuration, a different entry point, or a shared exit. Multiple names for one location don’t automatically mean the service is inflating its numbers. The concern is whether configuration counts are presented as distinct locations or imply that every name has dedicated bandwidth.

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are proxy protocols or transport options—not location names or direct indicators of route quality. Client support for a protocol doesn’t mean the service provides it. Different configurations using the same exit don’t reveal how many independent servers exist.

An IEPL line describes how traffic is carried, not the client’s encryption protocol. A relay usually means traffic passes through an intermediary before reaching the exit; a direct connection usually means the client connects to an overseas server without that intermediary, but traffic still travels over ISP networks. “Dedicated line” in a server name doesn’t mean the entire end-to-end path is exclusively yours, nor does it guarantee permanent access to a destination platform.

• ✅ Check how location coverage and route counts are measured; distinguish selectable configurations from independent exits.
• ✅ After connecting, check the exit IP and its reported location. Geolocation databases may not be up to date.
• ✅ Test the services you actually use; a location label doesn’t guarantee a platform will work.
• ❌ Don’t infer bandwidth or privacy from a server name, flag, or protocol name.

The same exit IP may indicate a shared exit or different entry points converging on one exit; that alone doesn’t prove inflated claims. Different exit IPs don’t prove the underlying resources are separate, either. More useful questions: Do the routes work on your network, and is there a genuinely usable alternative if one fails?

Privacy checks: Client apps, subscriptions, and DNS

Download the client from the link in the service dashboard or from the project’s official release channel. Installation and permissions vary by platform: desktop clients may require a system proxy or virtual network adapter, while mobile clients typically need system VPN permission. Permission prompts indicate that the client can handle the relevant traffic; they don’t certify the service’s trustworthiness.

A subscription link typically contains access credentials and can be used to retrieve server configurations. Treat it as sensitive information: don’t paste it into public testing sites, comment sections, or screenshots. If importing fails, first check which subscription formats, protocols, and configuration versions the client supports. Don’t hand the link to an unfamiliar conversion service.

A DNS leak occurs when domain lookups take a path you didn’t expect. Turning on a system proxy may not route traffic from every app or all system DNS requests. Your browser’s encrypted DNS settings may also use a different resolution path. In split-tunnel mode, some traffic is meant to connect directly, so seeing a local address doesn’t necessarily mean the configuration has failed.

Test each part separately: check the exit first, then the DNS lookup path, and finally whether the target app matches the proxy rules. If your device has IPv6 connectivity, check that this traffic is handled as expected too. An IP lookup only shows the exit used for that particular request; it can’t prove that every app on the device is routed through the proxy.

Payments and support: Know how to leave first

Price and time in business can’t eliminate the risk of a service shutting down. A practical way to reduce risk is to understand what’s included and how refunds work before deciding to prepay. Don’t increase your prepayment just because a promotion is counting down or people in a group are urging you to act before you’ve checked how the service works.

When checking a plan, confirm the billing period, data reset date, what happens when you run out of data, upgrade rules, and device limits. “No device limit” doesn’t mean unlimited data or automatically allow account sharing or resale. A data package that never expires describes the data’s validity period—not a guarantee that the service will operate forever.

Read the full refund terms and confirm where to submit a request and what order details are required. Don’t assume “refunds available” means you’ll automatically get your money back under any circumstances. Save the terms you saw before paying so you can refer to the actual agreement if there’s a dispute, rather than relying on a vague promise in chat.

You can assess support by asking about a specific issue—for example, how to import a client configuration or what troubleshooting steps to take after sharing an error message. Whether the answer addresses your question and whether support follows up are more useful indicators than how often a promotional channel posts. Redact passwords, subscription credentials, and sensitive payment details before submitting a ticket.

If your connection stops working, don’t send extra money to an account of unknown origin or share your account password to “fix your subscription.” Use the original site to check your orders, announcements, and support tickets, and verify that any instructions really came from the service.

Before you pay: A checklist for pages and real-world results

Use the checklist below to compare services and keep a record of each check. A page existing doesn’t make its claims trustworthy, but missing terms, unclear service details, and no support channel make verification harder. If key questions still get vague answers, pausing payment is more effective than guessing.

• ✅ Plan details are clear: price, billing period, data allowance, reset terms, and device policy are consistent.
• ✅ Route details are clear: location coverage, selectable configurations, dedicated lines, and relays are distinguished—not just listed by name.
• ✅ Client source is clear: the download link is verifiable, and the client supports the protocol and subscription format.
• ✅ Privacy details are clear: the logging policy and data handling terms are available, without relying on absolute claims instead of a real policy.
• ✅ Refund process is clear: you know where to submit a request and can keep order and support records.
• ✅ Results can be checked: verify the exit, DNS, split tunneling, and target apps separately, and record any issues.
• ❌ Don’t treat a speed-test screenshot, group reviews, server count, or low price as proof of trustworthiness on its own.

For example, VPNRB’s published plans include monthly subscriptions at ¥9.9 / 60GB, ¥18 / 250GB, and ¥28 / 500GB. Data resets monthly on the activation date, there’s no device limit, and there’s a 7-day no-questions-asked refund policy. Data packages remain valid until used and never expire. Before purchasing, check the selected option on the Plans page; don’t confuse monthly subscription terms with data package rules.

VPNRB lists coverage in 110+ countries and 240+ routes, including IEPL lines. Those figures don’t replace testing the connection yourself. The service states that it keeps no logs, uses a username and password, and doesn’t require an email address. See the global server locations for route and location details, use the IP lookup to check your exit, or start troubleshooting in the FAQ.