Cross-Border Network Troubleshooting Guide

Troubleshooting basics: first work out which layer is failing

The goal isn't to change every setting — it's to pin the problem down to one segment with as few moves as possible. A cross-border request passes through at least four segments: your device to the local network, the local network to the route entry point, the entry point to the destination site, and the site's response back. Any one of them failing can look like 'it won't load', but the fix is completely different each time.

First, separate 'can't connect' from 'connected but slow'. The first is a failed tunnel setup; the second is a working tunnel that isn't good enough. The two diagnostic paths don't overlap, and changing settings for both at once only makes things messier. Also separate two timelines: a failure on first setup usually points to the configuration method or platform compatibility, while something that worked and then suddenly stopped usually points to a change in your network, route scheduling, or account status. Different timeline, different place to look first.

The four-layer model: map the symptom to a segment

The point of this table is to help you decide where to start within thirty seconds. If your symptom falls in the 'local network' row, disconnect the client first and confirm the local network itself works — when the local network is down, no proxy setting can take effect, and tweaking the client is just wasted time.

The three-step isolation method

Work through the three steps below, changing one variable at a time. Only then do the results mean anything; change three things at once and even a fix won't tell you which one did it.

1. Switch routes

   Switch to another route in the client, preferring an IEPL dedicated line. If the connection recovers, the problem is on the original route: note its name, region, and the time window when it failed, and include that in any ticket. If it still fails, move on to step two.

2. Switch devices

   Connect the same route with the same account on another device. If the second device works, the problem is in the original device's client or system settings — go back to the chapter for that platform. If both fail, move on to step three.

3. Switch networks

   Replace your current Wi-Fi or broadband with a mobile hotspot and connect again. If it works over the hotspot, the problem lies in the original network's uplink, router, or ISP — nothing to do with your account or the route.

If all three steps fail, it's almost certainly not a single-point fault — go straight to the ticket process in chapter nine instead of retrying inside the client. Repeated reinstalls and route switching only wreck working settings and make later diagnosis harder.

Record five things before you start

Notes aren't bureaucracy. Route scheduling is dynamic, and the same problem can behave differently at different times; only records reveal a pattern. Without them you're describing from memory, and every conversation costs far more.

• When the problem happened, to the minute, with your time zone.
• The route name and region you were using, and whether you tried other routes.
• The platform and OS version running the client (Windows / macOS / iOS / Android / Linux).
• The exact error text or a screenshot — not just 'it won't load'.
• What you've already tried, for example 'three routes, two devices, two networks'.

When to contact support

In these cases, open a ticket right away instead of continuing to self-check:

• The same account can't connect on two or more routes, two or more devices, and two different networks.
• One route has been failing for more than a day while others work.
• Account-level problems: you can't sign in, the subscription won't load, or an order or payment status doesn't match what you expected.
• The client itself crashes, keeps quitting, or won't finish installing.

Conversely, self-check first in these cases: only one device is affected, only one site won't load, things slow down only at certain hours, or switching one route fixes it. These are single-point symptoms, and checking yourself is usually faster than waiting for a reply.

No connection at all: from the local network to account status

'Can't connect at all' means the client stays on 'Connecting' after you hit the button, or reports a connection failure outright, and no site will open. This chapter works from near to far: device → system → local network → route → account. Don't skip around; jumping ahead introduces several variables at once, until you can't even say what things looked like before.

First, understand the client's three states

'Connected' in the client only means the local tunnel is up — not that the exit works. The real confirmation is that your exit IP has changed. So the first step isn't the button colour; it's opening the IP check page and confirming the exit IP's location matches the region of the route you picked. If it doesn't match, your traffic isn't actually going out, and none of the later 'won't load' conclusions hold.

Clients on all five platforms keep a runtime log (called a 'connection log' on some). The last line usually shows where it stalls: stuck at the handshake usually means the local network is blocking the port or the system clock is off; stuck at authentication usually means an account or subscription problem; repeated reconnects at short intervals usually mean an unstable local network or a network adapter in power-saving mode.

Clock drift is the most easily overlooked cause

Connecting depends on a TLS handshake, and TLS requires the device clock to be within a few minutes of standard time. When the clock is off, the client just sits on 'Connecting' or reports a certificate error — and people usually blame the route, switching again and again while nothing changes.

• Windows: Settings → Time & language → Date & time, and turn on 'Set time automatically'.
• macOS: System Settings → General → Date & Time, and turn on automatic setting.
• iOS: Settings → General → Date & Time, and turn on 'Set Automatically'.
• Android: Settings → System → Date & time, and turn on automatic setting (menu paths vary slightly by manufacturer).

