Cross-Border Connection Troubleshooting Handbook

Order of checks: three tests before any settings

Connection failures look like a tangle, but they really sit in three layers: account and subscription, client and device, route and network. A problem in any one layer can produce the same symptoms — spinning, timeouts, pages that won't open. So this manual locates the layer first and changes settings second: change one variable at a time and retest immediately. Change three things at once and even a fix tells you nothing; the next relapse starts from zero.

Check one: is the account and subscription valid? Log in to the user panel and confirm the plan is still within its term and this month's traffic is not used up. Traffic resets monthly on the activation date and does not top itself up when it runs out; the symptom is that every route fails to connect, or connects but passes no traffic. This step is panel-only — don't touch the client.

Check two: is the fault global or isolated? Try another device, another network (a hotspot from a second device, for example) and another destination site. If any one of the three works, the account and the route pool are fine and the problem is local. Only when all three fail is it worth suspecting the route.

Check three: is it the client or the route? Repeated failures on one route that clear up on another point to the route; failures on every route point to the client or the local network. This check decides whether you go to chapter 2 or chapter 3.

Once those three are done you usually know which chapter to jump to. The table below maps common symptoms to chapters — find your symptom first, then work through the chapter step by step.

Before you start, have three things to hand: the device that fails, the time it failed, and the matching lines from the client log. The most valuable thing in a ticket is not the words “won't connect” but “at this time, on this route, the error said exactly this”. Chapter 10 explains how to pull the logs.

Keep the retest method fixed too: same destination, same time window, same command. Opening three sites in three different regions right after a change tells you more than clicking Connect over and over. And if the first attempt after a change works, don't call it done — retest ten minutes later. Intermittent faults are easily hidden by the first success.

Won't connect at all: from subscription to local port, layer by layer

Start by splitting “won't connect” into three behaviors: it spins forever after you hit Connect, it fails within seconds, or it shows connected while the traffic counter stays at zero. The first usually stalls in the handshake, the second is usually local configuration or a port, and the third generally means the tunnel is up but no traffic passes. Each has a different starting point; mixing them together only makes the diagnosis messier.

The six steps below run from the account down to the local machine, and each one can reach a conclusion on its own. Stop at the step where it starts working — there's no need to continue.

1. Confirm the subscription is valid and this month's traffic isn't used up

   Log in to the user panel and check the plan's expiry date and this month's remaining traffic. Monthly plan traffic resets each month on the activation date and does not renew itself when used up; traffic packs last until they run out and never expire, and are counted separately from monthly plan traffic. This step is panel-only — don't change the client.

2. Try another route

   Switch city within the same region (Tokyo to Seoul), or switch route type (IEPL to relay). Three routes in different regions all failing effectively rules out a single bad route; if only one fails, that route is the problem — just replace it.

3. Try another network

   Use a second device as a hotspot for the computer, or switch to mobile data. Office, campus and hotel networks often restrict ports and protocols; if a different network works, the policy is local and the account is fine. This one step saves a lot of pointless client tinkering.

4. Check the system clock

   Set the system clock to sync automatically. A drift of more than a few minutes makes the TLS handshake fail, and the client usually reports only “connection failed” with no real cause. After syncing, restart the client and try again.

5. Quit other proxy software

   Two clients running at once fight over the same local port, and the one started second often fails silently. Check the tray and the task manager, and quit every proxy, accelerator and packet capture tool you aren't using — keep one.

6. Check the firewall and security software

   An inbound rule that was blocked on first run does not restore itself. Find the client in the system firewall and make sure both inbound and outbound are allowed; third-party security suites' “network protection” can also block the tunnel, so disable it temporarily and retest.

A few causes that are easy to miss

Local port conflict. The client's default local port may already be taken by another program. The interface looks fine and the Connect button works, but nothing is listening on the port the system proxy points at. Change the port or quit whatever is holding it.

Networks that restrict UDP. Some networks throttle or outright drop UDP. Switch the client to TCP, or try another transport; if it connects, that was the cause.

Loopback proxying. If the routing rules send the subscription domain and the panel domain through the proxy while the proxy isn't connected yet, updating the subscription and establishing the connection wait on each other and it looks like nothing will ever connect. Set both domains to direct and reconnect.

Router-side blocking. Parental controls, internet time limits and DNS filtering all block at the router. Comparing against mobile data confirms it in one test.

When to stop and open a ticket

Three routes in different regions and of different types all fail, the same failure happens on two different networks, the system clock is synced and other proxy software is closed — when all three hold, it is almost certainly not a local problem. At that point a ticket with the client log and the time of failure is more efficient than more attempts. Chapter 10 lists what to attach.

