VPN Troubleshooting Guide

Can't connect at all: from your local network to the cross-border route

“Can't connect” can describe several different issues: the client won't start, the connection toggle won't turn on, the route handshake fails, or the client says connected but apps still can't reach their services. These failures occur at different layers and need different fixes. First, copy the exact error and note your current network, selected route and the action that triggered it. Don't uninstall the client or change your subscription, DNS and network components all at once. Keeping the original state makes it possible to tell which step actually helped.

Check that your local network can access the internet

Turn off the client connection and open a website you can normally access directly to confirm your internet connection is working. If regular websites won't load either, check whether Wi-Fi requires sign-in, the router is online and your system is still using an old proxy. Hotel and public networks may require you to complete a sign-in page in your browser. Do that first, then start the client. A page loaded from the browser cache doesn't prove you're online: refresh a page that needs to make a new request and check that fresh content loads.

Once your basic connection is working, compare your current Wi-Fi with another available network. Keep the client, configuration and route unchanged during the comparison. If the same settings fail only on one network, the issue is more likely with that local access network than with your account as a whole. Business networks may have specific access policies; if you see a permissions prompt, ask your administrator rather than disabling required security controls. Record that switching networks resolved the issue as diagnostic evidence, but don't assume a particular route will work on every network.

Check the connection toggle and route handshake separately

If the connection toggle won't turn on, check whether your system is asking you to authorize a VPN, network extension or virtual network adapter. Without authorization, the client may show a route list but be unable to handle traffic. Quit other active proxy tools to prevent conflicts over the system proxy or network extension. Reopen the client and enable only the connection you're testing. The app named in the system prompt should match the client you're using. If you're unsure about a permission request, verify its source before approving it.

If the toggle turns on but the route handshake fails, first confirm that the subscription updated successfully and that the account panel shows an active subscription with traffic available. Then compare another route in the same region, followed by a route in a different region. If only one route fails, you can switch temporarily and note the affected route. If all routes fail, check your local network, system time and client error logs. A significantly incorrect system date can interfere with certificate checks; restore the correct time rather than disabling certificate verification.

Narrow down the issue with a minimal test set

A minimal test only requires your current device, an up-to-date configuration and a reliable test website. Pause unrelated downloads, sync tasks and other proxy tools, then load a page in a regular browser. Don't rely on a service that requires sign-in or is subject to regional policies as your only test. If regular browsing works but a specific service doesn't, go to the App Routing section instead of treating the entire connection as broken. The connection icon shows the client's status; it doesn't mean every website is reachable.

If the logs show an authentication failure, check your account and subscription first. For connection timeouts, compare routes and local networks. For permission or interface creation errors, check system authorization. Error names vary by client, so keep the full message instead of just saying “it failed.” You don't need to change route authentication settings or construct a server address manually. Use the configuration from the account panel as your baseline. Mark any manually edited copy separately so a configuration mistake isn't mistaken for a route failure.

Troubleshooting flow: Does direct access work? → Is the system handling traffic? → Is the subscription active? → Is one route failing or all of them? If you still can't connect after changing networks and routes, save a screenshot of the error and a redacted log, then submit the evidence through a support ticket in the account panel.

Connected but websites won't load: distinguish routing from DNS

If the client says connected but websites keep loading, the connection status and actual service access don't match. Common causes include system traffic not reaching the client, failed domain resolution, an old browser connection, rules sending traffic to an unsuitable route, or an issue with the website itself. Test a website you can normally access directly and one that requires the current route. Note whether both fail, only some fail, or only one browser fails. This comparison is more useful than repeatedly toggling the connection.

Check whether requests reach the client

If the client has a connection list or log view, watch for the relevant domain while refreshing the target website. No request in the log doesn't prove the route is down; the browser may not be using the current system proxy, or the app may be using its own network path. On desktop, check whether the client is using the system proxy or virtual network adapter mode; use the names shown in the client itself. Selecting a route without enabling traffic handling may not be enough. Save your original settings before changing modes, and confirm that system permissions are in place.

