VPN Troubleshooting Guide

Can’t connect: identify where the problem occurs

“Can’t connect” might mean the client won’t sign in, the subscription list is empty, the connect button shows an error, or a website simply won’t load. These issues occur at different layers. Note the last step that worked: Can you open the account panel? Do you see the available routes? Does the status change after you tap Connect? That tells you whether to check the account, configuration or network next. Don’t delete the client just because you see a red icon; reinstalling can erase useful error records.

Check your network and account first

Disconnect the client temporarily and check whether regular websites load. Public Wi-Fi may require you to confirm access in a browser first. Until then, the client may appear online while only the network sign-in page is reachable. If regular internet access is also down, troubleshoot your Wi-Fi, router or network access first. If another network is available, compare results on the same device, but don’t sign in to your account or save your subscription on a public device.

Next, open Account overview and check your current plan, remaining data and subscription status. Closing the payment page doesn’t mean the order went through; check the status shown in your account panel. Switching routes usually won’t help if your subscription has expired or you’ve used all your data. VPNGain monthly subscription data resets each month on the activation date, not on the first of the month. Data add-ons don’t expire and remain available until used, so make sure you know which type you’re using.

Distinguish permission errors from connection timeouts

If an error appears as soon as you tap Connect, check whether the system blocked the client from creating a VPN configuration, starting a network extension or enabling a virtual network adapter. If you previously denied a permission request, check the relevant permission in system settings. Grant elevated permissions only when the client specifically asks for them; running it with elevated privileges all the time isn’t a general fix. Organization-managed devices may restrict network extensions, so check with your device administrator rather than trying to remove management policies yourself.

If the status stays on Connecting and eventually times out, note the route name and time, then compare it with a different route type. Changing regions and changing route types aren’t the same thing: different entry points in the same region may use different paths. See the route list for route types. One route failing and all routes failing point to different causes, so avoid describing either situation vaguely as “the whole service is down.”

If every route fails, check for other VPNs, system proxy tools or network-filtering software running at the same time. Exit those tools normally, make sure their background services have stopped handling network traffic, then test VPNGain. Don’t disable all system protections. If the logs identify a specific block, check permissions only for the client program in question and restore the original settings after testing.

Use comparison results to choose what to check next

If the same device works on a different network, the issue is related to the original network environment, but that doesn’t tell you whether the cause is the router or the ISP’s route. If other devices work on the same network, focus on permissions, leftover proxies and configuration on the affected device. If all devices fail, first check whether they share the same expired subscription or entry point; a shared result doesn’t necessarily mean the same hardware is at fault.

If the client reports a certificate or secure connection error, first check that the system date, time and time zone are correct, and that automatic time sync uses a trusted source. Don’t disable certificate validation or install certificates from unknown sources just to make a connection work. An incorrect clock, a network sign-in page and local filtering software can produce similar errors. Check the original error text instead of guessing from a message on the web page.

Submit a support ticket if your network is working, your account is active, permissions are in place, and different route types keep failing across multiple networks. Include the stage at which the failure occurs and the comparisons you’ve already made. Reinstalling or clearing the configuration repeatedly is unlikely to help at this point and may make the issue harder to reproduce. If service returns temporarily, note what changed before and after so support can tell whether the cause was a configuration or network change.

Connected, but websites won’t load: proxy and DNS

A Connected status usually means the connection process completed; it doesn’t guarantee that your browser’s requests are using the connection. Web access also depends on system proxy settings, routing rules, DNS resolution and the destination server’s response. Try opening a regular website and the one that failed, then note whether all sites fail, one domain fails, or text loads but images don’t. Different symptoms call for different checks.

Check whether requests are actually going through the client

On desktop systems, connecting to a route and enabling the system proxy may be separate actions. Check that the client is using the intended proxy or tunnel mode, then check whether your browser uses system settings. Some browser extensions override the system proxy, and work profiles may have their own policies. You can temporarily disable known proxy extensions to compare results, but don’t clear all browser data; that also changes sign-in status, cache and extension settings.