Connects but pages won't load: first separate all from some

The client says connected and traffic is moving, but the browser won't open a page. The first move is not to change settings but to separate two cases: nothing loads at all, or only some sites don't load. That distinction decides ninety percent of what follows.

Nothing loads

When nothing loads, DNS usually isn't going through the tunnel, or packets are being dropped along the path. Work through the three checks below in order.

Is DNS resolving inside the tunnel? In the client, confirm that an option such as “resolve DNS through the tunnel” is on, and that the system DNS has not been pinned to a fixed local address. Chapter 9 explains how to tell.

Does the MTU match? Tunnel encapsulation eats into packet length. With the local MTU still at 1500, large packets get dropped — the classic sign is a home page that loads while images and video never do, and pages that stall halfway. Test once with a ping that forbids fragmentation:

# Windows
ping -f -l 1472 example.com

# Linux / macOS
ping -M do -s 1472 example.com

1472 plus the 28-byte header comes to exactly 1500. If it goes through, the MTU is fine; if you're told the packet needs fragmenting, or it simply times out, step the value down towards 1400 and try again, then set the client MTU somewhere between 1400 and 1450. That range is the usual value for tunnel problems — there's no need to hunt for an exact number.

Do the routing rules treat the browser as direct? Run once in global mode; if pages load, the rules are the problem, so go back to rule mode and add the missing entries one at a time.

Some sites won't load

When only certain sites fail, the problem usually sits with the destination, not the tunnel.

Regional restrictions. Sites serve by exit region, so use a route in the matching region. Chapter 4 maps common regions to use cases.

Exit IP triggers verification. When many people share one exit, a site may demand extra verification or simply refuse. Switching to another route in the same region usually gets through.

Local cache. Browsers and apps cache old resolution results or old connections. Flush the DNS cache once (commands in chapter 9) and reload.

Streaming and account region. Streaming services look at the account's registered region as well as the exit region. Change the exit but not the account region and you still see only part of the catalogue. No route change fixes that — the account side has to match.

Which routing mode to choose

When troubleshooting, run once in global mode first. If global works and rule mode doesn't, the routing rules are almost certainly the issue; if neither works, go back to the DNS and MTU checks. Once you've located it, return to rule mode and add the missing domains to the allowlist rather than leaving global on permanently — global mode pushes LAN access, local devices and local dev services through the tunnel too, and that costs you.

Slow speeds and peak-hour lag: tell the three kinds of slow apart

There are at least three kinds of slow: always slow, slow at particular times, and slow on particular sites. Their causes and fixes are completely different, and mixing them up wastes effort. Spend two minutes deciding which one you have before changing anything.

Always slow

Slow from the moment you connect, at any hour, usually starts locally. Check in order: the real speed of your own broadband; whether Wi-Fi is running on 2.4GHz (prefer 5GHz at close range); whether the router is old or has bandwidth limits enabled; whether system updates, cloud drive sync or cloud backup are running in the background.

Another common case is choosing an exit region that is simply too far away. Physical distance sets the floor: reaching a European exit from Asia adds distance no route can remove. Picking a nearby region is the single most direct improvement you can feel.

Slow at certain times

Fine during the day and slower in the evening is a shared property of international bandwidth, not a fault of one provider. The evening fix isn't reconnecting over and over — it's changing route type.

Route type is visible in the client's route list; every route is labelled with its type. In the evening, switching your usual route from direct to an IEPL dedicated line in the same region is usually more effective than changing region.

Slow on one site only

When only one site is slow, suspect the site first: does it throttle shared exits, throttle single connections, or has its CDN scheduled you to a distant node? The test is simple — open another site of the same kind on the same route; if the speed is normal, the tunnel isn't the problem.

Browser extensions slow things down too: ad blockers, script managers and translation add-ons amplify waiting time on cross-border access. Compare once in a private window, which loads no extensions by default.

How to measure so the numbers mean something

Don't look at the peak number in a speed test — look at how long a real task takes: how long the same episode takes from click to playback, how long the same file takes from start to finish. Fix three things while measuring: same destination, same time window, same action. Run route A and route B three times each and take the median; only then are the two results comparable.

The route table on this site does not list latency figures, and no live speed test runs on the page. Latency changes with the local network, the time of day and the destination, so a fixed number would mean nothing; real-world feel can only be measured on your own connection.

Choosing an exit region by use case

For fuller route-selection rules see the beginner's guide to choosing a route; for all regions and route distribution see the servers page.

When to consider a different plan