If the request reaches the client, check how it was matched: direct, proxied or blocked, and which route it used. If the domain matched the wrong rule group, fix the rule or restore the subscription's default configuration rather than simply switching routes. You can temporarily test with the client's global proxy mode as a comparison, but treat it as a diagnostic tool only. Restore your original rules afterward so that work resources and local network services that should connect directly aren't sent through a remote route.

Test domain resolution separately from website access

DNS resolves domain names to addresses, but a successful lookup doesn't mean the website request will work. If the browser says it can't find the server or the logs show a resolution failure, use a system command to check DNS. The commands below query the resolver configured on your system; they don't change settings or require subscription credentials. The example domain demonstrates the command format. For troubleshooting, replace it with the affected website's domain, but don't include a full page URL with sign-in parameters in a command or support ticket.

nslookup example.com

If the lookup returns an address but the browser still fails, check routing, certificate errors and the website's response instead of assuming it's a DNS issue. If the lookup fails, compare results with the client off and on, then check whether your system or browser uses a separate DNS setting. Secure DNS in the browser, DNS handling in the client and the system resolver may all be active at once, producing different results in different apps. Restore a known-good default first, then enable custom options one at a time. Don't copy public resolver addresses from unverified sources.

The limits of cache, address families and certificate errors

After a configuration change, your browser may reuse an existing connection or cached DNS result. Fully quit and reopen the browser, or compare using a separate browser profile, to help distinguish a cache issue from a route issue. Private browsing doesn't isolate every system network state, so it isn't a universal reset. If an old DNS cache is affecting Windows, you can clear it with the command below. This won't fix an invalid subscription or change proxy rules. Record what you're seeing first so you don't lose a useful comparison.

ipconfig /flushdns

Some networks provide multiple address families, and a traffic-handling mode may not cover every path. If the logs show requests taking an unexpected route, check the client's support for your current network and follow its documentation. Don't permanently disable networking across the whole system just to test. If a website shows a certificate warning, don't ignore it and enter account details. Check the system time, domain name and network sign-in page first. Certificate issues are a separate security signal; a connected status is no substitute for verifying them.

If only one website fails, try another browser, a different route and another local network, and record the error shown by the site. If several websites fail on one device while other devices work, investigate that device's DNS and traffic-handling settings first. If the same domain-resolution issue occurs across multiple devices and networks, include redacted lookup results and client logs in a support ticket. Support needs to know whether DNS resolution, rule matching or the connection failed—not just see a screenshot of a loading spinner.

Slow speeds and peak-hour slowdowns: compare the full path

Start by defining what's slow. A slow first page load, video buffering, slow file transfers, choppy meeting audio and delayed AI requests can point to different bottlenecks. They depend on DNS resolution, handshakes, sustained transfers, real-time stability and the target service's processing. Note which app and action are slow, and the local network and time of day. Don't judge an entire route by one probe or download, and don't attribute all the target server's processing time to the VPN connection.

Separate local congestion from the remote route

Turn off the connection and check ordinary internet access. If local websites, transfers on your local network or other direct tasks are also slow, start with Wi-Fi signal, router load and background activity. A connected Wi-Fi status only means there's an active connection, not that data transfer is stable. Distance from the router, nearby interference and large sync tasks on other devices can all disrupt real-time apps. Keep the device in the same spot, pause network-heavy tasks and repeat the same action for a fair comparison.

Once your basic connection is working, compare your current route with a backup route. Keep the app, action and local network the same; don't switch routes while also changing video quality or the download source. The target service may assign different servers based on exit region, so results from different regions aren't a direct comparison of route capacity. Compare routes in the same region first, then check whether another region works better for your needs. A temporary improvement after switching routes only shows that this request took a better path; it isn't a promise of sustained speeds.

Cross-check peak-hour slowdowns by time and network