Restart the client and try again. On a device that's been offline for a long time, the clock can drift by tens of minutes — in that case, calibrate the time before looking at anything else.

Local network and security software

• A third-party firewall or security suite may block the tunnel with its network protection or traffic monitoring — turn it off temporarily and try again.
• Check whether the system proxy settings still hold an old proxy address (Windows: Settings → Network & Internet → Proxy).
• Access controls, parental controls, or ad filtering on the router may treat the route entry point as a suspicious target and block it.
• Corporate or campus networks may only allow common ports; switching protocol or port usually restores the connection.

Switching routes and protocols

Try an IEPL dedicated line first. If every route fails, switch protocols: move between Trojan, VLESS, Hysteria2, and Shadowsocks, one change at a time. A given protocol being blocked on a particular network is common, and switching often fixes it immediately — no new purchase or subscription re-import needed.

Checking your account status

• Whether the plan is still active and whether the data allowance is used up (data resets monthly on your activation date).
• Whether the subscription URL has been shared with others, so sessions keep knocking each other offline.
• Whether repeated sign-ins from several locations in a short time tripped an anomaly check.

Signing up needs no email address — a username and password are enough — so all account actions happen inside the user panel. If you forget your password, use the recovery flow in the panel; nothing else is required.

Symptom reference table

Connected but pages won't load

What these problems share: the client says connected, but pages spin forever in the browser or report 'This site can't be reached'. Don't touch the route yet — work through the order below to confirm whether traffic is actually going through the proxy. Most 'connected but won't load' cases are solved in the first two steps.

'Connected' doesn't mean 'proxied'

Clients work in one of two ways. System proxy mode only rewrites the system proxy settings: the browser and apps that respect those settings go through the proxy, and everything else is unaffected. TUN (virtual adapter) mode takes over all traffic, including apps that ignore the system proxy. If the client is in system proxy mode and the browser has an extension that takes over proxy settings, the system settings get overridden — the client says connected while the browser still won't load anything.

The check is simple: open this service's IP check page and see whether the exit IP's location matches the region of the route you chose. If not, traffic isn't going through the proxy — the problem is the client mode or a browser extension. If it matches, the proxy is working; keep reading.

Narrow it down to one layer from the command line

Browser error messages tend to be vague; the command line narrows things down directly. The three commands below answer three questions: is the destination reachable, does the domain resolve, and is the result consistent.

# 1. Is the destination reachable (example domain — replace it with the site you actually need)
curl -I --max-time 10 https://www.example.com

# 2. DNS lookup only — see whether the domain resolves to an address
nslookup www.example.com

# 3. Resolve again with a specific DNS server and compare the two results
nslookup www.example.com 1.1.1.1

If curl returns 200 or 301, the path itself works and the problem is in the browser. If curl times out but nslookup returns a result, the problem is at the exit or the destination. If nslookup itself fails, jump straight to the DNS checks in chapter eight. Run all three tests on the same network, or the results aren't comparable.

Check by scenario

• No site loads: check DNS and whether the tunnel is active first, then the route, then your account status.
• Only some sites fail: check whether those domains are listed as direct in your routing rules, or whether the sites themselves are down for maintenance.
• Only the browser fails while other apps work: check browser extensions and the browser's built-in encrypted DNS setting.
• Only one device fails: compare with another device to confirm it's a device-side issue, not an account issue.

The 'half-working' problem caused by IPv6

Some broadband connections hand out both IPv4 and IPv6 addresses, and the system prefers IPv6. If the route only handles IPv4, you get the seemingly random pattern where some sites open and others spin forever. There are two fixes: turn on TUN mode in the client so all traffic enters the tunnel, or temporarily disable IPv6 in the system network settings and test again to compare.

Problems on the destination's side

Don't overlook a fault at the destination itself. Try the same site over another route, another device, and another network. If all three fail while other sites are fine, the problem is almost certainly on the site's side, not with this service — just wait for it to recover.

Browser extensions and security software

Ad blockers, script managers, and proxy-switching extensions all change where requests go. Disable them all while troubleshooting, confirm things work, then re-enable them one by one to find the culprit. This takes only a few minutes and rules out a good share of problems that look complicated.

Subscription update failures: URL, cache, and status checks

The subscription is how the client gets its route list. When an update fails, the client usually keeps the nodes from the last successful fetch, so you may see 'it connects, but the node list is stale' — or a straight-up subscription update failure. Work out which one you have before deciding what to do: the first often doesn't affect use, the second needs immediate attention.

Confirm three things first