Slow and “out of traffic” are two different things: running out usually means no connection at all, not a slower one. If you've confirmed you simply need more traffic, the monthly plans come in three tiers: ¥9.9 per month with 60GB, ¥18 per month with 250GB and ¥28 per month with 500GB, reset monthly on the activation date, with mid-term upgrades charged pro rata for the remaining days. If your usage swings a lot, you can also stack traffic packs: ¥158/300GB, ¥358/1000GB and ¥658/3000GB, valid until used up and never expiring. Full comparison on the plans page.

Frequent drops: work back from the timing pattern

Drops are easily blamed on an unstable route. Before changing routes, look at the pattern: fixed intervals, random, or when switching networks. Three patterns, three completely different causes — get the pattern right and the cause usually names itself.

Drops at fixed intervals

A drop every five minutes or every half hour, at almost identical times. This is usually not the route dying but the session being reclaimed.

Keepalive and timeouts. A client with no traffic for a while will disconnect and reconnect on its own. Drops while idle and normal behavior as soon as traffic flows point to this. Turn on options such as “keep connection alive” or “periodic keepalive” in the client.

Session timeout. Routers and carriers reclaim sessions that sit idle too long. The symptom matches the keepalive problem; the fix is to raise the router's session timeout, or have the client send probe packets periodically.

Random drops

No fixed timing; the connection either recovers by itself or needs a manual reconnect. Three common causes: Wi-Fi roaming (the tunnel rebuilds as the device moves between access points), weak signal, and battery policy (see chapter 8).

Order of handling: pin the device to one Wi-Fi band and one access point as a control; turn off the system's “Wi-Fi assistant” or “auto-switch network”; note where you were and what you did when it dropped. Drops while moving that recover when you sit down are almost certainly roaming.

Drops when switching networks

Dropping when you move from Wi-Fi to mobile data, or from one SIM to another, is normal — the tunnel has to be rebuilt. What matters is whether it reconnects automatically: find a switch such as “reconnect on network change” in the client and turn it on. Some systems revoke connection authorization after a network change and need it confirmed again.

What is worth writing down

Three drops are enough to show a pattern, provided you record the right things. Note four: the time (to the minute), how long it lasted, what you were doing (idle or transferring), and whether the network changed. Add the matching lines from the client log, and those four plus the log are enough to place it in one of the categories above.

Four switches on the client side

Most drop problems are solved by four switches: connect on startup (so a reboot doesn't leave you disconnected), auto-reconnect on drop (so you don't intervene by hand), keepalive and heartbeat (against session reclamation), and connect only when in use (saves battery on mobile but sacrifices background continuity). Trade them off against your use case: on desktop, turn the first three on; on mobile, decide the fourth by whether you need a persistent background connection.

When it is an upstream problem

If the same route drops at similar times on different devices and different networks, and a different route fixes it, then it's upstream. At that point, switching routes and putting the timestamps in a ticket is more useful than reconnecting repeatedly.

Subscription update fails: from link integrity to the fetch network

A subscription update is really the client sending one request to the subscription URL and getting back a block of configuration text. Failures have only four causes: the link is wrong, the request can't get out, an interstitial page takes over the request, or the client fails to save. Work through them in order and you'll have an answer within four steps.

1. Copy the full link again

   Copy it from the user panel — don't retype it, and don't use text that has been passed through a chat app, which brings line breaks and spaces along with it. The link carries parameters; one missing character and no configuration comes back.

2. Open it once in a browser

   A healthy response is a block of plain text or a downloaded file. If you get a login page, an error page or a blank screen, the link has expired or an interstitial page has taken over the request. This is the single most useful step in the chapter.

3. Connect first, then update

   The subscription URL itself may only be reachable through the tunnel. Connect with a working route first, then hit update. Doing it the other way round traps you in “can't update because I'm not connected, can't connect because I can't update”.

4. Delete the old subscription and add it again

   More reliable than pressing update repeatedly. After a failed update, some clients keep the old configuration and look as if the update succeeded while the nodes never change.

If you prefer the command line, one command verifies whether the link works:

curl -sS -m 15 "https://example.com/sub?token=YOUR_TOKEN" | head -n 5

The example address is a dummy value, only there to show the shape of the command — copy the real link from the panel. A block of text back means the link works and the content is right; a block of HTML means an interstitial page took over the request; a plain timeout means the request can't get out. Three results, three directions.

Update succeeds but nodes shrink or go empty

Fewer nodes. The route pool changes as operations are adjusted; the count goes up and down and that's normal. As long as your usual regions are still there, nothing needs doing.

Empty list. Usually you got an error page back and the client can't parse a single node out of it. Go back to step 2 and verify the link in a browser.