Peak-hour slowdowns can occur on the local network, the ISP path, the route entry point or the target service. Turn “it gets slow on weekday evenings” into a reproducible record: note the network, route, app action, symptoms and whether the same settings work outside peak hours. Then compare another local network at the same time. If only one access network is slow, support will need the local network comparison. If the same route shows an issue across multiple networks, that provides stronger evidence of a route-side problem.

Don't use probe results as a substitute for real-world testing. A client route probe may test only one target or one connection stage; a good result doesn't guarantee smooth video delivery, meeting relays or AI services. Verify smart route selection with the actual task too. For apps that rely on long-lived connections, frequent automatic route changes may be worse than staying on a working route. First choose a route group that's been tested and check whether the task is stable, then decide whether to enable an automatic strategy. Option names and features vary by client.

Consider route type alongside the task

IEPL dedicated lines, relays and direct connections describe types of access paths, not a universal speed ranking. Whether a route suits your needs also depends on the path from your local network to the entry point, the exit region and the target server. VPNYD covers 90+ countries and 160+ routes. Choose based on the account panel configuration and your actual results. See the Route Guide for an explanation of route types. A region name or route label doesn't guarantee that a particular website will always be accessible.

When testing streaming, keep the content and quality the same and let the player reconnect. For coding tools, test autocomplete requests, extension downloads and command-line access separately; one task doesn't stand in for all the others. For development scenarios, see the guide to choosing routes for Cursor and Copilot. If you've checked your basic network and compared a backup route but the issue still recurs at the same time, submit the task, time range and route details rather than simply saying “it's very slow.”

Frequent disconnects and mobile background dropouts: check the lifecycle

First distinguish between the system closing the client's connection and the connection toggle staying on while an app session drops. The former often involves permissions, sleep, network changes or background restrictions. The latter may also be caused by a target service timeout, a route change or the app's own session policy. Note what happened just before the disconnect: did you lock the screen, close a laptop lid, switch Wi-Fi, change apps, or leave the device in the foreground? The trigger is more useful than “it disconnects after a while” and helps determine whether to check the system or the route first.

Rule out session resets caused by network changes

When switching from Wi-Fi to another network, your local address and routing may change, so existing connections need to be re-established. The client reconnecting doesn't mean a video call, remote terminal or long-running browser session will resume automatically. Test on a single fixed network, away from weak signal areas, with automatic network switching disabled if possible. If the connection is stable on a fixed network but fails after a network change, focus on client reconnection and app session recovery rather than reimporting the subscription as if the account had expired.

If disconnects happen even while the device stays in the foreground, check whether automatic route selection is enabled and whether the logs show an exit change just before the issue. Automatic strategies can suit some tasks, but apps with long-lived connections may need a consistent exit. If supported, temporarily pin the current route for comparison. If the task stays stable, look at the strategy group. If it still disconnects, compare a backup route and local network. Don't change the strategy, traffic-handling mode and app client all at once.

Mobile background management and VPN authorization

On Android, battery saver and background restrictions can prevent the client from running continuously. In system settings, check whether the client is allowed to run in the background and whether it's on a restricted-app list, then adjust the options available on your device. Menu names vary by system and manufacturer, so no single path works everywhere. Grant only the permissions the client needs; you don't have to disable battery saving for the whole device. After changing settings, test in the foreground, while switching apps and with the screen locked, noting which state triggers the problem.

On iOS, first confirm that the system VPN configuration belongs to the current client, its connection authorization is complete and no other configuration is also handling traffic. Not seeing a refreshed screen after switching apps doesn't mean the system VPN has disconnected; return to the client and verify with an actual request. Conversely, a connection icon in the status bar doesn't guarantee that an app session is intact. If an app loses its session only after the screen locks, check that app's own background behavior instead of attributing everything to the connection tool.

Test desktop sleep and recovery separately