• The device can get online right now. Updating a subscription needs a working network request; hitting update while offline will always error out.
• The system clock is set automatically. Clock drift makes the request fail at the TLS stage, while the error message usually blames the network.
• The plan is active and the data allowance isn't used up (data resets monthly on your activation date).

Only move on once all three check out. They cover the most common causes of subscription update failures, and ruling them out saves a lot of time.

What a subscription URL looks like

A subscription URL is a link that carries credentials; the client uses it to pull the route list. The example below only shows the format — copy your real URL from the Overview page after signing in to the user panel.

# Subscription URL example: format only, not a working address
https://example.com/sub?token=YOUR_TOKEN

# Some clients can return different formats by type (example)
https://example.com/sub?token=YOUR_TOKEN&flag=clash

The subscription URL is tied to your account and carries access credentials — treat it like a password. Don't post it in group chats, don't send screenshots of it, and don't paste it into public config files or code repositories. To use it on several devices, just import the same URL on each one; no extra request is needed, and there's no device limit.

Two ways to import

Importing by link is the first choice. Adding nodes manually is the fallback: enter the server address, port, protocol, and credentials one by one in the client. Manually added nodes don't change with later updates, so if a manual route stops connecting, switch back to link import to check whether the route itself was changed.

Common causes of update failures

How often to update, and when

Once a week is a good default. When you switch routes or regions, or speeds feel slower, update manually first before touching the protocol. After an update the node list is regrouped by region; if the number of nodes in a region changes, the server is usually adjusting routes — just update again a little later.

Slow speeds and peak-hour lag

'Slow' is a result, not a cause. Measure where the bottleneck is before deciding what to change. This chapter runs in the order: test locally, then test the exit, then adjust the route. Do it backwards and you'll easily mistake a local bandwidth problem for a route problem, cycling through routes with no improvement.

Measure your local bandwidth first

Disconnect the client and run a speed test on your local broadband, noting the result; then connect the client and test again. The gap between the two is what the proxy path costs you. If your local broadband is already slow, no route will make it faster — call your ISP instead.

Two things to watch when testing: use the same speed test service both times so the results compare, and shut down background downloads, cloud sync, and system updates — they saturate the link and badly distort the numbers. Results also depend on server load, so a single run proves little; run three in a row and take the middle value.

How route types differ

All three route types are part of the 110+ countries / 250+ routes coverage, and you can filter by region and type right in the client. Prefer IEPL dedicated lines at peak hours because the dedicated channel avoids the public internet's international gateways and is less affected by overall congestion; direct routes are the shortest path but are exactly the ones that get dragged down by congestion at peak times.

Protocols and overhead

The protocol determines encapsulation and overhead. Hysteria2 is built on QUIC and holds up better on lossy networks, which suits routes whose quality fluctuates; Trojan and VLESS use TLS, are widely compatible, and fit most everyday use; Shadowsocks has low overhead and performs better on older devices. You can switch protocols at any time — just reconnect afterwards, no need to re-import the subscription.

Bottlenecks on the device side

• Wi-Fi band: 2.4GHz reaches further but has a lower speed ceiling; at close range, prefer 5GHz.
• Encryption performance on old devices: older processors pay more for encryption and decryption, which shows up as pages loading but video stuttering.
• Background tasks: system updates, cloud sync, and game launcher downloads all keep eating bandwidth.
• Router performance: with many devices at once, an entry-level router's forwarding capacity can hit its limit before your broadband does.

What to try at peak hours, in order

Work through the order below, changing one thing at a time and retesting right after each change.

1. Switch to an IEPL dedicated line

   Prefer a region close to the destination. When a region has several dedicated lines, try them one by one and note which holds up best at peak hours.

2. Switch protocols

   Move between Trojan, VLESS, Hysteria2, and Shadowsocks; when packet loss is obvious, QUIC-based protocols usually help the most.

3. Check routing rules

   Route local sites directly to cut wasted tunnel traffic, and make sure no rule mistakenly sends the destination site direct.

4. Confirm it isn't a local problem

   Test again on another device and another network. If only the original device is slow, the problem is the device or the local network, not the route.

By time of day

If things only slow down at certain hours and improve clearly after switching routes, it's almost certainly congestion at the international gateway, not your account or device. For latency-sensitive cases like live sports, see Best VPN for Live Sports for route-picking tips.

Frequent drops and mobile background disconnects

There are two kinds of disconnection: a real one, where the client drops back to disconnected, and a 'phantom' one, where the client still says connected but traffic has stopped. The two need completely different checks — tell them apart first, or you'll spend hours looking in the wrong place.

Tell real drops from phantom drops