The browser can't open it either. The problem is on the account side — log in to the panel and check the plan status and remaining traffic.

One link across several devices

This site places no limit on simultaneous devices, so importing the same subscription link on several devices is allowed and you don't need a separate one per device. What you should avoid is resetting the subscription repeatedly across devices — on some clients a reset invalidates the old configuration and takes the other devices down with it. When you need a new configuration, import the new link first, confirm it works, then delete the old one.

Clock drift can also break updates

HTTPS requests validate certificate expiry. With a large clock drift the validation fails outright and the client reports only that the update failed, with no detail. Setting the system clock to sync automatically and restarting the client is the only fix for this one.

One app won't go through the proxy: first check whether it uses the system proxy

When the browser works and one app doesn't, the tunnel itself is fine — the problem is how that app sends requests. Apps behave in three ways: they follow the system proxy, they connect directly, or they use UDP. Decide which one you have, then choose how to capture it.

Three kinds of app

Follows the system proxy. Most browsers and some desktop apps are in this group. Turn the system proxy on and they follow.

Connects directly. Many game launchers, software updaters and command-line tools ignore the system proxy setting and can only be captured by taking over all traffic with a virtual network adapter (TUN) mode.

Uses UDP or QUIC. Some browsers and video apps default to QUIC. When the tunnel handles UDP poorly, the result is a hang rather than an error, which is easily misread as the app being unusable.

Platform differences

Order of handling

1. Switch to TUN mode

   This is the widest-reaching way to capture traffic and covers apps that ignore the system proxy. After switching, restart the target app and try again.

2. Turn off the app's QUIC and HTTP/3

   Browsers usually have a switch for it; once off, traffic returns to TCP, which the tunnel handles far more reliably.

3. Check whether the app uses its own DNS

   Some apps ship their own encrypted DNS and go around system settings. Turn off the app's “secure DNS” option so it follows the system.

4. Point command-line tools at the proxy manually

   Find the local port in the client interface and put it in the environment variables, or add the parameter to the command. Background services need separate configuration — they don't inherit the user's environment variables.

5. Check the per-app proxy list

   On platforms that support per-app proxying, such as Android, the target app must be ticked in the proxy list, otherwise it goes direct.

To see whether a command-line tool really goes through the tunnel, a command that prints only the status code is the quickest:

curl -sS -m 10 -o /dev/null -w "%{http_code}\n" https://example.com

A 200 means that command's traffic got through; 000 means it didn't. Run it once before and once after enabling the proxy and compare. The same method tells you whether a script or a build tool goes through the tunnel.

Cases that still don't work

The app hardcodes an IP or uses a private protocol. That traffic goes around the routing rules and can only be captured by TUN mode taking over everything.

The app has its own network permission. On mobile, some apps are restricted separately by the system; allow them in system settings.

The app's own regional restriction. Change the exit without changing the account region and the app still refuses service — nothing to do with the tunnel.

Development work with long-lived connections (completion requests, package managers, model APIs) demands more stability; see Network and route notes for AI coding tools for the details of route choice and routing rules.

Mobile background drops: battery policy is more often the cause than the route

The connection disappears a few minutes after the screen locks and has to be reconnected after unlocking. Nine times out of ten this isn't the route but the system's background management: to save power, mobile systems freeze background processes, reclaim network configurations and restrict background data. Fix the system settings for your platform first, then think about routes.

iOS

Low Power Mode. It restricts background refresh and network activity, and the tunnel is the first casualty. Turn it off and retest — this is the most commonly missed one.

Background App Refresh. With it off, an app can't maintain a connection in the background. Turn it on for this client specifically in system settings.

Connect on demand. With it on, the system brings the tunnel up whenever a network is needed, with no manual tap. This is the most hands-off switch on mobile.

Network switching. When the Wi-Fi signal is weak the system moves to mobile data, the tunnel rebuilds during the switch, and it looks like it drops every time you walk into a particular room. Pin the device to one network as a control and you'll confirm it.

Android

Battery optimization. The system puts rarely used apps into a restricted state and cuts their background network. Add the client to the battery optimization allowlist and permit background activity.

Autostart permission. Some customized systems block apps from starting automatically by default, so the connection doesn't come back after a reboot. Allow it for this app in app management.

Swiping it out of recents. Many systems end the app's tunnel along with it. If you need it running in the background, lock the app in the multitasking view.

General checklist

1. Turn off the system's battery optimization for the app

   This includes smart power saving, deep sleep and background limits — check each one.

2. Allow background data and background activity

   The system's data saver also cuts background connections and needs a separate exemption.

