Troubleshooting guide: layer by layer

Diagnostic framework: find the fault layer first

The most time-consuming part of troubleshooting is never the fix — it is looking in the wrong place. The same “can't connect” can come from account status, the local network, client configuration or the destination service itself, and those four sit far apart, each needing a different response. Switching routes over and over right away usually just replays the same error a few times and buries the real clue.

This chapter starts with a layered framework and an information checklist. The eight chapters that follow go symptom by symptom and each can be read on its own, but it is worth spending three minutes on the triage flow here first to see which layer the problem sits in, then jumping to the matching chapter. Readers new to the service can also work through the getting started guide — sign-up, plan choice, subscription import — and then come back here.

What each of the four layers covers

Account layer. The account layer answers “am I allowed to connect”. Whether the subscription is still valid, whether this month's data is used up, and whether the plan has expired decide whether the client can pull a valid route configuration from the server. VPNWing monthly plans come in three tiers: ¥9.9/month with 60GB, ¥18/month with 250GB and ¥28/month with 500GB, with data resetting each month on the activation date; there are also data packs at ¥158/300GB, ¥358/1000GB and ¥658/3000GB that last until used up and never expire. If this month's allowance is gone, the client usually connects and then drops quickly, or reports the subscription as invalid. When you upgrade mid-cycle, the price difference is converted into remaining days, so the billing cycle does not restart.

Network layer. The network layer answers “can the local network get out at all”. That covers Wi-Fi signal quality, router state, whether the network restricts certain ports, and whether DNS resolves. The test is direct: quit the client completely and use the plain local connection to reach a couple of everyday local sites. If that already fails, VPNWing is not the problem.

Client layer. The client layer answers “is the configuration right”. That covers the client version, whether the subscription imported successfully, whether routing rules send the target domain to direct connection, and whether the system proxy or virtual adapter has been taken over by other software. Problems here are easily mistaken for route faults, because the symptom is the same: connected, but nothing loads.

Destination layer. The destination layer answers “is the other side healthy”. Some sites restrict datacenter IP ranges, some services do maintenance at certain hours, and some regional restrictions have nothing to do with the route and everything to do with where the exit IP is registered. The test: switch to a route in a different region and try the same site. If every route fails, the problem is most likely on the destination side.

Three-minute triage: work through it in order

1. Open the user panel and confirm subscription status, remaining data and expiry date. This rules out the account layer.
2. Quit the client completely and reach two everyday sites over the plain local connection to confirm the local network itself works. This rules out basic connectivity at the network layer.
3. Reopen the client and switch to a route different from the current one — ideally a different region and a different route type, for example from direct to an IEPL dedicated line. This separates a single-route problem from a global one.
4. In the browser, first open a site you know worked before, then the site that failed. Comparing the two separates “nothing works” from “one site does not work”.
5. If all of the above is fine but the target site still fails, note the exact message shown at the point of failure and move into the matching chapter.

After these five steps most problems can be pinned to a specific chapter. Spend the remaining time on details rather than repeated trial and error.

Common misconceptions about simultaneous device limits

VPNWing does not limit simultaneous connections: one account works on Windows, macOS, iOS, Android and Linux at the same time, with no separate activation per device. So when you see a message about “connection count” or “device count”, it is usually not an account quota but the local connection table being full.

There are two usual sources. First, the NAT session table on a home router is finite; when one network is running many downloads, video streams and game connections at once, new connections fail, which looks a lot like “too many devices”. Second, the operating system itself has hit its file descriptor or port limit. Both share one signature: connections recover as soon as you disconnect some devices or pause the heavy task. If that matches, restart the router and reduce concurrent connections rather than changing plans.

What to prepare before opening a ticket

The more complete the ticket, the faster the diagnosis. Include the following in one go:

• The username used at sign-up; never send your password.
• The platform and OS version where it fails, for example the Windows client, macOS client, iOS client, Android client or Linux client.
• The route name and route type shown in the client, for example Tokyo · IEPL dedicated line, Hong Kong · Relay.
• When the fault started, and whether it is constant or intermittent.
• Reproduction steps: the full sequence of actions from opening the client to the failure.
• The exact error text or a screenshot — not just “can't connect”.
• Self-checks already done, for example which routes you tried, which network you tried, and whether you reinstalled the client.

When to open a ticket straight away