Check the client logs for a request when you reopen the affected website. No log entry may mean the app isn’t using the proxy, or simply that the current log level doesn’t show that type of event; an empty log alone isn’t conclusive. If a request matches a direct-connection rule, see the app routing section. If it was sent through the selected route and timed out, the route or destination server is a more likely cause. The rule name is more useful than a screenshot of a connection icon.

Tell DNS resolution failures apart from destination blocks

DNS translates domain names into addresses. If your browser says it can’t find the server or the name couldn’t be resolved, check DNS. Messages such as access denied, region unavailable or verification required usually mean the destination responded, so don’t treat them as DNS errors. If only some page resources fail, images, sign-in or media may be using different rules. Check the specific failed resources rather than testing only the homepage domain.

First check whether your system still has an old manual DNS setting and whether the client handles DNS. Browser secure DNS, encrypted DNS in the system and client DNS may each use different paths. Don’t enable several resolution options whose effects you don’t understand. Restore the client’s default option first, then test the browser’s separate DNS setting on its own. Record the results before and after each change, and keep the configuration that you verify works.

The commands below only inspect local DNS and proxy status; they don’t change configuration. Replace the test domain with the domain that’s actually failing, and never put a subscription URL in a command. A successful lookup only means the system resolved the name that time. If your browser uses its own DNS, it may get a different result. Linux DNS tools vary by distribution; if a command isn’t available, check your system documentation rather than installing an unknown script.

# Windows: check DNS resolution in Command Prompt
nslookup example.com

# macOS: view system DNS and proxy settings in Terminal
scutil --dns
scutil --proxy

# Linux systems using systemd-resolved
resolvectl status
resolvectl query example.com

Cache, IP versions and certificate issues

After changing settings, old DNS cache entries or reused connections may temporarily preserve the previous result. Close the affected tab and reopen the app before considering the system’s cache-refresh option. Clearing the cache isn’t a fix for every website problem. If a system lookup succeeds but the browser still shows an error, compare with a clean browser session to distinguish browser cache or extensions from system network settings.

Some environments use more than one IP version, and an app may prefer a path that doesn’t match the tunnel configuration. Check the client’s documentation for how it handles system traffic and DNS. Don’t permanently disable system networking as a default workaround. If you see a certificate name mismatch or certificate chain error, stop entering account details and check the system time and any network sign-in page. Disabling certificate checks can hide a real secure connection problem.

For a DNS support ticket, include the failed domain, the browser’s exact message, the system lookup result and whether the browser’s own DNS is enabled. Don’t send your full browsing history. If the same destination shows the same service message across different networks and routes, the destination may be imposing its own restrictions. See our streaming access guide rather than mistaking an account-region rule for a client issue.

Slow speeds and peak-hour slowdowns: compare like with like

“Slow” can mean a page takes a long time to load, downloads are slow, video keeps buffering or interactions feel delayed. These symptoms can have different causes, including DNS resolution, route congestion, the destination server or the app itself. Start by describing what action is slow instead of relying on a speed test. Speed-test servers differ from the services you actually use, so a change in the result doesn’t directly reflect how websites, streaming platforms or AI tools will perform.

Keep test conditions consistent

Choose a task you can repeat, such as opening the same page, playing the same clip or sending the same type of request. Keep the device, network, destination and client mode the same; change only the route. Watch for other activity during the test, such as system updates, cloud syncing or downloads on other devices. VPNGain supports unlimited devices, but devices on the same subscription share plan data, and adding devices won’t increase your local internet bandwidth.

Wi-Fi quality affects all cross-border tests. If you’re far from the access point, the signal is obstructed or the network is busy, switching routes may only make an occasional difference. Check whether regular browsing is also slow from the same location. If possible, compare using a stable wired connection. The Wi-Fi link speed shown on your device isn’t the same as your actual browsing speed; it describes a different part of the connection from the remote service.

Choose a route by type, not just distance