After sleep, closing the lid or waking up, Windows and macOS may reinitialize parts of the network stack. First confirm that the system network has recovered, then check whether the client is handling traffic again and whether the previous route still works. If only the browser fails after waking, reopen it for comparison. If all apps fail, check the system proxy, virtual interface and client logs. Manually reconnecting can help verify the issue, but if every wake requires it, record the steps that reliably reproduce the problem and check startup order and permissions.

On Linux, distinguish between closing the graphical window and stopping the background process. Closing the window doesn't necessarily stop the proxy core, and a running service doesn't mean the desktop environment has restored its proxy settings. Check the process or service status for your installation; don't copy a service name that doesn't apply. If the client and network manager compete over routes after wake, keep their logs and note the timing. Rebooting repeatedly can hide the issue, making it difficult to determine what changed before and after recovery.

Apps with long-lived connections are more sensitive to interruptions. AI coding tools, remote terminals and meeting apps may keep a stale session even after the underlying connection recovers, requiring a new request or meeting. Check both connection status and app behavior; don't rely on a green icon alone. If the same route shows similar interruptions across multiple devices and networks, submit a ticket with timestamps and logs. If the issue occurs only while locked, asleep or in battery-saver mode, start with platform permissions and background settings.

Troubleshooting flow: Is the connection stable in the foreground? → On a fixed network? → On a fixed route? → Does locking or waking trigger the issue? In your ticket, say whether the client toggle turns off, whether the app recovers automatically and whether the network or exit changed just before the problem.

Subscription update failed: check the source, request and account status

The subscription provides the client with route and rule settings. A failed update doesn't necessarily mean your current connection will stop working immediately: the client may still have an old configuration, or it may no longer have any usable routes. First identify what happened: the subscription never imported, an existing configuration won't refresh, the route list shrank after an update, or the update succeeded but connections fail. Keep the import source, exact error and before-and-after states for each issue. Don't import the same subscription repeatedly and then guess between several similarly named configurations.

Confirm the subscription source in the account panel first

Sign in to the account panel and confirm that the account and subscription you're using belong together. Check the subscription status and available traffic. The client and subscription access are both in the panel; the client requires you to be signed in with an active subscription. Don't copy a subscription URL from chat history, an unfamiliar website or someone else's screenshot. Treat the URL like an account credential: don't paste it into public speed-test sites or send it to others in an ordinary screenshot.

If the panel status doesn't match what you expect, check whether you're signed in to another account, whether the payment order is complete and whether the client is still using an old configuration. VPNYD doesn't require an email address. Your username and password are used to access your account, so verify them against your own username and panel records. Don't create new accounts repeatedly to troubleshoot network issues; orders, subscriptions and test records can become scattered and harder for support to verify. Check order issues separately in the panel.

Different error messages call for different fixes

If the update times out, first check whether your basic network can open the account panel, then check whether the client's update request is using a proxy route that's no longer working. Some clients update configurations through the current proxy; others use the system network. Check the client interface and logs. If the update depends on the very route that's failing, you're caught in a loop and can't refresh the configuration. In that case, keep the original configuration and use a working basic network to get a fresh import link from the panel instead of editing subscription authentication fields manually.

If the update reports an invalid format, check whether you copied a documentation page, sign-in page or incomplete link. Some network sign-in pages return webpage content when the client expects configuration text, causing a parsing error. Check whether the error includes page markup or a sign-in prompt, but don't upload the entire response. If you see access denied or an authentication error, check your account status and subscription source first. Client support for configuration formats varies; use the panel entry designed for your current client.

If the update succeeds but the route list looks wrong, check the active configuration

After a successful update, the client may not automatically switch to the newly imported configuration. Check the active configuration name and update time, and confirm that the route list came from the source you just updated. If multiple configurations appear, identify which one you're testing before connecting. Custom rules, manual edits and external overrides can also affect the result. Save those changes, then compare against the unmodified configuration from the panel. Don't overwrite all your existing settings before identifying the cause, especially if you've maintained your own app-routing rules.