Three situations are not worth further self-checking and are faster as a ticket: every device on the same account fails on every route in the same time window; the client errors out and exits on launch or during subscription import and never reaches the main screen; or you have completed the steps in the matching chapter and the problem still reproduces reliably.

The ticket form is inside the user panel, and replies appear on the same page. If the issue involves billing or refunds, VPNWing offers a 30-day money-back guarantee — just include the order details in the ticket, no other documents needed.

No connection at all: check the three stages in turn

“No connection at all” means the client cannot establish a session: the button spins forever, progress stops at some percentage, or it shows connected and immediately falls back to disconnected. These three have very different causes, so identifying which one you have saves most of the guesswork.

The three kinds of “can't connect”

The first is failure before the handshake: an error appears right after you hit connect, with barely any spinning. That usually means the client never established a session with the route entry point, so look at the local network or entry reachability.

The second is failure during the handshake: it spins for seconds to tens of seconds and then fails. The network path is working; the stall is in authentication, configuration delivery or cipher negotiation.

The third is disconnect right after the handshake: it briefly shows connected and returns to disconnected within seconds. These are usually about configuration integrity, system proxy conflicts or security software blocking.

Before the handshake: check the local environment

Step one is always the plain-connection comparison. Quit the client completely — not minimised to the tray — and reach two everyday sites over the local connection. If that fails, VPNWing is not the issue: restart the router, switch Wi-Fi band, or compare against a cellular connection.

Step two, check the system clock. Encrypted handshakes rely on certificate validity checks, and a large clock skew — common on devices waking from long sleep or with a manually changed time zone — makes the handshake fail at the first step, usually with a vague error. Every platform has an automatic time sync switch in system settings; turn it on, restart the client and try again.

Step three, check security software. Some antivirus and firewall products treat the virtual adapter created by the client as an abnormal network interface and block it, which shows up as the client reporting connected while no new interface appears in the system. Add the client to the allow list, or temporarily disable protection for a comparison test — and remember to turn it back on.

Step four, check whether a second proxy app is running. Two clients taking over the system proxy or creating virtual adapters at the same time overwrite each other's configuration, and neither connects. Keep only one running at a time.

During the handshake: authentication and subscription

If the network path is confirmed good, look at the subscription next. Check three things in the user panel: whether the subscription is valid, whether any data remains this month, and whether the plan has expired. If any one of them fails, the client is rejected at the authentication stage.

A failed subscription import also looks like “can't connect”. The test is to trigger a subscription update manually in the client and see whether it reports success. If the update fails, jump to the subscription update chapter later on, which has the full path.

Another case is a mismatch between client version and subscription format. Subscription content is delivered in different formats depending on client type, so a manually pasted configuration can fail to parse when the format is off. Clear the current configuration and pull a fresh subscription from the panel instead of appending to the old one.

After the handshake: connects, then drops

A brief connection that drops immediately usually has one of three causes.

First, routing rules conflicting with the local network. For example, a rule sends the client's own update domain through the proxy, that domain is unreachable from the proxy side, and the client fails its own startup check. Add the client update domain to the direct rules, or temporarily switch to global mode for a comparison.

Second, an MTU mismatch. Encapsulated packets larger than the path MTU that are not fragmented properly get dropped, which shows up as connected but dropping within seconds. This is more common on some mobile networks and dial-up style connections; the “connected but pages won't load” chapter later has the detailed method.

Third, the account being logged in repeatedly elsewhere. VPNWing does not limit simultaneous connections, but if one account is logged in over and over by many devices in a short window, the server may apply protective rate limiting. Confirm that no other device is stuck in a reconnect loop.

Symptom reference table

If it still does not work

If you have tried at least two routes in different regions and of different types — one direct and one IEPL dedicated line — and at least one other network, and the problem still reproduces reliably, open a ticket. Include the full error text shown by the client, when the fault started, and the route names you tried; that shortens handling noticeably.

If only one route is unavailable at certain hours, keep using another route in the meantime and note the exact route name and time window in the ticket so it can be checked directly.

Connected but pages won't load: routing, DNS and MTU

The client says connected and the status light is green, but the browser keeps spinning, or only some sites fail. This is the most common and most misread category in troubleshooting. It is almost never “the route is broken” — it is a question of whether traffic is taking the right path.

First, separate the two scopes

The first is nothing works: after connecting, no site opens, including ones that worked before. These usually come from system proxy settings, a virtual adapter that did not take over traffic, or DNS failing entirely.