A nearby location isn’t necessarily the best choice for your current network. IEPL, relay and direct routes use different paths, and performance still depends on whether the entry point is reachable, how the exit connects to the destination, and current network conditions. Compare route types that meet the destination’s regional requirements before choosing a regular route. Don’t prioritize a nearby city over the platform’s region requirements. See route coverage and types for examples.

To investigate peak-hour slowdowns, compare the same conditions at different times rather than combining tests from different devices. Note when it starts slowing down, which network and route you’re using, and whether regular websites are affected too. If every route slows down on the same network, look at your local connection first. If only some entry points are affected, keep a working route for comparison so support can narrow down the issue to the entry or exit path.

Understand how video and long-lived connections behave

A video starting smoothly doesn’t guarantee it will stay stable. A player may use buffered content at first, then reveal that the connection can’t sustain the required throughput. Changing resolution or restarting playback also changes the buffer. Note the actual resolution, whether buffering starts only after seeking, and what happens on a different route to the same destination. Don’t assume every streaming platform will be accessible, and don’t confuse a playback restriction with slow buffering.

AI completions, online meetings and command-line tasks rely more on persistent connections. A website may load while a long-running task still gets interrupted. Repeatedly switching exit routes may also trigger new verification from the destination. Choose a route that can complete the task reliably instead of chasing speed-test results mid-task. For development workflows, see choosing routes for Cursor, Copilot and command-line tools, and use app logs to identify where the request stalls.

Don’t change concurrent connection settings, transport parameters and system network settings all at once to “speed things up.” What these options do depends on the client, and blind adjustments may increase packet loss or make the issue harder to reproduce. If logs show a clear packet-size-related error, start with the client’s default settings and ask support to review it. Parameters copied from elsewhere may not suit your device or network.

Submit a speed-related ticket if your network is stable, other activity has been ruled out, and the same type of task remains slow on a particular route at particular times. Include a working and failing comparison; there’s no need to repeat large downloads that use a lot of data. Choose a plan based on your data needs, not assumed speeds. Check current allowances and billing rules on the plans page.

Frequent disconnects and mobile apps closing in the background

First determine whether the connection itself dropped or the app’s session ended. If the client shows Not connected or the system VPN indicator disappears, that points to the connection layer. If the client remains connected but a video stops or an AI request is interrupted, also check the destination service and app logs. Record separately whether it fails only after you leave the app or also while it stays in the foreground. This helps determine whether background management is the priority.

Look for what triggers the disconnect

Note whether the disconnect followed a Wi-Fi change, entering an area with a weaker signal, locking the screen, closing a laptop or enabling power-saving mode. A network change alters the existing connection path, and the client may need to reconnect; an app’s existing session may not resume automatically. If it happens only when switching networks, check whether auto-reconnect is enabled and what it does before assuming your subscription has expired.

After a desktop device wakes from sleep, the virtual network adapter, system proxy and client status may be briefly out of sync. Check whether the client reconnects, then reopen the app you were using. If regular network access is also affected, check the system’s network status. Don’t immediately remove the virtual adapter or reset all network settings; this can affect other programs and temporarily disconnect a device used for remote work.

Check Android background activity

In Android app settings, check battery management and background activity permissions for the VPNGain client. Names such as “Unrestricted” and “Allow background activity” vary by device, so follow your system’s instructions. Change only settings related to the client; don’t disable the system’s entire power-saving feature. Afterward, test with the app in the foreground, while using another app and with the screen locked to see whether the difference is resolved.

Some systems close apps when clearing tasks; others close only the app window and keep the VPN service running. Don’t use the presence of an app card in the task switcher to decide whether the service is active. Check the system VPN status and client logs instead. If automatic cleanup, a work profile policy or a separate security app is enabled, check whether it restricts background networking. Follow the administrator’s instructions on managed devices.

How iOS and desktop systems differ

