The real difficulty with "which cheap VPN is worth it" is this: price pages from different providers look almost identical, and the information that would tell them apart isn't on the price page. An international route costs money continuously — exit servers, relay entry points and bandwidth are all fixed monthly costs. When the price stays below those costs for long, a provider has only three ways out: sell one route to more people (overselling), print a bigger node number than it has (inflation), or stop the service at some point (shutdown).
All three leave traces you can see before you pay. Below they're broken out by risk type, each with one action you can actually take; none of it needs extra software — a browser and the command line already on your system are enough.
Three risks, one table first
The three risks look different and so do the checks. Start with the summary table; the sections after it go into detail.
| Risk | Typical sign | Check before ordering |
|---|---|---|
| Overselling | Fine by day, noticeably slower during the evening peak | Test the same node at three or more different times and see whether it only fails at peak |
| Inflated node counts | A large country count, but only country names — no cities, no route types | After connecting, look up the exit IP's location and compare it line by line with the client label |
| Provider shutdown | Only long-term plans, and no refund to be found in the terms | Read the refund terms, the payment receipt and the date of the latest announcement |
Of the three, overselling and inflated counts can be tested during a trial or refund window; a shutdown can only be covered by the terms. That's why refund terms deserve to rank above price.
Overselling: how many people your bandwidth is sold to
Overselling is the default state of every shared-bandwidth service; only the degree differs. A route's exit bandwidth is fixed, and the provider slices it among a group of users. If those users aren't online at the same time, nothing looks wrong; once the evening peak brings them all on at once, each person's share is diluted — which shows up as lower speeds, more packet loss and pages that need two spins before they load. The question isn't whether there's overselling, but how much.
The method is simple but needs repeating: same node, three or more tests at different times. One in the morning, one at evening peak, one late at night — and what you record is "does the same HD video open reliably, does a large download break off", not the number on a single speed-test screenshot. A single test is skewed by your local network, Wi-Fi interference and where the test server sits, so it's worth very little. If everything is fine by day and reliably collapses at evening peak, that route is almost certainly sold too many times over.
Many reviews quote a one-off peak speed. A peak only shows that nobody else was on the route at that moment; it says nothing about whether you can use it at 8pm.
Inflated node counts: the bigger the number, the more you need to break it down
Phrases like "120+ countries, 180+ routes" mix three separate things: the number of countries and regions, the number of routes, and the number of servers. They need not correspond at all. Three common ways the numbers get padded:
- One server with several entry points, each labelled as a different city;
- The city hosting the relay entry labelled as the exit country, when the real exit is elsewhere;
- DNS or routing rules that make a lookup page return a "correct-looking" answer while the real exit hasn't moved.
The check is straightforward: connect to a node, open any page that reports the location of your exit IP, and see whether the country and city match the client's label; then repeat with two or three nodes in other countries. If the node labelled "Germany" exits on another continent, that node list is decoration.
The second thing to look at is whether the route type is spelled out. A "Japan node" can mean very different things depending on whether it's direct, relayed or an IEPL dedicated line:
| Type | Traffic path | What it means | Best for |
|---|---|---|---|
| Direct | Local → public international gateway → overseas server | Lowest cost; vulnerable to congestion at the international gateway during peak hours | Light browsing, occasional use |
| Relayed | Local → domestic relay entry → overseas exit | The relay leg uses a higher-quality domestic route; the exit leg still runs over the public internet | Everyday access, price-sensitive users |
| IEPL dedicated line | End-to-end dedicated line that never touches the public international gateway | Fixed bandwidth, stable latency, billed on committed bandwidth, highest cost | Meetings, long-lived connections, anything that needs stability |
There's a conclusion here you can reach yourself: IEPL is billed on committed bandwidth, so its unit cost is far above a public-internet relay. If a cheap plan claims "all routes are IEPL", either only a handful of nodes are dedicated lines, or the claim doesn't hold. It's not that you can't buy it — just know which leg you're paying for.
Shutdown risk: reading the signals in the terms and the payment methods
A shutdown isn't random; there are usually warning signs. The longer the subscription term and the larger the prepayment, the more users lose when the service stops — which is exactly why long plans get pushed hardest. Signals worth watching:
- Only long-term plans, no monthly option;
- No refund section in the terms, or a flat no-refunds policy;
- The node list hasn't been updated in months and announcements stop months back;
- One support channel only, and questions go unanswered for a long time;
- A brand-new brand and domain that claims to have been running for years.
Payment methods are worth a look, but don't read them as a trust score. Alipay and WeChat leave a transaction record, so there's at least a traceable receipt if a dispute arises; on-chain transfers like USDT are irreversible — once sent, they can't be pulled back, which makes them a better fit for established users who already trust the provider. A normally run product usually offers several options rather than leaving just one.
What a long-term plan saves you is only realised if the provider lasts the whole term. With no refund clause, you're effectively making a prepayment with no guarantee.
Three hands-on tests: spotting problems without specialist tools
The sequence below takes about ten minutes; run it during the trial or refund window. The three steps cover the exit, DNS resolution and traffic splitting.
- Check the exit IP and its location. Connect to the node, open a terminal and run the command below, then see whether the country and city it returns match the client's label. Disconnect and run it again — the two results should differ; if they're identical, your traffic isn't going through the node at all.
- Check who's resolving your DNS. Run nslookup and look at which resolver the Server line points to. If resolution still lands on your local ISP while connected, that's a DNS leak: domain lookups can be poisoned, and what you're trying to reach is exposed to the local network.
- Verify per-app and per-time-slot. Use a browser and a non-browser app (a sync client or a command-line tool will do) to reach the same overseas site, confirming both kinds of traffic go through the node; then repeat at evening peak to see whether it only fails in a particular window.
# 1. Exit IP and location: run once before connecting and once after, then compare
curl -s https://ipinfo.io/json
# 2. The DNS resolver your system is currently using
nslookup example.comAll three steps coming out as expected only means this particular route works right now. It doesn't prove the provider isn't overselling, and it doesn't prove the node numbers are honest — those two can only be judged over time and through the terms.
A note on client differences. The same subscription link can behave differently across systems: Windows clients generally support full rule-based routing and per-process proxying, some macOS clients take over the system proxy in a different way, and mobile leans more on global mode. If it works on your computer but not on another device, suspect the client's routing configuration before the route itself. A subscription link is effectively an account credential — anyone who has it can use your traffic — so don't paste it into group chats or share it as a screenshot.
Which promises cannot be verified at all
Some marketing lines share one trait: they sound strong, and there is no way from outside to prove them false. Treat the following as marketing copy, not specifications.
- "Unlimited traffic." Bandwidth has a physical ceiling; every "unlimited" comes with speed or connection caps, they're just not stated where you'd notice.
- "Lifetime validity." How long a service exists depends on the operator, not the wording. What can be promised is a concrete rule such as "this data pack doesn't expire" — not "forever".
- Assorted "XX-grade encryption". These aren't standard cryptography terms and don't map to any specific algorithm. What actually matters is the protocol and its configuration, not the adjective.
- "No logs." That's a statement of position, not a verifiable fact. The sensible approach is to check whether it spells out what is recorded, how long it's kept and under what circumstances it would be handed over — not how loudly it's claimed.
Protocols deserve their own paragraph, because they directly decide whether you can connect at all. VMess is sensitive to client time, and a large system clock offset makes the handshake fail outright; Trojan disguises itself as ordinary HTTPS traffic on port 443 and holds up better on tightly restricted networks; Hysteria2 and TUIC run over QUIC (UDP) and do better on lossy links, though some networks throttle UDP, where TCP-based protocols win instead. A mature client should let you switch protocol and route type within the same subscription, rather than giving you one default.
Pre-order checklist
The sections above, compressed into one list. Ticks are things you can confirm before ordering; crosses are things that should make you slow down.
- ✅ Clear refund terms with a stated number of days, such as a 7-day no-questions refund, rather than no refunds at all.
- ✅ Each price tier states its included traffic right beside it, so you can work out the cost per unit of traffic yourself.
- ✅ The node list gives specific cities and route types (direct / relayed / IEPL), not just country names.
- ✅ Sign-up needs only a username and password, with no email address — one less piece of personal data to be breached or marketed to.
- ✅ Supports payment methods with transaction records, such as Alipay and WeChat, so you have a receipt if something goes wrong.
- ✅ There's a public announcements or changelog page where you can see when the routes were last adjusted.
- ✅ No cap on simultaneous devices, so you don't have to buy a second plan for one more computer.
- ❌ Describing the service itself as "unlimited" or "forever" without stating any conditions.
- ❌ Only multi-year plans, and the word refund doesn't appear in the terms.
- ❌ A dozen near-identical entries for the same city in the node list, counted as different countries.
- ❌ One support channel only, with questions unanswered for days.
VPNAJ's published specs
Put VPNAJ through the same standard and here's what can be published. Every figure can be checked item by item on the pricing page and the network page — you don't have to take this article's word for it.
Monthly plans come in three tiers: ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB, with traffic resetting each month on the activation date and mid-term upgrades prorated against the remaining days. Data packs are ¥158/300GB, ¥358/1000GB and ¥658/3000GB, used until they run out and never expiring. Payment supports Alipay, WeChat and USDT; signing up needs only a username and password, no email address; encryption is uniformly "Quantum Encryption". These are rules you can act on, not adjectives.