The second is some things fail: part of the sites work and others do not, or a site's home page opens but the detail page fails. These usually come from routing rules, DNS results or MTU.

The test is simple: after connecting, visit three sites in turn — a local site, a commonly used international site, and the target site that failed. The combination of results usually points to the right direction.

Direction one: routing rules

Routing rules decide which traffic goes through the proxy and which goes direct. There are two typical failure patterns.

First, traffic that should be proxied goes direct. The target domain is matched as direct, so the request leaves over the local connection and naturally fails. This happens when the rule set lags behind updates or the target site changes domains. Search the target domain in the client's rule list to see which rule it lands on; if it is indeed matched as direct, add a proxy rule manually, or switch to global mode temporarily to verify.

Second, traffic that should go direct is proxied. Local sites get pushed through the tunnel, becoming slower or failing. This does not break connectivity but wastes data and makes the route look slow.

A useful test: switch to global mode and try again. If the target site opens in global mode, the problem is in the routing rules; if it still fails, read on for DNS and MTU.

Direction two: DNS resolution

The signature of a DNS problem is that an address responds to ping but the domain will not open. Either resolution returns a wrong result, or the query gets no answer at all.

The test is to resolve the same domain from the command line and see whether the returned address makes sense. If the result is clearly wrong or the query times out, DNS is the culprit.

There are three fixes, from least to most invasive:

1. Switch the DNS mode in the client. Most clients offer follow-system, built-in DNS and a specified upstream; switching to built-in DNS usually sidesteps local ISP resolution problems.
2. Specify a working upstream DNS manually. Afterwards, flush the system DNS cache once, otherwise the old results keep being used.
3. If only a few domains resolve incorrectly, set a resolution method for those domains in the client, or open the address directly as a comparison. Use that only for verification; day to day, keep using the domain name.

Direction three: MTU and fragmentation

MTU problems are easy to recognise: small pages open, large pages stall halfway; images load partially, video freezes on the first frame, and the login page spins forever after submitting. The cause is that encapsulated packets exceed the maximum length the path allows, and devices along the path do not return the control messages needed for fragmentation, so large packets are silently dropped.

To test this, send probe packets with fragmentation disabled. On Windows, combine the ping -f and -l flags; on macOS and Linux, combine the ping -D and -s flags. Raise the packet size step by step until you find the largest size that still returns a reply with fragmentation disabled, then add the header size to get the usable MTU.

The fix is to lower the MTU in the client or the system network settings. Values around 1400 are common, but the exact number should come from the probe above — do not copy someone else's figure. Disconnect and reconnect once for the setting to take effect.

Narrowing it down from the command line

The commands below are only for checking connectivity and involve no account information:

# Check the domain resolution result
nslookup example.com

# Check whether the target is reachable (connectivity check only)
ping -c 4 example.com

# Check the HTTP response headers to tell a network problem from a site problem
curl -I https://example.com

On Windows, replace ping -c 4 with ping -n 4. If nslookup returns an odd address, the problem is DNS; if resolution is fine but every ping times out, the problem is routing or the routing rules; if ping works but curl -I times out, the problem is more likely MTU or the destination side.

Order of work

Check routing rules, then DNS, then MTU, because the cost of each test rises in that order. Routing rules need one switch to global mode; DNS needs one command; MTU needs several probe rounds. Following that order, most problems are solved in the first two steps.

If all three check out but the target site still will not open, try a route in a different region. If it recovers, the original route's path to that site is the issue — note it and open a ticket. If it still fails on another route while the site opens over the plain local connection, the destination side most likely restricts that region's exit.

Slow speeds: is bandwidth short or is the route taking a detour?

“Slow” is the vaguest kind of report. The same word can mean insufficient local bandwidth, a route that takes a detour, rate limiting at the destination, or a device running something else in the background. Locate the bottleneck to a specific segment before talking about tuning.

First find which segment is the bottleneck

A full path breaks into four segments: device to router, router to local ISP, local ISP to route entry, and route exit to the destination. Congestion in any one of them shows up as “slow”, but each needs a different response.

One basic rule: speed through a proxy never exceeds the local uplink bandwidth. If the local uplink is small to begin with, no route will make uploads faster. Likewise, if other devices at home are running system updates or cloud sync, part of the available bandwidth is already taken.

How to measure segment by segment

Step one: disconnect the client and measure from the local network to a local site. Record the result. That is the baseline.