On iOS, the VPN connection is typically maintained by a system network extension, so sending the app to the background doesn’t necessarily disconnect it. Check the VPN status in system settings and whether another configuration is taking over the connection. Don’t delete every profile to troubleshoot; some may be for work. If the client offers on-demand connections, make sure the rules suit your current network and note that they may behave differently from a manual disconnect.

If the connection also drops during continuous foreground use, check whether it happens only on one route or repeatedly on every route on the same network. Note whether regular browsing is affected when it disconnects. A brief network outage, a client process exiting and a remote connection reset can all end with a “Disconnected” status, but the logs show different event sequences. Save the relevant section around the disconnect; you don’t need to upload a full record of routine activity.

Auto-reconnect can try to restore the route, but it can’t guarantee that the destination app will resume its task. Uploads, terminal commands and online editing may need the app to recover or you to restart the task. For important work, check whether the app can save drafts, resume transfers or retry. If the client reconnects but the task still fails, restart the app session before switching routes again and adding more variables.

Submit a support ticket if the issue remains reproducible after checking background permissions, or if the client exits on its own or the network extension repeatedly restarts. Include comparisons between foreground and background use, what you did just before the disconnect, whether the system still showed a connection, and whether you had to reconnect manually or restart the app. If there’s a crash report, check it for local paths and account details before sharing only the relevant section.

Subscription update failed: check the source and response

Updating a subscription and connecting to a route are separate processes. The client may still use an old configuration but fail to fetch new content, or it may download text successfully but fail to parse the configuration. Read the error carefully: fetch failed, authentication failed, empty response and unsupported format point to different issues with the network, account, response or client compatibility. Don’t paste your full subscription URL into a public forum just because an update failed.

Make sure the subscription belongs to your current account

Open the subscription section in the account panel and check the signed-in username and plan status. VPNGain doesn’t require an email address; you can get started with a username and password. Keep your username somewhere safe so you don’t confuse accounts in different browsers. Don’t rely on browser autofill to identify the account you’re using, and don’t use another account’s subscription as a temporary fix.

Use the import option supported by your client and choose the format intended for it. When copying manually, check for extra spaces, line breaks or truncated parameters. Examples should use a dummy value such as https://example.com/sub?token=YOUR_TOKEN; keep your actual address between your account panel and your own client. Don’t use a conversion website from search results to process a real subscription.

If you changed account details in the panel or generated new subscription credentials, the old address may no longer work. Use the current address shown in the panel. Before replacing it, note the old configuration’s name and mode. Remove the old entry only after confirming the new one imports successfully. Don’t switch back and forth between old and new entries and lose track of which is active; that can make the route list and update status appear inconsistent.

Tell fetch failures apart from incompatible content

If fetching fails, first check whether the account panel opens and whether the current network requires an access confirmation. Some clients let you fetch updates directly or through an existing proxy. Start with the default behavior and compare only if logs clearly show that the fetch path is unreachable. If the old connection has stopped working but you force update requests through it, you may create a loop that can’t recover on its own. Adjust the fetch path according to the client’s instructions.

If the logs say the response isn’t the expected configuration, you may have received a sign-in page, network access page or error response. Don’t paste your subscription into a public website to inspect it. You can give support the response type or a redacted error summary. Receiving content doesn’t mean it’s valid, and opening an address in a browser doesn’t mean the client can use it as a configuration.

If parsing fails, check that you’re using the import method provided for your client in the account panel. Clients can differ in their support for rules, transport options and extra fields; a file extension alone doesn’t prove compatibility. If you’re using a custom template, save a copy and compare it with a separate configuration created from the original subscription. Don’t delete fields that trigger errors and keep using the result without checking; this may unintentionally change parsing, routing or security behavior.

Update succeeded, but the list didn’t change

Make sure you updated the selected configuration, not a backup with the same name. A client may store several subscriptions: the route list shown belongs to the current configuration, while the update action may apply to another entry. Also check region filters, favorites and search terms; the routes may be there but hidden by a filter. Clear filters, then check the configuration’s last update time and error log instead of repeatedly reinstalling the app.

