You can't judge whether a VPN is reliable by the length of its server list or the price of its plans alone. Check the refund policy, test the services you regularly use on your own network, and see whether support is reachable when something goes wrong. Overselling, misleading server claims, and shutdown risks concern capacity, accuracy, and business continuity respectively, so assess them separately.
The evidence available before you pay is always limited. Rather than ranking a service based on a single speed test, this guide offers repeatable checks: rule out local issues, verify route details, and limit upfront payments and the account information you share.
Slow at peak times? How to check for overselling
Overselling generally means a provider has sold more capacity than its shared resources can handle during periods of high demand. It can affect entry bandwidth, cross-border links, exits, or other shared infrastructure. But a slowdown at peak times alone doesn't prove overselling: local Wi-Fi interference, ISP congestion, and limits imposed by the destination site can cause similar symptoms.
Keep the device, connection type, and task as consistent as possible when troubleshooting. Don't compare a page loading over wired internet with a large download over Wi-Fi. Record the time, entry location, client mode, and specific symptoms; this is more useful for diagnosis than a speed-test screenshot alone.
| What you notice | Possible cause | What to check next |
|---|---|---|
| Regular websites are slow even with the proxy disconnected | Local network or ISP congestion | Check your Wi-Fi signal and test again on another connection |
| One destination is slow, but other tasks work normally | The destination service, exit route, or account restrictions | Try another exit and check the destination service's status |
| Several locations on the same entry are slow at once | Congestion at a shared entry point or on a shared backbone | Compare other entry points and send your records to support |
| Things repeatedly slow down at busy times but recover later | Capacity constraints or time-of-day ISP congestion | Repeat the same task at different times and note the support response |
| Speed tests work, but apps fail to connect | Routing rules, DNS, destination region restrictions, or app compatibility | Check which rules are applied and review the app's error message |
Repeated congestion over time, combined with a provider that can't explain its scope or offer an alternative route, is a stronger warning sign. Conversely, one fast download doesn't prove there's enough capacity: a speed-test server may use a different route from your regular services, and the test may not cover the times you usually connect.
Which servers and locations should you verify?
Server names in a client are configuration labels, not proof of infrastructure. Different names may share an entry point or exit; several routes in one region may serve different carriers or paths and don't necessarily indicate misleading claims. What matters is whether the provider clearly explains locations, entry and exit points, and route types.
After connecting, use an IP lookup to check your exit IP and its reported location, then compare it with the region shown by the destination app. IP geolocation databases can lag or disagree, so one conflicting result isn't enough to prove a location claim is false. If the mismatch persists and the provider can't explain it, treat that as a reason to be more cautious.
IEPL, transit, and direct connections describe different ways of routing traffic, not speed tiers. IEPL generally refers to a dedicated Ethernet connection provided by a carrier, but traffic between you and the entry point, or from the exit to the destination, may still use public networks. Transit routes traffic through an additional server; a direct route generally avoids an extra relay entry point set up by the provider. The label alone doesn't guarantee a particular experience.
Refund terms: what to check before paying
“Refunds available” isn't enough to know what you can actually claim. Find the full terms and check when the application window starts, which orders qualify, what's covered, where to apply, and how refunds are processed. In particular, distinguish “after the first payment” from “after each renewal,” and a refund to the original payment method from credit added to your account; these mean different things for you.
Save the plan details, terms page, and order records as they appear when you pay. If the page contains only promotional copy and no complete conditions, ask for clarification before paying. If support's explanation conflicts with the published terms, ask which version governs rather than relying on a vague assurance in chat.
- ✅ Find the complete refund policy and confirm which orders qualify.
- ✅ Check whether requests must go through a support ticket, account dashboard, or public contact channel.
- ✅ Confirm whether refunds are full and whether the payment provider imposes any additional restrictions.
- ✅ Keep your order and terms, but don't save or forward your account password or full subscription link.
- ❌ Don't treat “support said yes” as a promise without conditions.
VPNCar describes its refund offer as “7-day no-questions-asked refunds.” The full terms say, “You can request a no-questions-asked full refund within 7 days of your first payment.” The period starts with the first payment. To assess whether the service works for you, test your usual tasks within the refund request window instead of waiting until renewal.
Payment methods and long-term prepayment: limit your sunk costs
A cheap annual plan doesn't mean a provider will necessarily shut down, but paying far ahead means trusting the provider to deliver more service in the future. Even a successful test today says nothing definitive about its future finances, operational capacity, or business continuity. Confusing “works now” with “reliable long term” is a common mistake.
Before paying, check the order total, billing period, data rules, and where the payment page comes from. A payment method's availability doesn't mean its provider guarantees service quality; check that provider's actual rules for disputes and reversals. Be especially cautious if a discount requires you to leave the official checkout and transfer money privately; verify the receipt and who is responsible for support.
A monthly subscription can help you assess ongoing use; a data plan lets you use data as needed, but neither removes business risks. VPNCar monthly plans are ¥9.9 / 60GB, ¥18 / 250GB, and ¥28 / 500GB, with data reset monthly on the activation date. Data plans are ¥158 / 300GB, ¥358 / 1000GB, and ¥658 / 3000GB, with no expiration. Check the plans page for details.
How to check support channels and privacy information
Reliable support isn't about how many contact options appear on a page. What matters is whether the channels work, support understands the issue, and you can keep a record. Before paying, ask a specific question, such as where to submit a refund request or which subscription format a particular client needs. A clear, verifiable answer is more useful than a vague “we support everything.”
Also check whether there's a public contact page if you can't access your account dashboard. During an outage, the dashboard and ticket system may both be affected, so don't rely entirely on a contact route that requires your current connection. Save the public contact page and order details so you can explain the issue later.
For privacy, read what account and operational information the service collects, why it collects it, and what it says about retention and deletion. “No logs” is a policy claim that needs to be assessed in context; it doesn't mean all network activity is impossible to observe. VPNCar uses “quantum encryption” as a security claim. Assess privacy based on the specific policy, client configuration, and how you use the service—not just the label.
VPNCar doesn't require an email address. Create an account with a username and password. Providing less account information can reduce what you need to share, but you'll need to keep your credentials safe. When contacting support about an issue, share only the error details they need. Redact account identifiers, subscription links, and other access credentials from screenshots.
Hands-on checks: from importing a subscription to using your apps
After paying, test the tasks you actually use instead of repeatedly switching servers and watching status colors. Subscription links usually contain access credentials: get yours from the account dashboard and import it into a compatible client. Unlike a public tutorial URL, it shouldn't be posted in group chats or pasted into third-party online converters. Client support for protocols, subscription formats, and routing features varies by platform; being able to import a link doesn't mean the resulting configurations are equivalent.
- Check your client and configuration. Get instructions from the provider's official support page and confirm that your client supports the protocols and format in the subscription. If importing fails, first check compatibility and the link status; don't assume every route is down.
- Confirm that traffic is being proxied. Start by testing common tasks in rule mode. If an app doesn't use the system proxy, check its own proxy settings or consult the client documentation to see whether a virtual network adapter is needed. Global mode doesn't necessarily capture traffic that the client doesn't handle.
- Check the exit and DNS paths. After connecting, check the reported exit location and whether DNS requests are handled as expected. A different DNS resolver location doesn't by itself mean there's a leak; the key question is whether queries bypass the intended proxy route. Encrypted DNS in your browser can also change how lookups are handled.
- Repeat real-world tasks. Test work apps, video, or AI tools at the times you normally use them. Distinguish connection failures from location mismatches or account-permission issues. Change one variable at a time where possible, and keep the results for comparison.
- Report reproducible issues. Include your operating system, client, route name, time of the issue, and error message. Ask for an alternative route or configuration advice; don't send your password or full subscription details.
On Windows and macOS, which apps use the system proxy depends on how each app is implemented. Mobile platforms more often route traffic through operating-system network extensions. If the same account behaves differently across devices, compare client features, modes, and DNS settings before comparing server names.
Bottom line: follow the evidence and limit prepayment
A reliable choice is backed by verifiable terms and repeatable results. Clear refund terms, route descriptions that broadly match what you observe, and useful responses to problems are good reasons to keep using a service. Server counts, dedicated-route labels, a single speed test, and low prices can't replace that evidence on their own.
If you can't find the terms, the payment doesn't match an order, location claims remain contradictory, or support only asks you to wait without suggesting any checks, don't pay more in advance. If only one app is misbehaving, first check routing rules, DNS, and the destination service's restrictions; don't mistake a configuration problem for a business problem.
Choose based on what you need: test your usual tasks at a cost you can accept, keep relevant records, and decide whether to continue based on your experience. No pre-purchase checklist can predict every change in a provider's business, but it can shift your decision from trusting claims to checking evidence.