Step two: connect the client and measure to a site in the same region. If this already drops noticeably, the problem is between the device and the router — check Wi-Fi signal strength, band (2.4GHz and 5GHz differ a lot in real throughput) and same-channel interference.

Step three: connect the client and measure to a site in the target region. This reflects the quality of the cross-border link.

Read the three results together: if step one is already slow, the problem is local; if step one is fine and step two drops, the problem is the client or the router; if the first two are fine and step three is slow, only then is it the cross-border route.

One caveat: a single speed test varies a lot with test server load, time of day and browser cache. Run at least three tests and look at the median rather than the peak.

Route choice: nearby does not mean best routed

Many people assume closer is faster, but that is not always true. Cross-border link quality depends on hop count, which backbones are crossed and whether the path uses a dedicated channel — not just straight-line distance. The three route types work like this:

Route types: IEPL dedicated lines use a dedicated channel, relay routes forward through backbone nodes, and direct routes use the local exit. The full list of regions and types is on the route list page.

If a route performs well during the day and slows noticeably in the evening, the shared link is probably congested at peak — moving to an IEPL dedicated line usually helps. If a route is slow at every hour, the routing is more likely taking a detour, and changing region works better than changing type. For a general method of picking routes, see choosing a route by region, type and use case.

How client settings affect speed

A few settings that are easy to overlook:

• Protocol and cipher suite. Stronger encryption costs more computation. On low-power devices — older mobile devices or entry-level routers — that cost can become the bottleneck. If the device is limited, choose a lighter combination.
• Multiplexing. It lets several connections share one tunnel and cuts handshake overhead, but on lossy links it can amplify head-of-line blocking. Try it on and off and compare.
• Rule set complexity. With a very large rule set, every request has to be matched, which adds noticeable latency on slower devices. Trimming the rules or matching by domain suffix helps.
• Background tasks. System updates, cloud sync and photo backup all take bandwidth in the background, and they often start automatically at night. Check their status before investigating speed.

When it is a plan allowance problem

If slower speeds come with unstable connections, open the user panel and check this month's data. VPNWing's three monthly plans are ¥9.9/month with 60GB, ¥18/month with 250GB and ¥28/month with 500GB, with data resetting each month on the activation date. Some clients warn you when the monthly allowance is nearly used up.

If it is just one heavy month, top up with a data pack: ¥158/300GB, ¥358/1000GB, ¥658/3000GB, valid until used up and never expiring. Data packs and monthly allowances are counted separately and do not conflict. If your usage is consistently above the current tier, upgrading the monthly plan is better value, with the price difference converted into remaining days. The full comparison of the three tiers is on the plans and pricing page.

Do not judge from a single speed test

Speed test results are influenced by too many factors for a single number to mean anything. A more practical way to judge a route is to use it at your usual hours, on the sites you actually visit, over several days. If a route is stable most of the time, there is no need to drop it because one test looked low.

If you have measured segment by segment as above and confirmed the bottleneck is the cross-border link, and at least two routes in different regions show no improvement, open a ticket with the times of the three measurements, the route names and the results.

Peak-hour lag: where congestion comes from and how to switch routes

If connections are fine during the day but start lagging between seven and eleven at night — video buffering, choppy meeting audio — it is probably not a device fault but shared cross-border capacity being used up at peak.

Why the evening specifically

Part of the cross-border path is shared. Weekday evenings are when home networks are busiest: video, games, downloads and video calls all at once, and international gateway bandwidth is heavily used. At the same time the destination servers are in their own peak window, so response times drop as well.

That means two things. First, peak-hour lag is often the two effects stacking, not purely a route problem. Second, simply switching to another route of the same type may help very little, because the new route uses the same congested segment.

How the three route types behave at peak

Different route types are affected differently by congestion:

• IEPL dedicated lines use a dedicated channel that avoids congested public internet segments, so they are affected least at peak. The trade-off is a higher unit cost, which is why they are usually reserved for cases that need stability.
• Relay routes forward through backbone nodes: the first half takes an optimised path, the second half still shares public links. Peak performance sits between dedicated lines and direct.
• Direct routes leave through the local exit and depend entirely on public links, so they fluctuate most at peak.

VPNWing currently offers 120+ countries / 160+ routes across the three route types. Direct routes are usually enough for everyday browsing; if peak hours are your main usage window, prefer IEPL dedicated lines or relay. The full route list with type labels is on the route list page, grouped by region with the type marked on each entry.

