Complete VPN Troubleshooting Guide

Connection entry point

Cannot connect at all: establish the fault boundary first

Confirm that the underlying network works

A complete connection failure may appear as a connection button that keeps waiting, fails immediately, or triggers repeated retries. The system may show that a connection was requested without ever establishing a tunnel. Do not switch routes first. Exit the client’s connection state and confirm that the current Wi-Fi, wired, or mobile network can open ordinary websites. If the underlying network also fails, address the router, captive portal, airplane mode, or access-network problem first. Hotel, mall, and office guest networks often require browser authentication; until that is completed, the client’s connection request may be discarded.

After confirming that the underlying network works, record its type and test another available connection method once. For example, if the same device fails on a home network but connects over a mobile network, the issue is more likely related to the home router, local-network DNS, or access policy. If both networks fail, continue by checking the account, subscription, and client. The comparison is not meant to make the alternate network a permanent dependency; it is a way to identify whether the problem is on the device side or the network side with as few variables as possible.

Check the client, subscription, and system clock

Open the client’s route list and confirm that it is not empty and that the selected item has not been removed or marked unavailable. If the list is empty, do not keep clicking Connect; go to the “Subscription update failures” section. If routes are present but all fail, fully quit the client and reopen it instead of merely closing the window. Some desktop clients remain in the system tray after the window closes, leaving old network processes running. Relaunching in that state can cause port conflicts or proxy-state collisions.

The system date, time zone, and automatic time synchronization must also be correct. Encrypted connections rely on certificate validity checks, and a significantly incorrect clock may appear only as a vague handshake failure. Enable automatic time settings, restart the client, and test one route again. If other network filters, enterprise security software, or another proxy client is installed, quit them completely first to prevent multiple programs from controlling the system proxy, virtual network adapter, or DNS. Keep only the client used by PDDVPN connected, confirm that a tunnel can be established, and then restore other tools one at a time.

From one-route failure to an overall failure

Testing a single route is not enough to assess the service as a whole. Within the same client, compare routes from different regions and with different route types, waiting for each previous connection to fully close before switching. If only one route fails while others work, keep using an available route and record the failed route name for the support ticket. If every route fails, check whether the local firewall blocks the client, an old proxy remains in the system, or the subscription has updated correctly. PDDVPN covers 90+ countries / 200+ routes; the items shown depend on the current subscription and client synchronization, so one route’s behavior should not be taken as evidence about all routes.

If you still cannot connect after these steps, save the client’s exact error text and the network type used for testing. Even a cryptic message is more useful than “cannot connect” for identifying the stage: a parsing failure usually points to the subscription or DNS, a port conflict to a local process, and a handshake failure to the system clock, network environment, and specific route. Do not edit server parameters in the subscription yourself; changing one character can remove the evidence needed for further diagnosis.

After the tunnel connects

Connected but websites will not open: check the proxy and DNS

Distinguish between an established tunnel and traffic being routed through it

A client status of Connected only confirms that the connection process completed; it does not guarantee that browser traffic is entering the tunnel. Open the client’s status page and confirm that a valid route is selected, then check whether the system proxy or the client’s system-level traffic mode is enabled. The most common desktop case is a successful client connection with the system proxy manually disabled. Another is a browser proxy extension overriding system settings with its own rules. During testing, disable similar browser extensions and keep the system proxy as the only path.

If only one browser cannot open websites while others work, the cause is usually that browser’s extensions, private DNS, cache, or network policy. Use a browser window without extensions for comparison, disable its custom proxy settings, and restart the browser process. Refreshing a page alone may not rebuild the underlying connection; fully quitting and reopening is more effective at ruling out reused connections. If no browser or app can connect, continue by checking DNS, routing mode, and any old proxy address left in the system.

Clear leftover proxy settings and DNS cache

After an abnormal client exit, the system proxy may still point to a local port that is no longer listening, preventing every website from loading. Reopen the client, disconnect normally, and then quit the program so it can restore the system settings. If that does not help, open the system network settings and check whether the proxy remains set manually. If you do not know the exact address, do not enter a new one at random; disable the unused manual proxy and reconnect the client.

When a domain cannot be resolved, a browser may report that the address cannot be found even though a previously cached service remains reachable. Clear the system DNS cache, then disconnect and reconnect. Run the commands below in the appropriate system terminal. If permission is denied, use an administrator terminal as prompted by the system, and never paste an entire script from an unknown source.

Windows:
ipconfig /flushdns

macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux:
resolvectl flush-caches