• Real drop: the client returns to disconnected and the log shows the disconnect. Look at the local network, adapter power saving, and link quality.
• Phantom drop: the status still says connected, but pages won't load. Look at keep-alive behaviour, DNS, and the client process being killed by the system.

How to tell: open the IP check page the moment it happens. If it loads, the tunnel is still up and the problem is at the application layer; if it doesn't, the tunnel really is down. This takes seconds and decides which way you investigate next.

Desktop: adapter power saving and power plans

• Windows: Device Manager → Network adapters → Properties → Power Management, and clear 'Allow the computer to turn off this device to save power'.
• Windows: Control Panel → Power Options, and switch the plan to High performance so the CPU and adapter stop throttling constantly.
• macOS: System Settings → Battery, and turn off Low Power Mode, or stay plugged in while you work.

These three are the most common sources of desktop disconnects. A wireless adapter that goes into power saving when idle takes time to wake up, which shows up as a stall every so often or a straight disconnect.

Mobile: the app gets killed in the background

Both iOS and Android kill background processes when memory is tight or battery saver is on. When the proxy process is killed, you switch to another app, come back a while later, and the connection is gone with no warning at all.

• iOS: Settings → General → Background App Refresh, and allow the client to refresh; also turn off Low Power Mode.
• Android: Settings → Apps → the client → Battery, and choose Unrestricted or add it to the battery-saver allowlist.
• Android: lock the client in the recent-apps list so a one-tap clean-up can't close it.
• Turn off the restrictions that built-in smart power saving or deep sleep features place on the client.

Reconnecting when the network changes

Moving from Wi-Fi to mobile data, or roaming between Wi-Fi networks, means the tunnel has to be rebuilt. Some systems take ten seconds or more to recover, which is normal; if it never recovers, disconnect and reconnect manually — no need to restart the device. If you switch back and forth often, wait until the connection settles before starting long tasks.

Routers and modems

A router that's been on for weeks can fill its session table or run high on memory, which shows up as the whole network stuttering — not just the proxy dropping. Power-cycle the modem and router once and watch for a day; if drops clearly become less frequent, the local network hardware is the problem.

Band steering and roaming

Some routers merge 2.4GHz and 5GHz under one name, and the connection briefly drops as devices hop between bands. With several routers at home, poor roaming settings cause the same thing. Try splitting the two bands into separate names, connect to just one, and see whether the drops decrease.

Logging the pattern beats reinstalling

Note the interval between drops, how long they last, and which route and network type you were on. Drops at a fixed interval usually come from keep-alive or power-saving settings; irregular drops are more likely link quality or a local network issue. Android power-saving policies vary a lot, so for the full flow from install to allowlisting, see Android VPN Setup from Scratch.

One app won't use the proxy

When the browser works but a desktop app, game, or command-line tool can't connect, it's usually not the route — that app simply isn't going through the proxy. The causes come down to three things: proxy mode, routing rules, and the app's own network behaviour. Check them in that order and you'll almost always find it.

Proxy mode decides what gets captured

How routing rules are matched

Routing rules match by domain, IP, and app name in order, and the first match wins. If the destination domain is listed as direct, or an earlier rule catches it first, that app won't go through the proxy — even if it appears in the client's app list.

How to check: open the client's connection log, use the problem app once, and see whether a matching connection appears. No entry means the traffic never reached the client; an entry marked direct means a rule let it through; an entry that went through the proxy means the problem is in the app itself or at the destination.

Common misconfigurations

• A manual 'direct' entry was added to the rule list and never removed.
• Only some processes are proxied, and the app isn't on the list.
• The app uses its own network stack; some download tools and game launchers ignore the system proxy.
• The app prefers IPv6 while the route only handles IPv4.

Games and UDP apps

Games lean heavily on UDP, while the system proxy usually handles only TCP, so 'the browser works but the game won't connect' is a classic pattern. These apps need TUN mode enabled in the client, with UDP forwarding supported; if latency actually rises after enabling it, switch to a node in a lower-latency region.

AI Tools

AI Tools such as ChatGPT, Claude, and Gemini are more sensitive to link stability: most use long-lived connections, and a break means the session has to be rebuilt, which shows up as endless spinning after sign-in or an answer cut off halfway. When that happens, switch to an IEPL dedicated line first, then confirm the app is inside the proxy scope. More detail is collected on the ChatGPT acceleration page.

Confirm it's working

The most direct check: in the problem app, open an address that only loads through the proxy, or use the app's own network diagnostics to see the exit address. You can also confirm the current exit on this service's IP check page. The trade-offs between global proxy and rule-based routing on desktop, plus how to set up launch at startup, are covered in Best VPN for Windows.