Rule out the variables at home first

Before blaming the route, spend two minutes ruling out local factors:

1. Whether other devices at home are running heavy tasks. System updates, cloud sync and TV boxes caching video all take bandwidth, and they often start automatically in the evening.
2. Whether Wi-Fi is being hit by a neighbour's signal on the same channel. Peak hours are also your neighbours' peak hours, and 2.4GHz interference gets noticeably worse. Switching to 5GHz usually improves things immediately.
3. Whether the router has gone weeks without a restart. On some home routers, a fragmented session table after weeks of uptime slows new connections. Restart once as a comparison.
4. Whether the device itself is throttling. Laptops on battery limit performance, and encryption overhead rises accordingly.

Only after ruling out these four is it accurate to blame the route.

Five things you can do

One: pick routes by use case. Video meetings and large transfers get IEPL dedicated lines; everyday browsing and short video are fine on relay or direct. Not every scenario needs the same route.

Two: schedule heavy tasks off-peak. System updates, backups and large downloads can run during the day or late at night, outside the peak window.

Three: reduce concurrency. One account allows unlimited simultaneous devices, but several high-bandwidth tasks at once compete with each other. Pause unnecessary background sync during peak hours.

Four: cut unnecessary computation. On limited hardware, a lighter cipher combination frees up some processing capacity.

Five: log the hours and routes. If a route slows down reliably at certain hours, write it down. That record is valuable for telling a route problem from general congestion, and it is the most useful information in a ticket.

About speed promises

One thing to be clear about: VPNWing does not promise specific speed figures. Real cross-border speed depends on local bandwidth, the destination site, time of day and routing, and any fixed speed promise would fail to reflect that. What can be confirmed is route type and coverage: 120+ countries / 160+ routes, three route types to choose from, and no limit on simultaneous devices.

If peak-hour lag is already interfering with normal use and switching to a dedicated line type has not helped, open a ticket with the specific hours, route names and what you were doing. These cases usually need route-by-route checking, and the more specific the information, the faster the diagnosis.

Frequent drops: reconnect strategy and network switching

Drops are more irritating than a failure to connect, because they interrupt something in progress. The key to diagnosing them is not reconnecting but finding the pattern: is the interval fixed, does it coincide with a particular action, does it only happen on one network. Once the pattern is clear, the cause is usually pinned down.

Three drop patterns

First, a fixed interval. It drops every few minutes or tens of minutes, roughly the same gap each time. These usually relate to keepalive, heartbeat timeouts or a server-side session limit.

Second, random. No fixed interval — sometimes hours without a drop, sometimes three drops in ten minutes. These are mostly about the network environment: Wi-Fi signal fluctuation, a mobile device handing over between base stations, or jitter upstream.

Third, dropping when idle. It stays up while in use, but after being left alone for a while you come back to find it disconnected. That is a classic NAT session timeout — expected behaviour, not a fault.

The test is direct: note the times of at least three drops and see whether the gaps are similar. Three is enough to show a pattern.

Regular drops: keepalive and timeouts

If the interval is fixed, check the client's keepalive settings first. Most clients offer a heartbeat interval or a keepalive switch; with it on, the client sends small packets periodically to hold the session open. With keepalive off, intermediate devices on the path may reclaim the session after a period without data, which shows up as drops at a fixed interval.

The second thing to check is the server-side session limit. Some routes cap the length of a single connection to balance load and force a reconnect when the time is up. The signature: it reconnects successfully straight away and then runs stably for the same length again. If that matches, it is not a fault — consider a route with a different session policy.

The third thing to check is system sleep. When a laptop lid closes or a mobile device screen locks, the system suspends network activity and the tunnel is dead on wake. Allow network devices to stay active during sleep in the power settings, or get into the habit of reconnecting manually after waking.

Random drops: network switching and signal

With random drops, the network environment is the focus.

Wi-Fi signal fluctuation. Distance from the router, walls in between, or many same-channel devices nearby all raise packet loss. Past a certain loss level the client decides the link is unusable and reconnects. Test by moving closer to the router: if drops become noticeably rarer, signal is the issue.

Mobile handovers. On the move, a device hands over between base stations, and each handover briefly interrupts the data connection. Without fast reconnection in the client, that shows up as a drop. This is very noticeable on a commute; it is a property of the network, so the response is to enable automatic reconnection and shorten the retry interval.