After running the command, fully quit the browser and test again. If the system does not provide the corresponding command, use the reconnect option in its network settings; there is no need to install an extra tool just to clear the cache. The key sign of a DNS issue is that a domain cannot open while a known network connection still exists—not that every web error is caused by DNS. If the client log explicitly reports a domain-resolution failure, check whether it uses system DNS, remote DNS, or a rule-defined resolver.

Choose the troubleshooting path based on the scope of the error

To distinguish a rule problem from a route problem, temporarily switch the client to global traffic mode for a short test. If access works in global mode, the route itself is usable and the issue is more likely in the routing rules. If access still fails, return to DNS, the system proxy, or the selected route. Restore the original mode after testing so a temporary global setting does not become the long-term configuration. For an app that is not being handled by the rules, continue to the “A specific app does not use the proxy” section.

Performance sorting

Slow speeds and peak-hour lag: separate latency from throughput

First identify what is slow

“Slow speed” can describe several different situations: a long wait before a page opens, repeatedly reduced video quality, low large-file transfer speeds, or sluggish voice and interactive apps. Their bottlenecks differ. Web pages and interactive apps are more sensitive to latency, packet loss, and DNS; large transfers depend more on sustained throughput; video is also affected by the target platform’s route, cache nodes, and account-region checks. Record the exact scenario instead of writing only “slow.”

Disconnect first, then confirm that the underlying network is stable on the same device, network, and time period. If the underlying network is already congested, switching routes can change the international path but cannot fix a weak local Wi-Fi signal or a crowded broadband uplink. Stay close to the router when using wireless, and avoid simultaneous cloud sync, system updates, or large uploads. When upload capacity is saturated, page requests and video controls queue up too, making download speed appear lower. Connect the route only after establishing a baseline, then compare the same target with similar actions.

Choose routes by geographic path, not by name

Similar route names do not mean identical paths. Start with a route whose region matches the target service and whose geographic distance is relatively short, then assess stability. If the target service requires a particular region, prioritize the correct exit region rather than the name that appears closest. Route types may differ in detour length, congestion sensitivity, and connection stability. See the server page for the practical differences between relayed and direct routes.

Keep all other conditions unchanged when testing routes. Change one route at a time and use it continuously for a while before judging the result. Frequent switching leaves old connections in the browser, video app, and DNS cache, mixing the results. If a new route restores web access but video still buffers, check the target platform, quality settings, and app cache. If every type of access slows down, recheck the local network, system proxy mode, and background traffic.

Use time comparisons for peak-hour issues

The key to peak-hour lag is identifying whether congestion occurs in local access, the carrier uplink, the selected route, or the target platform. Keep the same device and test target, and record results both off-peak and during the affected period. If performance also drops while disconnected, prioritize the local access network or carrier link. If only one route fails at a particular time while others work, switch to an alternative route in the same region and include the original route name and time period in the ticket.

Do not use a snapshot speed-test screenshot as a substitute for sustained-use results. A short test may coincide with a cache hit, a temporary bandwidth burst, or app preloading and cannot represent a long transfer. A more reliable approach is to keep the target fixed and observe whether page loading, video buffering, and the actual task remain stable. This site does not use fake online-user counts or fake availability rates to explain route status; diagnosis should consider the complete chain of the current device, network, route, and target service.

If the same sustained performance problem occurs across multiple regions and network environments, include the underlying-network result, target type, affected route name, time period, and client log in the support ticket. Do not send only a speed screenshot or crop out the route name and test environment. These details help support distinguish local access, route scheduling, and target-platform issues, reducing repeated questions.

Connection stability

Frequent disconnects and mobile background drops

Determine whether the network changed or the tunnel broke

When disconnects recur, first check whether the device switched from Wi-Fi to a mobile network, roamed between wireless access points, or briefly entered a weak-signal area. A change in the underlying network address may require the existing connection to be rebuilt, reflecting both access-network switching and client reconnection. If disconnections happen whenever you leave a particular location, address wireless coverage first. If the device remains still and the underlying network is stable but the client keeps reconnecting, check the route, power-saving policy, and system network permissions.

On desktop, first disable automatic recovery after sleep and wake for testing, then restart the system completely before reconnecting. After sleep, old virtual adapters and routes may remain temporarily; the client can show Connected while the tunnel is already invalid. Disconnect normally and quit the client before restarting it; this clears old state more reliably than repeatedly clicking Connect. If drops occur only on one route, switch to an alternative in the same region and record the original route. If all routes drop in similar situations, check local network fluctuations, system sleep, and security software.

Order of operations for mobile background limits