Don’t assume existing connections automatically switch to new rules after an update. Some clients need you to reload the configuration or reconnect; follow the on-screen instructions. Custom rules may also override subscription content and preserve an old selection. When troubleshooting, distinguish the original subscription, your personal overrides and the active connection so you don’t mistake the effect of an override for a failed server update.

Reimporting won’t solve an insufficient data allowance. Check the difference between monthly subscriptions and data add-ons on the plans page, then confirm your status in the account panel. If you upgrade partway through a billing period, the price difference is converted into remaining days; don’t use local dates to guess when the change will take effect. If the payment and subscription statuses don’t match, provide the order ID in a support ticket rather than submitting the same order repeatedly.

Contact support if the account panel is working, the import format matches your client and the default configuration still fails. Say whether the first import failed or an update broke a configuration that used to work. Include the exact error, platform and comparison of fetch paths. If it fails only with a custom configuration, make that clear so support can check compatibility before repeating account-status questions.

An app isn’t using the proxy: check routing

If your browser works but one app doesn’t, the route as a whole probably isn’t the first thing to blame. The app may not read system proxy settings, may have its own proxy setting, or may send sign-in, content and media requests to different domains. First identify whether the failure happens at startup, sign-in, content loading or during use. Then check whether the client receives the app’s requests. “This app doesn’t work” leaves out the access path that matters most.

Understand system proxy and tunnel modes

A system proxy provides an entry point for apps that use system settings; it doesn’t automatically cover every program. Tunnel mode uses system networking features to handle a wider range of traffic, but can still be affected by routing rules, permissions and platform behavior. Don’t assume “Global” mode means every app takes the same path. In some clients, “Global” refers only to how rules are selected. Check the current mode to understand what it actually covers.

First check whether the app has its own proxy option, network extension or work-profile setting. If it does, make sure it isn’t still pointing to an old proxy that has been shut down. Note the original setting before changing it so you don’t break another work environment while fixing this app. Don’t copy a local port number from a guide online. Get the listening address, port and proxy type from the running client, and confirm the app supports that type.

Use logs to check rules and domains

Repeat the failing action once and check the relevant logs by time. If the request matches a direct-connection rule, check the domain category and any personal override rules. If it matches a proxy rule and uses the expected route, check the destination’s response. Sign-in pages and content APIs may use different domains, so opening the homepage doesn’t prove the whole app works. Checking each failed resource is more informative than changing the entire system to use one proxy.

If the app uses its own DNS or caches addresses for a long time, rules may not recognize the destination as expected. Fully quit and restart the app, then check the DNS path in the DNS section. Don’t hard-code a single address into a rule; the destination may change it. If you need a temporary rule, note whether it matches a domain, process or address, and keep a way to restore the defaults.

A browser private session can help compare extensions and session state, but it doesn’t automatically remove the effect of the system proxy. If private browsing works but your regular session doesn’t, check extensions and site cache first. If both behave the same way, check the system or route. For destinations that require sign-in, distinguish a failed network request from insufficient account permissions; switching exit routes repeatedly won’t fix a clear account-related message.

Separate environments in command-line and development tools

Terminals, editor plugins and graphical apps may inherit different environment variables. A proxy variable set earlier in a terminal may still point to an old client, while an editor launched from the desktop may not read the terminal’s environment. The commands below only display proxy variables in the current environment; they don’t set any addresses. If the output includes an address with authentication details, hide the credentials before sharing it. Don’t upload all environment variables.

# macOS / Linux: view common proxy environment variables
printenv HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
printenv http_proxy https_proxy all_proxy no_proxy

# Windows PowerShell: list environment variables with proxy in the name
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

After removing unused variables, restart the relevant terminal or app; existing processes usually retain the environment they started with. Containers, remote development environments and virtual machines have their own network spaces, so the host’s local proxy address may not work inside them. Don’t expose a local proxy to your entire local network just to connect them. First check the client’s access scope and your device’s security settings.