Two networks at once. Some devices keep Wi-Fi and cellular active together and switch intelligently between them. The tunnel dies at the moment of switching. If you do not need the dual-network boost, turn one off.

Upstream jitter. If other devices on the same network also lose connectivity at the same moment, the problem is the local ISP or upstream and has nothing to do with VPNWing. Check by watching a device that is not using the proxy.

Drops when idle: NAT session timeout

Home routers and ISP gateways both keep a NAT session table with a lifetime per entry. A connection with no data for a long time gets reclaimed, and once it is reclaimed the tunnel is gone. This happens on every NAT-based network; it is not specific to VPNWing.

There are two responses: turn on the client's keepalive so a small amount of data always flows, or extend the NAT session timeout in the router settings — some routers offer it, possibly named “TCP timeout” or “session persistence”.

Note that the keepalive interval should not be too short. Too short and the client sends small packets constantly, which drains battery on mobile networks. In most cases an interval of tens of seconds to a few minutes is enough.

Interference at the system level

A few easily overlooked sources:

• Power saving. Windows power saving, macOS low power mode, and battery optimisation on Android and iOS all restrict background network activity. Adding the client to the allow list avoids it.
• Security software network control. Some security suites audit each program's network access and silently block reconnect requests in the background.
• Virtual adapter conflicts. After installing other VPNs or virtual machine software, several virtual adapters may be left behind, and confused route priorities cause intermittent drops. Removing unused adapters usually helps.
• System proxy being rewritten. Some software rewrites system proxy settings on a schedule, and the connection drops at that moment. Check whether such software is running.

Checklist

1. Note the times of at least three drops and see whether there is a pattern.
2. Turn on client keepalive and watch for improvement.
3. Compare on another network, for example switching from Wi-Fi to cellular.
4. Check system power and battery settings and add the client to the allow list.
5. Remove unused virtual adapters and extra proxy software.
6. Compare against a route of a different type.

If you have worked through the list and drops still occur reliably, and you can give the drop times and route names, open a ticket. These cases usually need server logs, so the more precise the times, the better. For how to measure connection success rate and drop rate yourself, testing stability yourself gives reproducible steps.

Subscription update failures: check the address, the clock and the format

The subscription is the configuration channel between client and account. The client periodically requests the subscription address and receives the route list, routing rules and connection parameters. A failed update means the client cannot get the latest configuration, which shows up as an empty route list, every route timing out, or the client reporting an invalid configuration.

How the subscription works

The subscription address is a link with a token bound to the account. When the client makes the request, the server identifies the account from the token and returns configuration in the matching format. Three points in that flow can fail: whether the request gets out, whether the server accepts the token, and whether the client can parse what comes back.

In troubleshooting terms, that is three directions: address, clock and format.

Note that the subscription address is an account credential: get it only from the user panel, do not paste it into public channels and do not send it to others. If you suspect it has leaked, reset it in the panel.

Direction one: the address itself

The most common cause of failure is an incomplete address. Subscription addresses are long, and copying from a chat app, email or notes easily truncates them or adds line breaks and spaces.

Check three things: whether the address starts with the complete protocol header and contains no spaces or line breaks; whether the chat app auto-detected part of it and turned characters into links or emoji; and whether the parameters at the end, especially the token, are complete.

Another common cause is security software rewriting the address. Some suites perform man-in-the-middle inspection on all encrypted requests, and after rewriting, the server cannot recognise the token. Test by requesting the same address twice in the client: if both fail while the browser reaches other sites normally, try temporarily disabling that inspection for a comparison.

Direction two: clock and certificates

Subscription requests use an encrypted connection, and certificate validation depends on the system clock. With a large clock skew the certificate is judged invalid and the request fails at the handshake, while the client usually only reports “update failed” without saying why.

How to check: open the system time settings, confirm automatic time is on, and verify the time zone. Travelling across time zones, long sleep periods and manual changes can all cause skew.

If the time is correct and it still fails, check whether software that intercepts encrypted traffic is installed. Such software replaces the system certificate chain, and the client can no longer verify the server certificate.

Direction three: format matching

Subscription content is delivered in different formats depending on client type. If the client type is detected wrongly, or a mismatched format is chosen manually, parsing fails.

How to check: fetch the subscription again from the panel, choose the format that matches the client type, and do not assemble it by hand. If the client supports several formats, prefer the one it detects automatically.