Mobile operating systems restrict network apps that remain in the background to control battery use. Common signs include the connection disappearing after the screen locks, needing to reconnect after switching apps for a while, or the client being terminated when the system clears background processes. In system settings, allow the client to maintain network activity, remove its background restrictions, and confirm that VPN permission remains allowed. Settings names vary by device maker, but the question is the same: after the client moves to the background, are its process and network tunnel being paused by the system?

Do not enable the system’s other VPN configurations, enterprise work profile, and multiple proxy clients at the same time. Mobile systems generally allow only the active network extension to handle traffic, and a configuration started later may replace the previous connection. If the status-bar icon repeatedly appears and disappears, open the system VPN settings, identify the active item, and keep only the configuration being tested. Restore other work configurations afterward as needed.

Identify intentional disconnects in the log

If the client log shows a user action, system sleep, network change, or stopped process, address the device state first. If it shows a route timeout, repeated handshake failure, or remote closure, switch routes and keep the log. Do not assume the problem is solved just because automatic reconnection succeeded; frequent reconnects interrupt live calls, transfers, and interactive sessions. A genuinely stable result means the device remains usable during normal use, screen-lock recovery, and an unchanged network.

When switching between mobile data and Wi-Fi, manually disconnect first, wait for the new network to finish connecting, and then reconnect. This adds a step but prevents the old session from retrying continuously during the transition. If frequent network switching is unavoidable, enable the client’s on-demand or automatic reconnect feature only after confirming stability on a single network; otherwise it can hide the underlying fault and fill the log with repeated retries.

If the disconnect has a clear trigger, describe the action in the ticket—for example, locking the screen, switching away from Wi-Fi, waking the system, or opening a specific app. Without a clear trigger, record the time period, selected route, network type, and whether the client was in the foreground or background. This turns a “random disconnect” into a reproducible condition that support can check across the device, power management, access network, and route.

Subscription synchronization

Subscription update failed: check the link, permissions, and cache

First distinguish import failure from update failure

An import failure means the client has never successfully generated a route list; an update failure means the existing routes remain visible but the latest content cannot be retrieved. The two require different paths. For a first import failure, copy the complete subscription again from the user panel. Do not select only part of the text or forward it through a tool that may truncate long content. For an existing subscription that will not update, first confirm whether the old routes still connect, then review the client’s exact update error.

A subscription link is an access credential and should be stored only on your own devices and in your own clients. If you suspect it was exposed, use the available option in the user panel to obtain it again instead of posting the link publicly for inspection. Do not paste the full subscription address into a support ticket; support usually needs only the account username, client name, update time, and error details. Access parameters must not appear in screenshots, shared logs, or article comments.

Verify copying, network access, and system time

Format errors during an update are commonly caused by spaces, line breaks, or non-ASCII punctuation inserted before or after the link. Delete the invalid subscription item in the client, then copy it again from the panel and paste it directly. If the client allows address editing, check that the leading protocol and trailing parameters are complete, but do not replace the domain, path, or access parameters yourself. A clear instructional example can be written as:

https://example.com/sub?token=YOUR_TOKEN

This address is provided only to illustrate link structure and cannot be used to connect. The actual subscription must be obtained from the site’s user panel. If the client reports a network timeout, access the user panel over the current underlying network first to confirm that the network itself works, then retry the update. In some cases, an old proxy state sends the client’s update request through an invalid route; disconnect, restore system networking, and update the subscription again. An incorrect system clock can also cause secure-connection failures, so enable automatic time synchronization as described in the “Cannot connect at all” section.

Remove duplicate subscriptions and stale cache

After importing the same subscription multiple times, the client may show several configuration groups with similar names. You may switch to the new group while automatic updates still point to the old one, resulting in “update succeeded but nothing changed” or a mismatch between the selected and connected routes. Keep the copy confirmed to come from the current panel, delete duplicates, then update manually and check the update time. Before deleting anything, confirm whether custom rules are tied to the old configuration so personal settings are not removed accidentally.

If the client cache is damaged, first use its built-in refresh or configuration re-download function. Only after confirming that the subscription address, underlying network, and system time are correct and duplicates have been removed should you consider deleting and re-importing the subscription. Uninstalling immediately also removes logs and makes parsing errors harder to locate. On desktop, confirm that the client has read/write access to its configuration directory; if a system security policy makes it read-only, the download may finish but the new content cannot be saved.

If the panel opens normally but the re-copied subscription still produces the same error in multiple clients, submit a support ticket with the client name, platform, exact error, time period, and whether it is a first-import failure or an update failure for an existing subscription. Do not send the full subscription address or a screenshot cropped down to only the word “failed.” Complete context helps determine whether the request never arrived, the content failed to parse, or permissions blocked the save stage.

App routing