Streaming and AI tools may also restrict content based on account region, payment region or their own service rules. If the destination clearly returns a region or permission message, the network connection itself may be working normally. VPNGain provides cross-border connectivity; it can’t provide eligibility for another service’s account or guarantee access to every platform. Check the destination’s official guidance before deciding whether a different route is needed.

If only one app consistently fails with the default configuration, include its name, platform, stage of failure, whether it uses a separate proxy and the browser comparison in your ticket. For AI development workflows, see our guide to accessing coding tools. If the request reached the destination and returned an application-level error, check the account and feature requirements with that service first.

Device warnings and system configuration conflicts

VPNGain supports unlimited simultaneous devices. So if you see a “device limit exceeded” message, don’t assume VPNGain requires you to disconnect devices. First identify whether the warning came from the VPNGain account panel, the client’s local configuration, a device management policy or the platform you’re trying to access. Different sources can use similar wording. Include the app name and surrounding context in a screenshot, and hide account and subscription details.

Unlimited devices doesn’t mean unlimited data on each device

Unlimited devices doesn’t give each one a separate data allowance, and it doesn’t remove session limits imposed by other platforms. Devices on the same subscription share plan data. Streaming, development and work platforms can still restrict sign-in environments under their own rules. If the warning comes from the destination app, check its account guidance. Don’t mistake that platform’s device management page for a VPNGain device list or delete all sessions to see what happens.

If the warning appears during a VPNGain connection, save the exact message and check where the current configuration came from. An old subscription, configuration from another service or duplicate entry may cause confusion. Confirm the account and configuration name in the account panel, but don’t switch accounts or pay again. If the warning conflicts with the unlimited-device policy, ask support to investigate rather than guessing that an unpublished device limit applies.

Where to check for platform conflicts

Common Windows conflicts include a leftover system proxy, background services from other networking tools and an incorrectly configured virtual network adapter. Disconnect from the client normally first, then check whether the system proxy returns to its expected state. Company devices may use automatic proxy scripts; don’t delete them without checking. Before resetting network settings, record the existing configuration and make sure it won’t affect work access. Don’t do this casually on a device you rely on for remote access.

On macOS, distinguish proxy settings in network services from system network extensions and app-specific proxies. When several tools have run in sequence, closing their windows doesn’t necessarily stop their extensions. Check which items are allowed to run in system settings, and use each tool’s own exit option to stop its service. If extension permission fails, follow the system prompt. Don’t lower system security settings as a substitute for granting the right permission.

On Linux, desktop proxy settings may not affect the command line, and the network manager may override manually edited routes or DNS files. First identify which service manages the current network, then check how the client is started and what permissions it has. Don’t edit system files, set environment variables and switch network managers all at once. These changes can override one another, making it hard to tell what actually fixed the issue.

On mobile devices, work and personal profiles may use different network policies. An app failing in a work profile doesn’t mean all traffic on the device is affected. Also check whether another VPN or system-level filtering service is competing for the connection. Keep necessary configurations in place; don’t delete organization-managed settings to test. Compare results in a personal profile where permitted, and ask an administrator about management restrictions.

Make changes you can undo

Before making system-level changes, note the original proxy mode, DNS settings and client configuration name. Save a screenshot of only the options you may need to restore, and hide sensitive fields. After each change, immediately test the action that originally failed. Continue only if it helped. If nothing changed, restore that setting so you don’t end up with several unverified adjustments that make the next issue harder to diagnose.

If security software reports a block, first confirm that the program came from the client download page in your account panel, then check what was blocked and why. Don’t install drivers from search ads or unfamiliar file-sharing sites, and don’t leave all protections disabled. The client and subscription are available after signing in. On platforms other than iOS, sign in to download; eligibility for iOS downloads is handled through the account panel.

If you confirm a system conflict but can’t resolve it, provide the platform, client details, current mode and the conflicting item you verified. For a device-limit warning, include the screen where it appears rather than only paraphrasing it. Support needs to identify where the restriction originates before deciding what to do. Adding a plan or repeatedly importing the subscription usually won’t fix the underlying issue if the source is unknown.