Another sign of a format mismatch is “update succeeded but the route list is empty”. The request worked, but the returned content was not parsed correctly. Clear the current configuration and import again rather than appending to the old one.

Checking address reachability from the command line

The examples below use a placeholder address and only illustrate the method. Do not substitute your real subscription address and paste it in public:

# Check whether the subscription address is reachable, headers only
curl -I "https://example.com/sub?token=YOUR_TOKEN"

# Check the first lines of the response to confirm it is a configuration, not an error page
curl -s "https://example.com/sub?token=YOUR_TOKEN" | head -n 5

If the first command returns 4xx or 5xx, the server rejected the request — focus on the token and the completeness of the address. If it returns 200 but the second command prints a web page instead of configuration text, the request was intercepted or redirected by an intermediate device.

Full re-import steps

1. Confirm in the user panel that the subscription is active and this month's data is not used up.
2. Copy the subscription address again, and paste it into a plain text editor first to check for stray characters.
3. Delete the current configuration in the client — export a backup first rather than overwriting it.
4. Create a new configuration, paste the address and wait for the update to finish.
5. Confirm the route list has entries, then pick any route and test a connection.
6. If the client supports it, enable automatic updates with a sensible interval.

If it still fails

If all three checks above are confirmed and the subscription still fails to update, try updating once on another network — some public networks block non-standard requests. If it succeeds there, the original network has a restriction.

If it fails on every network, include in the ticket the exact error text, the client platform, when the failures started, and whether they reproduce on several networks. Do not paste the full subscription address into the ticket; give only the last few characters of the token.

One app can't use the proxy: routing rules and forwarding

The browser is fine, but one particular app never connects. The approach here is completely different from the previous chapters. It is not “the network is down” but “this app's traffic is not entering the tunnel as expected”.

Why only one app fails

Applications handle network requests very differently: some follow the system proxy, some implement their own network stack, some connect straight to an address and skip domain resolution entirely, and some prefer UDP. Routing rules usually match by domain or process, so once an app's behaviour falls outside what the rules cover, its traffic leaks out.

The first step is to confirm whether the app's traffic goes through the proxy at all. After connecting, watch the client's connection log for requests from that app. No entries means the traffic never entered the tunnel; entries that fail mean it entered the tunnel but the destination side refused it.

Cause one: the app ignores the system proxy

The system proxy is a convention that applications may follow or ignore. Some apps open connections directly without consulting the system proxy settings, so their traffic bypasses the tunnel.

The fix is to switch the client to TUN mode, called virtual adapter mode or enhanced mode in some clients. TUN mode takes over traffic at the network layer and does not depend on the app honouring the system proxy, so it covers more.

The trade-off is that TUN mode needs higher system privileges and may conflict with security software on some systems. If the system network misbehaves after switching, switch the mode back before investigating.

Cause two: hard-coded resolution

Some apps bundle their own resolver addresses or hard-code server addresses, skipping system resolution entirely. In that case, even if the routing rules list the domain, it will never match.

How to check: look at the destination in the client's connection log. If it shows a domain, system resolution was used; if it shows an address, the app handled it itself.

There are two responses: add the app's destination address ranges to the proxy rules, or switch the client to global mode so all traffic enters the tunnel. Global mode is best used temporarily — leaving it on wastes data and slows local sites.

Cause three: UDP and QUIC

Most proxy protocols support TCP fully; UDP support depends on the implementation. If an app relies mainly on UDP — voice calls, real-time games, some messaging apps — and the client has UDP forwarding off, that traffic simply fails.

A related issue is QUIC. QUIC runs over UDP and is the preferred transport for many sites. If UDP is blocked and the client does not fall back, pages spin forever while another browser opens them fine.

The response: enable UDP forwarding in the client if the option exists; if only the browser is affected, turn off QUIC in the browser settings to force a fallback to TCP; for games and voice apps, prefer routes with good UDP support.

Cause four: certificate pinning

A few apps hard-code the server certificate fingerprint and trust only that certificate. Any man-in-the-middle decryption breaks them, and a proxy does exactly that kind of interception.

The symptom is the app reporting a network error or an insecure connection while the browser on the same device reaches the same service normally. There is usually no client-side fix: add the app's domains to the direct rules so it uses the local network. If the service is unreachable over the local network, only the app side can change that.

By app type

Order of checks