A specific app does not use the proxy: check rules and processes layer by layer

First prove that the route itself works

When browser access works but one app does not, do not replace the subscription first. Use a browser to verify that the target service’s web version or a service in the same region is reachable, confirming that the route and exit region are broadly appropriate. Then temporarily switch the client to global traffic mode and restart the target app for a short test. If it works globally, the issue is in routing rules, app-process detection, or the app’s own network settings. If it still fails globally, check the target service’s region, account status, app cache, and selected route.

The test must be performed after fully quitting the app. Many desktop apps remain in the background after their window closes, and old connections do not automatically rebuild when the proxy mode changes. Confirm that the process has ended from the tray, menu bar, or system task manager before reopening it. On mobile, remove the app from recent tasks and try again. Switching pages inside the app may continue reusing a network session created before the proxy connection.

Understand the difference between a system proxy and a virtual network adapter

Some apps follow the system proxy, some connect directly, and others use an independent networking framework. When the client enables only the system proxy, the latter two types may bypass it. A virtual network adapter or system-level traffic mode usually covers more traffic, but it can also conflict more easily with enterprise security software, other VPN configurations, or local development environments. Choose the mode based on the target app’s behavior rather than keeping the most comprehensive option enabled indefinitely.

If the target app has its own proxy settings, avoid configuring them redundantly with the system proxy. An invalid in-app proxy address can make the app fail even when the system proxy works. Restore the app’s network settings to follow the system, then let the client handle traffic centrally. Development tools, terminal programs, and containers may read separate environment variables; the graphical system proxy is not automatically passed to them. Check the tool’s documented network settings, but never place a subscription address directly in a project file or shared script.

Check rule matches and domain resolution

Rule mode typically decides traffic handling by domain, address, process, or rule group. If a target app uses multiple domains, some direct and others proxied, the login page may work while content fails to load. Review the client’s connection records to see whether the app’s requests appear, which rule matched, and which route was selected. No record may mean that the app bypasses the system proxy or runs in an environment outside the client’s control. If a record exists but the result is wrong, adjust the relevant rule group instead of changing the entire subscription at random.

An app’s private DNS can also return results that differ from the system. Temporarily disable private DNS in the app, clear its cache, and restart it to test whether the resolution path is responsible. If global mode works but rule mode does not, save the target domain and rule-match result before submitting a ticket; this is more useful than providing only the app name. Some services also vary results according to account region, content rights, or login status. A route can provide the appropriate exit, but it cannot replace the service’s own account requirements.

For long-term use of a specific app, document reproducible conditions: whether it works in a browser, whether global mode works, what rule mode matches, whether restarting the process changes the result, and whether the selected exit region meets the target service’s requirements. For streaming scenarios, see the streaming access guide. For AI Tools network requirements, read ChatGPT network selection and stable-use requirements. These pages explain differences between target services; this section remains focused on confirming that local traffic is being handled correctly.

Account status

Cross-check device, traffic, and plan status

How to assess a “device limit exceeded” message

PDDVPN supports unlimited devices, so a device-count message should not initially be treated as a fixed device cap. First determine whether it came from the site’s user panel, the client, or the operating system’s network settings. Some clients summarize duplicate configurations, concurrent connection conflicts, or local authorization issues as a device problem; that does not mean the service plan imposes a device limit. Quit abnormal connections on other devices and reconnect the current device to rule out session conflicts caused by repeated retries, but do not remove devices that work normally.

If the message appears in a third-party client, save the complete text and client name. Do not purchase extra device capacity based on the message or create multiple accounts to work around it. The plan fact for this site is unlimited devices; support will assess the actual cause using account status, subscription requests, and client errors. If several devices fail on the same network but work on another, also check the router’s connection tracking, local-network DNS, and access-network restrictions.

Verify subscription status and traffic cycles

When a connection suddenly stops, sign in to the user panel and check whether the subscription is active and traffic remains available. Monthly subscriptions include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Traffic resets monthly on the activation date, and a mid-cycle upgrade difference is prorated against the remaining days. Do not assume a calendar-month reset or rely only on the client’s local display; its cache may be behind the panel data.

If usage is less predictable over the long term, see the plans page for traffic packs: ¥158/300GB, ¥358/1000GB, and ¥658/3000GB, valid until used and never expiring. Monthly subscriptions and traffic packs are measured differently, so first confirm which type is actually in use. If a purchase exists but the client still uses an old subscription, update the subscription, confirm the active configuration group, and reconnect. After a mid-cycle upgrade, update it again so the client does not continue reading stale cache.

Distinguish account issues from local device issues