Monthly subscription traffic resets each month based on the activation date, not the calendar month. Mid-cycle upgrades are prorated for the remaining days; check the panel for your specific status. Data packages don't expire and remain available until used, but “never expires” doesn't mean usage is unlimited. If connection issues may be related to traffic, check the billing details on the Plans page, then review your current allowance in the panel. Upgrading isn't a general fix for DNS, permission or configuration parsing errors, so avoid unnecessary changes while the cause is unknown.

If you still can't update after getting a fresh link from the panel, submit the client name, platform, exact error, time of occurrence and a screenshot of the panel status. Hide the full subscription URL, access tokens, username and other unnecessary details. You can say “copied and imported from the panel”; there's no need to include the link itself in the ticket. If you think the URL has been exposed, reset it using a panel feature if available and reimport it on trusted devices. If you aren't sure how to reset it, ask support about the secure process first.

Troubleshooting flow: Is the panel status correct? → Is the source trusted? → Can the update request reach it? → Is the returned format compatible? → Is the correct configuration active? Handle connection issues separately from account issues. Keep the old configuration so an import problem doesn't turn into lost settings.

An app won't use the proxy: check traffic handling and routing

If your browser works but one app doesn't, at least one path through your connection is working. Focus on whether the app's traffic reaches the client, which rule it matches and whether the target service rejects the current route. Apps may have their own proxy settings, DNS behavior or background components. Loading a regular webpage in one window doesn't mean every request from the app takes the same path. First identify what's failing: sign-in, content loading, downloads, push notifications or a persistent session.

The system proxy doesn't cover every app

A desktop system proxy is a network setting apps may use, depending on how they're built. Browsers usually respect it, but some command-line tools, background services and specialized network components may use separate settings. If the client offers virtual network adapter mode, you can compare it after understanding its permissions and scope; it's a separate setting from the system proxy. Save your original configuration and make sure it won't conflict with business network tools or another VPN configuration. Don't treat switching modes as a permanent fix; first check whether the affected request now appears in the logs.

If the app has its own proxy settings, check whether they still point to a local address used by an old client. If the old tool has quit but the app still sends requests to its proxy, only that app may be unable to connect. Use the address and settings provided by your current client; don't copy a fixed port from the internet. If the app doesn't need its own proxy, restore its system settings and restart it. Background processes may retain old settings, so make sure they're fully closed after exiting the app window.

Check rule matches against the actual request domain

A target service often uses multiple domains for sign-in, static resources, content APIs and downloads. Adding a rule for the homepage alone doesn't prove the other requests take the same route. Use the client's connection list to inspect requests generated by the failed action, then check the matched rule and final route. If one resource goes direct while other requests use the proxy, check rule coverage and priority. Don't permanently send every request through one route to fix a single domain, especially local-network and internal business resources.

A temporary global proxy test can help identify a rule issue. If rule mode fails but global mode works, check your routing rules. If both fail, investigate the target service, account status or exit restrictions. Success in global mode doesn't guarantee that an app will keep working; regional policies, sign-in status and the target service's risk controls may still affect results. Restore your usual mode after testing and check that services meant to connect directly still work. Avoid fixing one app at the expense of other tasks.

Separate development tools from command-line environments

AI coding tool extensions, editor background processes and terminal commands may use different network environments. To test from a terminal, first check for leftover proxy environment variables. They may come from an old tool, a startup script or workspace settings. The commands below display variables without changing system settings. Output may include a local proxy address or authentication information, so inspect it only on your own device and redact each sensitive item before sending a support ticket. Never publish your full terminal environment.

# macOS / Linux: Check the current terminal's proxy environment variables
env | grep -i proxy

# Windows PowerShell: Check proxy-related environment variables
Get-ChildItem Env: | Where-Object { $_.Name -match 'proxy' }

Containers, remote development environments and subsystems may also have separate network boundaries. A local proxy address available on the host may not be accessible from these environments; a loopback address in a remote environment points back to that environment itself. Follow the relevant tool documentation rather than copying desktop browser settings. First identify where the request actually originates, then check whether it passes through the current client. For development route selection, see the guide to accelerating AI coding tools.