1. Confirm whether the app's traffic appears in the client log. No entries: follow the “ignores the system proxy” path.
2. Entries exist but fail: check whether the destination in the log is a domain or an address. If it is an address, check hard-coding and rule coverage.
3. Check whether UDP is involved. Turn off QUIC or enable UDP forwarding as a comparison.
4. Still failing: check certificate pinning and add the app's domains to the direct rules as a comparison.

If one route type is clearly unfriendly to that app, try another. If every route behaves the same, note the app name, the platform and the destination shown in the client log, and include them in the ticket. For how meeting and collaboration tools differ in route choice when working remotely, see choosing routes for remote work.

Mobile background drops and DNS resolution errors

Mobile problems come from two sources: system restrictions on background apps, and stale resolution results after a network change. Both are rare on desktop and quite common on mobile devices.

Why mobile apps drop in the background

To save power, mobile operating systems restrict background apps strictly. Once the client goes to the background, the system may freeze its network activity after a while and the tunnel dies. Coming back to the foreground, the client has to reconnect, which means an interruption of seconds to tens of seconds.

This is by design, not a client fault. The test is simple: keep the client in the foreground and see whether drops still happen. Stable in the foreground and dropping in the background means system background limits.

iOS and Android differences

iOS restricts background networking more strictly. The system gives VPN apps some background processing time but does not keep it indefinitely; after a long period of non-use the connection may be reclaimed. Options on iOS are limited: allow background refresh for the client, turn off low power mode, and keep the client in the foreground when a long-lived connection is needed.

Android varies more, because manufacturers add their own power-saving layers. Common settings include the battery optimisation allow list, background activity limits, autostart permissions and vendor-specific switches such as locking an app in the background. If the client drops especially often on one brand of device, check these first.

Linux desktop is not mobile, but has a similar power management issue. After a laptop suspends with the lid closed, the network device may need re-initialising and the tunnel is gone.

Settings that keep mobile connections alive

Handle it per platform:

1. Find the client in system settings and set battery optimisation to unrestricted, or add it to the allow list.
2. Allow background activity and background data use.
3. Turn off the system's smart or ultra power saving modes, or add the client as an exception in those modes.
4. Enable automatic reconnection in the client and shorten the retry interval a little.
5. If you do not need it on mobile data, set it to stay connected on Wi-Fi only, reducing reconnects caused by switching.

These settings reduce how often drops happen but cannot eliminate them. Handovers on mobile networks, signal dead zones and the system reclaiming resources all cause brief interruptions — that is inherent to mobile use.

Typical signs of a DNS problem

Resolution problems are more common on mobile because devices switch between Wi-Fi and cellular frequently, each switch changes the resolver, and the system cache may still hold results from the previous network.

There are three typical signs: an address responds to ping but the domain will not open, meaning resolution fails while routing works; some domains resolve to the wrong address and show an unexpected page; or after a network switch every domain fails for a while and recovers by itself a few minutes later, which is the cache expiring and healing itself.

How to check: use the system's built-in network diagnostics, or an app that can query resolution, and resolve the same domain once to see whether the result makes sense. If it differs from what you get on a computer, resolution is the problem.

Clearing the resolution cache per platform

Clearing the cache makes new results take effect immediately:

• Windows: run ipconfig /flushdns in Command Prompt.
• macOS: run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
• Linux: depends on the distribution; on systems using systemd-resolved, run sudo resolvectl flush-caches.
• iOS and Android: there is no public cache-clearing entry point, so the simplest approach is to toggle airplane mode once or restart the device.

After clearing, set resolution in the client to built-in resolution so local ISP results do not affect it again. If you just want to confirm the current exit location, use the IP lookup page on this site.

Order of checks and wrapping up

For mobile problems, work in this order:

1. Confirm whether drops happen in the foreground or the background. Background drops: follow the system power settings path.
2. Confirm whether it only happens on mobile data. If so, check handovers and signal.
3. Confirm whether all domains fail or only some. All: check resolution and tunnel state; some: check routing rules.
4. Clear the resolution cache, change the client's resolution mode and try again.

If drops are still frequent after working through the order, include in the ticket the device model and OS version, the client platform, the network type when the drop happened, and whether it happened in the background. That helps tell a system limit from client behaviour.

One more point: VPNWing does not limit simultaneous connections, so mobile devices and computers can use the same account at the same time with no separate activation for mobile. If you were thinking of changing setup just because a mobile device drops occasionally, try the settings above first — in most cases they improve things noticeably.