If the same account connects on another device but not on the current one, the problem is more likely to be the current client, system proxy, permissions, or network environment. If the same error occurs on every device, prioritize subscription status, subscription updates, and the selected route. When comparing devices, use the same network and route where possible so the device, network, and route variables do not all change at once.

Registration requires no email address; a username and password are enough, making the username an important account-checking reference. Before submitting a ticket, confirm that the username is correct and that the subscription was not generated from another account. Do not show the full username, order details, or subscription credentials in public screenshots. If you are unsure about the account status, use the user panel’s login and ticket options instead of creating another account and mixing configurations from different accounts in one client.

Payment methods include Alipay / WeChat Pay / USDT. A payment record proves only the order step; it does not directly show that the client has updated. After a purchase or upgrade, confirm the panel status, update the subscription, and reconnect. If the order status does not match the payment result, retain the panel order details and payment-channel result for a support ticket. The text states a 14-day no-questions-asked refund policy, but connection issues can usually be resolved through diagnosis first. For the full eligibility conditions, see the refund policy.

Human support

When to contact support and what to include

When a support ticket is appropriate

Submit a support ticket after the relevant basic checks if all routes remain unusable, multiple network environments produce the same result, subscription updates fail in multiple clients, one route remains consistently abnormal, or the account or order status differs from the panel. Human support can verify account-side status, route-side logs, and the information from your environment; it should not require endless reinstalls. Issues limited to one browser extension, local script, or enterprise network policy can also be reported, but clearly describe how that environment differs from an ordinary network.

During a widespread issue, do not create multiple tickets with identical content. Duplicate tickets split the context and prevent confirmed conditions from carrying over. Add new test results to the original ticket and state which action changed the symptom. If the issue resolves on its own, add the recovery time, whether the route was changed, and the current status so support can distinguish a temporary network fluctuation from a settings change.

Recommended support-ticket structure

Write the symptom and platform directly in the title, such as “All websites fail after connecting on macOS” or “Connection drops after locking the screen on Android.” Do not write only “urgent” or “doesn’t work.” In the body, state the system platform and client name, then the current network type, selected route, approximate start time, and whether the issue is consistently reproducible. List the checks already performed, including whether the underlying network works, whether you changed networks or routes, whether you cleared DNS, and the results in global and rule modes.

Screenshots should retain enough context to show the client status, route name, and exact error, but must conceal subscription links, access parameters, payment credentials, and other account information. Include only the relevant log section around the failure; do not send a single conclusion line or upload an entire personal directory without checking it. If the client can export diagnostic logs, inspect the content first to ensure it contains no subscription credentials. If unsure, submit the exact error text first and let support tell you which additional excerpts are needed.

Symptom:
System platform and client:
Current network type:
Selected route:
Approximate start time:
Can the issue be reproduced:
Is the underlying network working:
Other routes tested:
Checks already performed:
Exact client error:
Items for support to verify:

Details that reduce back-and-forth

Time and route name are the most important context for a route issue. “It was slow yesterday” does not identify a specific period or distinguish browsing, video, and download scenarios. State which route was in use, whether the target was a website or app, and whether the underlying network worked after disconnecting. For connection failures, include the exact error. For speed issues, describe the actual task and whether the problem persisted. For subscription issues, state whether it was a first import or an update to an existing configuration. For mobile issues, describe triggers such as foreground use, backgrounding, screen lock, or network switching.

For account and order issues, provide the username and the order identifier visible in the panel, but never send the password. Because registration requires no email address, support relies more heavily on the username and panel records for verification. For payment issues, state whether you used Alipay / WeChat Pay / USDT and describe the status shown in the panel; do not submit complete payment credentials in a ticket. For refunds, the body refers to the 14-day no-questions-asked refund policy; the refund policy defines the applicable scope and process.

Final checks after recovery

After the issue is resolved, restore temporary test settings to your normal setup. For example, switch from global mode back to the original rule mode, remove duplicate subscriptions, re-enable security software confirmed to be compatible, and verify that the system proxy is restored correctly after the client disconnects. If switching routes fixed the issue, keep the original route name and affected period so you do not forget the conditions and repeat the same test later. If clearing DNS or restarting the client fixed it, record the final step that actually worked rather than treating every earlier attempt as necessary.

For recurring problems, create a short personal checklist: underlying network, panel status, subscription update, client restart, route switch, system proxy, DNS, and target app. A fixed order makes it quick to identify the layer where the fault stops. To understand subscription imports, read what a subscription link is and how to import it. To review setup from installation onward, return to the quick start guide. This handbook turns on-site information into a diagnosable, reproducible, and transferable fault record rather than asking users to keep guessing in an unknown state.