If a streaming service or another region-dependent service shows a message, keep the exact wording and distinguish network failures from regional availability or account issues. A successful network connection doesn't grant access to a service, and changing routes doesn't change the service's own rules. If the logs show that the request reached the client and used the expected route but a specific app still fails, submit the app action, target domain, matched rule and redacted error. This helps support distinguish app traffic handling from route access and third-party service policies; you don't need to share full account credentials.

Platform differences and device-limit alerts: check permissions and configuration ownership

If the same subscription behaves differently across devices, compare platform permissions, client settings and local networks before suspecting a device limit. VPNYD supports unlimited simultaneous devices on Windows, macOS, iOS, Android and Linux. If an interface reports “device limit reached,” first identify where the message comes from: the VPNYD account panel, a client, the target app or another network service. Different services have different device rules. Don't mistake a third-party app's sign-in limit for a VPNYD connection limit.

On desktop, check traffic-handling permissions and startup order

On Windows, check whether the current client successfully enabled the system proxy or a supported traffic-handling mode and whether all required permissions were granted. If multiple tools launch automatically, the one that starts last may overwrite another tool's proxy settings. For testing, leave only the current client active and verify an actual request in your browser. If basic internet access also stops after quitting the client, check for a leftover system proxy; don't delete network adapters or edit system registry settings. Restoring the relevant setting in the client is usually easier to undo than a broad system reset.

On macOS, check network extension authorization and the active VPN configuration. After a system upgrade, device migration or client change, old permissions and configurations may remain. Identify the configuration created by the current client and manage it in system settings; don't delete every network item in bulk. Organization-managed devices may restrict network extensions. If you see a restriction, check with your administrator. After making changes, test a browser and the affected app to confirm that traffic handling actually works, not just that a toggle looks different.

On mobile, check configuration, background behavior and network changes

On Android, distinguish VPN authorization from background permissions. The former allows system-level traffic handling; the latter can affect continued operation while the screen is locked. Some devices also have separate app network and battery settings; check the options on your device. On iOS, confirm that the configuration belongs to the current client and that no other network profile is changing the request path. If a mobile issue only occurs in the background, return to the Background Disconnects section. Reimporting the subscription repeatedly won't fix a system lifecycle issue.

For a device-to-device comparison, connect both devices to the same local network and use the same up-to-date configuration and a route in the same region. If desktop works but mobile doesn't, check mobile permissions and settings. If switching networks fixes the issue on one device, investigate the access network. If all devices fail on just one route, investigate that route. Don't change both client and route during the comparison, or you won't know which change helped. You don't need to sign out other working devices; VPNYD supports unlimited simultaneous devices.

Linux and device alerts: know what to troubleshoot

On Linux, desktop proxy settings, terminal environment variables and background services may each take effect separately. A graphical client can show connected while a terminal app uses its own environment; a background process can be running while desktop apps ignore the proxy settings. First identify the environment the failing app runs in, then check the relevant traffic-handling scope. For virtual interface or route permission errors, follow the current client documentation rather than running system-modification scripts from unknown sources. Keep the original settings so you can restore your network if needed.

Keep the full context for any device-limit alert. If it comes from a third-party app, follow that app's account rules. If it comes from a client, check whether you're using a different subscription or external configuration. If the VPNYD panel shows an alert that conflicts with unlimited simultaneous devices, submit a screenshot, where it appeared and what action triggered it. Don't infer a hidden device limit or treat signing out of other devices as the official fix. Account status, available traffic and device limits are separate checks; verify them individually.

For platform-specific steps, see the Guides page. For Windows installation and startup settings, see the Windows Setup Guide. Get clients only from the access link in the account panel; don't use unfamiliar installers. If permissions are confirmed and the default configuration has been tested but only one device still has an issue, highlight the device differences and comparisons you've already made in your ticket instead of submitting screenshots of every working device.