DNS errors and checking your exit IP

DNS translates domain names into IP addresses. When DNS misbehaves, the symptoms are misleading: pages won't load while chat apps work fine, or some domains resolve on a device while others don't. Work out which case you have before changing anything.

Tell the three problem types apart

Each type needs a different fix: resolution failure usually means the local DNS service is unavailable; bad resolution usually means interference along the lookup path; a DNS leak is a configuration problem, and the lookups need to be pulled back inside the tunnel.

Three self-checks on the IP check page

• Does the exit IP's location match the region of the route you chose?
• Is there a DNS leak warning?
• Check once before and once after disconnecting the client, and compare.

The check lives on the My IP page — no extra tools to install and no command-line experience needed.

DNS settings in the client

Prefer the DNS resolution that comes with the route, so lookups travel out through the tunnel. If you manually point DNS at a public address, lookups may leave the tunnel and go back to your local ISP, which both affects the results and exposes your lookup history outside the tunnel. Unless you have a clear reason, don't hand-edit the DNS config the client delivers.

The browser's built-in encrypted DNS

Some browsers ship with encrypted DNS (DoH), which overrides the system and client DNS settings when enabled. If resolution problems appear only in the browser, turn this option off or set it to follow the system, then test again. It's often overlooked, yet it explains cases where every other app works and only the browser won't load pages.

Command-line checks

# Resolve with the system's default DNS
nslookup www.example.com

# Resolve with a specific DNS server and compare the two results
nslookup www.example.com 1.1.1.1

# Windows: flush the local DNS cache
ipconfig /flushdns

# macOS: flush the local DNS cache
sudo dscacheutil -flushcache

If the two lookups disagree, something is interfering along the resolution path. Flush the cache, restore the client's DNS settings to their defaults, and reconnect. The first lookup after a flush is usually a little slower, which is normal.

DNS is fine but pages still won't load

If resolution is fine and the exit IP is correct but pages still won't load, DNS isn't the problem. Go back to the scenario checks in chapter three, focusing on routing rules and browser extensions.

Device limits, account sharing, and opening tickets

This chapter covers account-level problems and what to do once you've worked through the previous eight. Account issues have a signature: no local change makes them better, and only checking from the account side will pin them down.

What unlimited devices means

VPNPF plans don't limit the number of devices: one account can be online at the same time on Windows, macOS, iOS, Android, and Linux. You don't buy per device, and you don't have to count how many you're using. When you get a new device, just import the subscription on it.

Many services charge by device count and prompt you to upgrade once you exceed it. This service's plans have no such limit, so moving between your own devices is never a problem. If you get signed out after signing in, it's more likely account sharing than a device limit.

What account sharing causes

The subscription URL is tied to your account and works as its credential. Sharing that URL is handing your account to someone else. Several people on one account causes three things: connections get used up at the same time so it's slower for you; sessions knock each other offline and you're asked to sign in again and again; and when unusual sign-in records appear, there's no way to tell where they came from.

If family members or colleagues need access, create separate accounts rather than sharing one subscription URL. Signing up needs no email address — a username and password are enough — so giving someone their own account costs very little.

These cases need a ticket

• You can't sign in and the recovery flow doesn't work either.
• The subscription won't load, and it still fails on another device and another network.
• An order or payment status doesn't match reality.
• You need a refund (60-day money-back guarantee).
• You've worked through the first eight chapters and the problem is still there.

What to include in a ticket

Complete details usually solve it in one round; missing details cost half a day in back-and-forth. Put together the list below and paste it straight into the ticket.

1. Account details

   The username you signed up with. Don't provide your password — tickets never need it, and no one will ask you for it.

2. When the problem happened

   To the minute, with your time zone. The timestamp helps tell a route change from local network fluctuation.

3. Route name and region

   The route name and region in use when it happened, whether you tried other routes, and what happened when you did.

4. Client and system

   The platform (Windows / macOS / iOS / Android / Linux) and OS version, plus the client version.

5. Exact error text or a screenshot

   Copy the client's error text directly, or attach a screenshot that shows the full message — don't just say 'it won't load'.

6. What you've already tried

   For example, 'three routes, two devices, two networks — same result'. This alone saves a round of back-and-forth.

After you submit

The ticket form is inside the user panel — sign in to submit one and track progress. Before submitting, search this guide for your symptom; most problems can be solved during self-check. Payment methods include Alipay, WeChat, and USDT; for order questions, just include the payment time and amount in the ticket — no sensitive information beyond a payment receipt screenshot is needed.