3. Pin the data SIM on dual-SIM devices

   Switching back and forth between two SIMs makes the tunnel rebuild repeatedly. Pin one as the data SIM; the signal is steadier.

4. Compare with another device

   If another device on the same network doesn't drop, the system policy on this device is the cause, not the route.

When it isn't a battery issue

If it drops frequently while unlocked too, go back to chapter 5 and look at the timing; if it only drops when changing Wi-Fi, that's roaming; if it only drops when a particular app comes to the foreground, that app is grabbing the network or rewriting DNS; if the connection icon stays up but background downloads stop, the system is restricting background data, not the tunnel failing.

Separating these four cases stops you from changing system settings over and over with no effect. Mobile battery policy changes with every release, so if a new drop pattern appears after a major OS update, come back to this chapter and work through the checklist again.

DNS problems: ping works but names won't resolve

DNS translates domain names into IP addresses. When it fails, it looks a lot like a dead connection: the browser says the server can't be found, yet pinging an IP directly works. The test is simple — ping an IP, then ping a domain, and compare the two results.

ping -c 4 1.1.1.1
nslookup example.com
nslookup example.com 8.8.8.8

First works and second fails: local DNS. Both work but the third fails: local DNS has been rewritten or has cached a wrong result. All three fail: there may be no network at all — go back to chapter 2. On Windows, replace ping -c 4 with ping -n 4.

Common symptoms at a glance

Clear the cache once

Clear the cache after changing settings, otherwise the old result stays in effect for a while. Commands by platform:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux(systemd-resolved)
sudo resolvectl flush-caches

On mobile there is no command line — toggling airplane mode once makes the system resolve again.

Why it leaks

Multiple network services. A system can have wired, Wi-Fi and virtual adapters active at once; the proxy changed only one of them and queries leave through another.

The browser's own encrypted DNS. A browser can specify its own encrypted resolver and bypass system settings entirely. Turn it off first when troubleshooting.

Routing rules treat DNS as direct. If the rules only match domain names and don't cover the queries themselves, resolution goes local.

Troubleshooting order in short

Confirm in-tunnel resolution is on, clear the cache, turn off encrypted DNS in the browser and the system, then check the routing rules. If resolution still fails after those four steps, attach the output of two nslookup runs to your ticket — far quicker than more guessing.

C6VPN's privacy policy is anonymous and log-free: browsing content and destinations are not recorded. Resolving DNS inside the tunnel is part of that policy, which is why troubleshooting prefers resolution through the tunnel over handing queries to the local ISP.

Multiple devices, concurrency and ticket timing

This chapter covers two things: how things behave when several devices are online at once, and when to stop troubleshooting and open a ticket.

What unlimited devices means

There is no limit on simultaneous devices: one account can be logged in on Windows, macOS, iOS, Android and Linux at the same time, with no separate purchase per device. The plans page says the same.

Unlimited devices doesn't mean dedicated bandwidth per device. Exit bandwidth is shared, so several devices streaming 4K or downloading large files at once compete with each other. The test is direct: turn the other devices off and measure again — if speed returns, it was concurrency, not a worse route.

Router-level proxying is another way to use it: import the subscription into the router and every device at home shares one exit. The upside is convenience; the cost is that all devices share one exit IP, so site risk controls hit them together and troubleshooting can't easily tell which device is at fault. Confirm the route works on a single machine before moving to the router.

About the “device limit reached” message

There is no device limit on the account side of this site. If a message like that appears in a client, check where it comes from: most often two clients are installed on the same machine and fighting over one local port, or a router plugin is limiting concurrent connections. Fix: quit the extra clients, check the router plugin's concurrency settings, then log in to the panel again and copy the subscription.

When to open a ticket

If two or more of the five points below apply, it's worth stopping and opening a ticket instead of trying more:

• Three routes in different regions and of different types all fail to connect
• The same failure on two different networks (home broadband and mobile data)
• The system clock is synced and all other proxy software is closed
• The subscription link opens in a browser but the client's update fails
• The same route works on another device but always fails on this one

What to include in the ticket

What not to include

Account passwords, full subscription links, screenshots of payment receipts, ID documents. None of these help locate the problem and all of them widen the exposure. If you must show the subscription link, blank out the token section.

Where to submit and what happens next

Tickets are submitted inside the user panel — log in and open the ticket page. Before you do, skim the Guides: some problems already have an answer there. You can also check the currently available contact methods on the contact and support page.

If troubleshooting ends with the service not meeting your expectations, the 30-day money-back guarantee can be requested in the panel. Creating an account needs no email address — a username and password are enough, and the same holds through the refund process, so nothing gets stuck on a missing mailbox.