Support tickets and follow-up: turn symptoms into actionable evidence

The goal of self-checks isn't to make users responsible for all network maintenance. It's to make the boundaries of the issue clear. Submit a support ticket if your basic network works, the subscription is active, the default configuration is readable and connections still keep failing. It's also appropriate to contact support if the same route issue occurs across multiple devices and networks, or the panel clearly disagrees with your order status. Don't keep changing system settings just to “try one more thing”; each change makes it easier for new configuration problems to obscure the original issue.

Start with the symptom, then describe what you compared

Submit the issue through the support ticket section in the account panel. Start with one sentence describing the symptom, such as “Browser works, but editor autocomplete requests fail” or “The connection toggle turns off after screen lock.” Then include the time and time zone, operating system, client name, local network type, selected route and exact error. If an app is involved, say whether sign-in, page loading, downloads or a persistent session failed. Include the device model only if its behavior is relevant; there's no need to list unrelated hardware details.

Record only the comparisons you actually performed: Did direct access work with the connection off? Did switching networks on the same device help? Did changing routes on the same network help? Did another device reproduce it? Did the default and custom configurations behave differently? Clearly mark tests you haven't done; don't fill in gaps with guesses. For intermittent issues, describe the steps leading up to the latest occurrence and keep the log timestamp. Support needs a reproducible sequence, not a blanket conclusion that “everything is broken.”

Keep only the necessary information in screenshots and logs

Include the error, current status and relevant settings in screenshots, but hide your username, full subscription URL, access tokens, payment account and other unnecessary information. Include only the relevant log lines from before and after the issue, with timestamps, error type, target domain and rule-match details. Don't upload a full configuration file or unchecked environment output. Files may contain proxy credentials, subscription links or internal network addresses; inspect each item before sending. Don't redact the error itself so heavily that it can no longer be used as evidence.

If your logs contain real credentials or a subscription link, don't forward them through ordinary chat to ask for help. Stop sharing them and use the panel's available feature to secure the link. If you're unsure what to do, tell support in a ticket that there may be an exposure risk without pasting the sensitive content again. Keep ticket details relevant to the issue: third-party service passwords, payment credentials and full browsing history aren't routine troubleshooting materials. Support can request any additional information needed, which you can review before sharing.

Ticket checklist: symptom; date, time and time zone; platform and client; local network and route; exact error; comparisons performed; redacted screenshots or logs. Don't include the full subscription URL, password or access token.

Close the loop by verifying the suggested fix

Before following a suggestion, record your current settings and the issue that remains. After each change, repeat the action that originally failed and check whether it actually works. If the client icon says connected but the app still fails, report that accurately. After recovery, test a directly accessible website, the affected app and sleep or screen-lock scenarios to make sure the fix hasn't caused another issue. If global mode, a fixed route or disabling background restrictions was only for diagnosis, restore a configuration suited to everyday use as advised.

If the issue isn't resolved, add your results to the original ticket to keep the evidence in one place. Say which suggestion you tried, what changed and whether a new error appeared instead of replying only “still not working.” If the issue recurs only at certain times, add the relevant comparison records. With intermittent failures, one successful request doesn't prove the root cause is gone. Repeat the original trigger and check the relevant conditions, such as foreground or background use and network switching.

Check billing separately from network issues

Network troubleshooting doesn't replace account and billing checks. Monthly plans: ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data packages: ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they never expire and remain available until used. See the full pricing details to review plans. Payment methods: Alipay, WeChat Pay and USDT. A larger data package won't fix every app issue, and one route problem doesn't mean your entire plan is invalid.

VPNYD offers a 14-day no-questions-asked refund. See the Terms of Service for usage and refund rules. For order status, refunds or plan changes, mark your ticket as a billing issue and include only the necessary details from the relevant panel record. If you're still learning the full setup process, read the Complete VPN Beginner's Guide. For quick answers, visit the FAQ. This handbook helps pinpoint issues; test results aren't promises of speed, regional access or long-term availability.