When to contact support: prepare your records and ticket

Contact support through an account panel support ticket if the issue is persistent and reproducible, your account and order statuses don’t match, the default configuration still won’t parse, or the client repeatedly crashes. You don’t have to complete every check before asking for help, but explain how far you got. A clear description and useful comparisons usually take fewer follow-ups than “it doesn’t work.”

Share the minimum details needed to reproduce the issue

Include when the problem happened and the time zone, along with the platform, system and client details, network type, selected route and proxy mode. Get system and client details from the device rather than guessing. Then describe what you expected and what actually happened. “The client disconnects when I switch to the background” and “the client stays connected but the app shows an error” are different issues.

Write the steps in an order someone else can repeat: the starting state, the action you took, the message that appeared and how you recovered. If the issue is intermittent, note whether you switched networks, locked the screen or resumed from sleep. Don’t fill in steps you didn’t observe just to make the report look complete. It’s fine to mark something as unknown; confident but inaccurate details are more likely to mislead troubleshooting.

Keep the conditions clear when reporting comparisons. Say whether the same device worked on a different network, the same network worked with another route, and the same route worked with another app. State which single factor you changed each time. Results from different days, locations or devices aren’t strict comparisons, but may still help if you identify what changed. Keep a record of the issue even after it’s resolved so you can compare if it returns.

How to redact logs and screenshots

Share only the relevant log lines around the error, keeping the event sequence and full error text. Hide subscription addresses, QR codes, credential parameters, payment details and unrelated account information. Request logs may include domains you visited, and local paths may reveal your device username; review each item before sharing. If you’re not sure what’s safe to upload, start with an error summary and provide more only when support asks for it.

Don’t send a screenshot of just a red icon or upload your entire desktop. Include enough to show the program name, current status and where the error came from. If the screen includes a subscription QR code, cover it before uploading. Redaction must cover the entire sensitive area; hiding only the middle may leave identifying details visible. Check screen recordings for browser tabs, notifications and autofill details too.

Use the outline below to organize your report and fill in what you actually observed. For a test you haven’t run, write “Not tested”; don’t do anything risky just to fill in a blank. If only one domain is affected, provide the domain, not a full URL with parameters that could expose session details. Add follow-up results to the same ticket to keep the context together.

Issue:
Date, time and time zone:
Platform, operating system and client:
Network type:
Route name and current mode:
Steps to reproduce:
Exact error message:
Result on the same device using another network:
Result on the same network using another route:
Settings changed and whether they were restored:
Relevant log excerpt:

Follow up and confirm the fix

Work through support’s suggestions one at a time and report what actually happened; don’t just reply “still doesn’t work.” If you can’t complete a step, say which screen you’re stuck on or what message appeared. Before remote assistance or system changes that require permissions, make sure you understand what they’re for. Don’t run scripts or commands you don’t understand. After the issue is fixed, restore any protections you temporarily disabled and any settings you changed for testing.

After the connection returns, test the task that originally failed instead of relying on the connect button’s status. Also check whether the connection stays stable after sleep, switching apps or updating the subscription. Note the working configuration and fix, but don’t store a full configuration with credentials in a public document. Keep a short summary so you can troubleshoot from what you’ve already learned if the issue returns.

Describe billing and technical issues separately. Plan allowances, prices and reset rules for monthly subscriptions and data add-ons are shown on the plans page and in your account panel. Payment methods: Alipay / WeChat Pay / USDT. VPNGain offers a 7-day refund guarantee; see the Terms of Service for full details. For billing assistance, include the order ID in a support ticket. Deleting the client doesn’t cancel an order or submit a refund request.

For a new use case, start with the FAQ. If you need to go through the full connection process again, return to Quick Start. This guide helps diagnose network and configuration issues; it doesn’t replace support from the destination platform, and repeatedly changing system settings to chase unverified results isn’t recommended. Keep records, change one variable at a time and make sure you can undo each change.