How to avoid pitfalls when buying a VPN: overselling, inflated node counts, and shutdown signals explained

Services in this category all look alike on the surface: a wall of country flags, a long list of server names, and the same promise of fast, stable connections. The real differences aren't in the marketing copy — they're in a handful of details you can verify yourself. This article doesn't hand out verdicts; it hands out checks. Every one of them can be run before you pay, or inside the refund window.

Which numbers you can verify, and which to skip

The numbers on a provider's site fall into two groups.

The first group can be verified: how many countries and regions are covered, how many routes there are, how long the refund window lasts, how many devices can be signed in at once, and which platforms are supported. These are either firm commitments or things you can confirm on the spot during a trial.

The second group can't be verified: live user counts, uptime percentages, average latency. These numbers shift with the time of day, your city, and your ISP's outbound routing, so nobody can check them even when they're printed on the page. When you see numbers like these, skip them — they don't change your experience, only your judgment.

Here's what the first group looks like, using this service's published figures as an example:

What these numbers have in common: every one of them can be confirmed before you pay and verified during the trial period. Focusing here while you shop will save you more time than reading ten reviews.

Overselling: the usual cause of peak-hour slowdowns

Bandwidth is a shared resource. A provider buys a block of international bandwidth upstream and splits it among all its users. When the concurrent capacity it sells exceeds what it actually has, that's overselling. Overselling itself isn't rare — what matters is how much of it there is, and whether peak hours crush the experience.

Overselling follows a very predictable pattern:

• Fine during the day, noticeably slower between 8 p.m. and 11 p.m.;
• Not one slow route, but every route slowing down at once;
• Video dropping from HD to standard definition, calls stuttering and dropping words;
• Worse on weekends and holidays than on weekdays.

If only a few servers are slow, that's single-node overselling, and switching to another entry point usually helps. If every server slows down in the same time window, the problem is upstream bandwidth, and switching servers won't fix it.

A good enough method: at 10 a.m. and again at 9 p.m., run a test on the same device against the same test server, and record download speed and packet loss. If peak-hour speed is only a fraction of what you get during the day, and it stays that way for several days, that's a sign of overselling.

Inflated nodes: how route counts get padded

Route count is the easiest number to dress up, because there's no standard definition for it. Four common ways to pad it:

• Counting countries as routes: one country equals one route, even if it only has one or two exit cities;
• Splitting one entry point into several: the same server with a few open ports, listed as multiple routes;
• Padding with protocol names: VMess, VLESS, Trojan, Hysteria2, and TUIC are transport protocols, not routes;
• Listing regions but not cities: everything in the list reads Japan or United States, and you can't tell where the exit actually sits.

To read a route list properly, first separate the three route types:

A list that spells out route type and city is far more trustworthy than one that only counts countries. A screen full of direct routes and a screen with a batch of IEPL dedicated lines are two very different things.

There are four steps to checking:

1. Check the granularity: a list that names cities and route types tells you far more than one that only names countries.
2. Check the exit: once connected, run an IP geolocation lookup and compare. A route labeled Tokyo should show an exit IP in Japan. The built-in IP lookup shows your current exit location directly.
3. Compare entry points: if several routes in the same region share the same exit IP, they're just different entry points, not different routes.
4. Check the subscription: a subscription link is a URL that your client pulls server configurations from on a schedule. If a service only lets you sign in through its own app and won't give you a subscription link, you can't switch clients or verify the servers.

Shutdown signals: when to stop and walk away

Services usually show signs before they shut down. Any one of the signals below on its own may mean nothing, but if two or three show up together, it's time to put your renewal plans on hold.

• Suddenly pushing only very long terms: lifetime plans, multi-year one-time payments, discounts too steep to be reasonable;
• Payment options narrowing: from public channels down to a personal payment code, or a request to transfer to a private wallet first;
• Support channels disappearing: the ticket system closes, only a direct-message account remains, and replies go from hours to days;
• App and announcements going stale: no version updates for six months, the last announcement months old;
• Routes quietly shrinking: the server list gets shorter, dead servers aren't replaced, and routes keep getting renamed;
• The community turns into ads only: user feedback gets deleted and people get removed from the group.

Refunds, payment, and signup requirements: three details people overlook

Refund promises

The words “refunds supported” carry very little information. Ask three things: how long the window is, whether there are conditions attached, and where you apply. This service's stated policy is a 7-day no-questions-asked refund — the key part being “no questions asked,” which means you don't have to explain yourself or prove you never used it. If a refund policy is full of conditions like “unused” or “within the data allowance,” the cases that actually qualify will be far fewer.

Payment channels

Having Alipay, WeChat, and USDT side by side suggests the payment pipeline itself is stable, and it leaves the choice to you: USDT doesn't pass through the banking system, at the cost of being irreversible; Alipay and WeChat leave a transaction record, which makes problems easier to trace. If a service is down to a single payment method and asks you to transfer privately, that alone is worth treating with caution.

Signup requirements

What a signup form asks for tells you how a service treats your information. Requiring email verification, linking a third-party account, or asking for more personal details all mean more data sitting on someone else's servers. This service works differently: no email address is required to register, a username is enough to get started, and the privacy policy is anonymous and log-free.

The pre-purchase checklist

Here's everything above condensed into one checklist to run through before you order:

• ✅ The route list names cities and route types, not just a line about global servers.
• ✅ Refund window, conditions, and where to apply are stated openly; this service offers a 7-day no-questions-asked refund.
• ✅ Public payment channels such as Alipay / WeChat / USDT are supported, with no private transfers needed.
• ✅ Signup doesn't ask for more than it needs; this service requires no email address to register.
• ✅ Apps cover Windows / Android / iOS / macOS / Linux, and the subscription link can be exported.
• ✅ Pricing and data allowances are on the plans page, starting at ¥9.9 per month, with no need to ask support.
• ❌ Only lifetime plans or very long terms are sold, with discounts too steep to be reasonable.
• ❌ Support is a single direct-message account, with no ticket or email channel.
• ❌ The page shows live user counts, uptime percentages, and other numbers nobody can verify.
• ❌ The route list gives only a country count, with no cities or route types.
• ❌ The app hasn't been updated in ages and announcements have been silent for six months.
• ❌ You're asked to transfer privately, to a personal account rather than a public channel.

Already ordered? Three things to do inside the refund window

Buying isn't the end of the process. The refund window is the cheapest testing period you'll get; do these three things in order and you'll know whether to stay or ask for your money back.

1. Test at peak hours. Between 8 p.m. and 11 p.m., use the service on your usual device for half an hour straight: try a video call, HD video, and a code repository pull. How it performs in that window is what most of your future usage will feel like.
2. Check the exit and DNS. Once connected, look up the IP geolocation and compare it with the region you picked. While you're at it, check DNS: if your traffic goes through the route but domain resolution still goes to your local ISP, that's a DNS leak — you may get resolved to the wrong address, or have the domains you visit visible locally. Testing is simple: connect to the route, open any DNS leak test page, and see whether the resolving server's location matches the route.
3. Walk through the subscription setup. Install the client on all five platforms and import the subscription link once on each, confirming the server list is complete and switching works. This step catches the “it only works on one system” problem early.

If you want to understand the difference between route types and protocols first, see Routes and protocols explained; to see which regions and routes this service currently offers, the route list has the full rundown.