VPN Troubleshooting Guide

Network and connection basics

Can't connect at all? Start by narrowing down the issue

Describe the problem so it can be reproduced

First, distinguish between “the client won't launch,” “an error appears when I connect,” and “it says connected, but requests time out.” Each points to a different layer and calls for a different fix. Note the network, server and device state the last time it worked, then record exactly where things are getting stuck now. If you recently changed system proxy settings, imported a config or installed network software, note those changes separately. For now, avoid piling on more changes.

Disconnect the VPN and check whether websites that normally work load as expected. Also check whether your device has a network address. If regular websites won't load either, troubleshoot Wi-Fi, Ethernet, a network sign-in page or your router first. Public Wi-Fi may require you to accept its terms in a browser before you can connect. Switching servers before basic connectivity is restored usually just creates more timeouts; it doesn't tell you whether an international route is at fault.

Check your account, subscription and client status

Open Account Overview and check whether your plan status, remaining traffic and subscription details are available. A config may still appear in the client even if your account status has changed, so seeing a server list doesn't confirm that your account is active. If the dashboard won't open either, note that as a dashboard access issue rather than treating it as the same problem as a client connection failure.

Check whether the client has actually started its connection core and whether the system has granted the required network permissions. Server names in a list and a toggle on the app's home screen are just interface indicators. If the core fails to start, permission is denied or the config can't be parsed, requests never reach the route. Read the full error message and save a screenshot. Don't leave system protection disabled as a troubleshooting measure, and don't replace program files with downloads from unfamiliar sources.

Narrow it down by changing one variable at a time

Keep your current configuration, try another server, then test the original server on a different local network. Keep the target website the same and don't change the app, rules and network all at once. If only one server fails, the issue is more likely related to that route. If all servers fail on one network but work on another, check the local connection first. If they fail across different networks too, revisit your subscription, permissions and client-core errors.

Network tools running at the same time can compete for the system proxy, routes or virtual network interface. Check for another VPN, proxy tool or work network app, and if permitted, close anything unnecessary before testing again. On a managed device, follow your organization's policies and don't remove security software. After closing a tool, check whether it restored the system proxy; otherwise, it may still point to a program that is no longer running.

An incorrect device clock can cause certificate checks and secure connections to fail. Check that the date, time and time zone are reasonable, then see whether the error mentions a certificate or handshake. Don't choose to ignore verification or leave security checks disabled as a workaround. If the issue continues after correcting the clock, note the target, exact error and stage where it occurs so support can tell whether it's a local environment or connection-path issue.

When to stop troubleshooting on your own

If the logs keep showing an invalid config, a client core that won't start or denied permissions, cycling through servers won't help. Fix the local error first. On the other hand, if the core starts normally, the basic network works and your subscription is active, but connection timeouts recur across different networks, it's time to submit a support ticket. Comparing a server that fails with one that works is more useful than simply reporting that all servers are unstable.

Reinstalling shouldn't be your first step. Save redacted errors and note where the configuration came from first. Clearing the app may delete useful troubleshooting records and leave old system proxy settings behind.

Once the connection is back, return to your usual settings instead of keeping broad rules enabled for diagnosis. For an overview of server locations and route types, see the global server guide. If you haven't successfully imported your subscription yet, go back to the guide and check the setup steps. The goal is to find a reproducible cause, not to get lucky after a restart.

Requests, DNS and page loading

Connected but websites won't load? Check DNS and request handling

Check whether the problem affects every website or just one

Keep the current connection and try a website that normally works, followed by the site that's having trouble. If the first loads but the second doesn't, check the target region, app rules and the platform's status. If no websites load, check the system proxy, DNS and whether the client is actually forwarding requests. The browser's exact error matters: “server not found” points to DNS resolution, while “connection reset” points to the connection stage. Neither should automatically be dismissed as slow speeds.

Try the same site in another browser or a standalone app. If only one browser fails, check its extensions, proxy and secure DNS settings. If every app fails, the issue is more likely at the system or client level. Don't clear all browsing history and sign-in data at once. First try a new browser window to rule out some cache and extension issues. Once you know where the problem is, clear only the relevant site data so you don't introduce an account-session issue.

Check whether DNS returns a result

DNS translates domain names into network addresses; the connection process starts after an address is returned. Successful system-level resolution doesn't mean the client's own DNS is working. The client may use a separate resolution path, and your browser may have its own secure DNS. Check the current configuration and logs to see which component handles the request, then determine whether the result is empty, returns an error or points to an unexpected region. Don't compare results from different sources without keeping them separate.

nslookup example.com
curl -I https://example.com

The commands above are for environments that already have the relevant tools installed. The first checks the resolution path used by that tool; the second attempts to connect to a website and request its response headers. A successful result only shows that this test target is reachable; it doesn't prove every app is using the selected server. If the tools aren't installed, don't download unfamiliar software just for this test. Save the browser error and client DNS logs for support instead.

Don't treat security warnings as a network optimization option

If you see a certificate error, first check your device's clock and whether you're on a public network that requires sign-in. A network sign-in page can interfere with initial access and trigger an unusual certificate warning in the browser. Don't turn off certificate validation to see whether the site loads, and don't install certificates from unknown sources. Note the domain associated with the error, then try again on a working basic network to help separate a local connection issue from a problem with the destination site.

If the domain resolves but the page keeps waiting, check the client logs for a connection to the target and note which rule and server were used. If there's no record of the target, the app may not be sending requests through the client. If a request is logged but the connection fails, then check the route, destination address and transport. If the logs show a block or direct-connection rule, verify that the rule is behaving as expected before changing DNS to mask a routing issue.

System and browser caches may retain old results. Consider clearing the relevant DNS cache only if it keeps using an outdated address after a configuration change, and record what changed. Clearing a cache won't fix an invalid subscription or change a third-party platform's account region. System commands vary by platform. If you're unsure, use your system's network settings or a client-provided reset option rather than changing unrelated network settings.

Use the comparison results to choose your next step

Don't keep using DNS addresses entered at random during troubleshooting. Restore a supported configuration, test your usual apps again and check the request logs in the client. If the issue only occurs on a particular network, mention the type of network and whether it requires a sign-in page in your ticket. If the same DNS error occurs across networks, attach redacted logs. This helps support avoid repeating checks you've already completed.

Working DNS, a working connection and permission from the platform to access its service are separate conditions. If a site shows a regional restriction or account warning, check the app-routing section instead of repeatedly clearing the DNS cache.

Connection paths and real-world performance

Slow speeds and peak-hour lag: compare the connection path

Describe what “slow” means in practice

A slow first page load, video buffering, stalled file transfers and a delayed AI response aren't the same symptom. A webpage involves DNS resolution, connection setup and content requests. Video performance also depends on player buffering, the source and resolution. AI tools may be waiting on server-side processing. Note the specific action and where the delay starts instead of using a client connection test to explain the entire experience.

Pause ongoing downloads, cloud sync and large uploads on other devices or apps, then test the same target again. When a home network's upload capacity is in use, web requests can stall even if there's download capacity left. Check your Wi-Fi signal and the device's connection to the router. If possible, compare using a more stable local connection. If regular internet is also slow with the VPN disconnected, address the local network first rather than upgrading your plan.

Keep test conditions consistent when switching servers

On the same network, choose another server suited to the target region, keeping the app, content and rules unchanged. A server being geographically close doesn't necessarily mean the connection path is shorter. Local access, the route's entry point, transit path and destination service location all affect performance. See the server locations page for coverage details. The dashboard and client show which servers are actually available to you; don't infer bandwidth or quality from server names.

Route types can help guide your choice, but they don't replace testing them in practice. IEPL, relay and direct routes describe how a connection is organized, not how it will perform for every target, network or time of day. After switching route types, note whether the issue changes from constant buffering to playback starting, for example. Don't turn a one-time improvement into a lasting speed guarantee, and don't run several speed tests at once.

For peak-hour issues, record the time and compare networks

If things work during the day but repeatedly lag in the evening, note the time, local network and server, then test the same combination again the next day. Peak-hour congestion can occur on home Wi-Fi, with your local network provider, at a route's entry point or on the target platform. An evening slowdown alone doesn't tell you which part is responsible. If switching local networks helps, focus on the access connection. If switching servers helps, include that difference in your support ticket.

A video app may cache its previous region check or media connection. After switching servers, stop playback and reopen the same content. If needed, restart the app instead of cycling through many servers. Check whether the player is automatically changing video quality too. A change in picture quality doesn't necessarily mean you've disconnected, and constant buffering doesn't necessarily mean the platform is restricting your region. For more on catalogs and viewing conditions, see Disney+ regions and connection stability.

If an AI tool's website loads but responses are slow, check whether your request was submitted, whether the platform says it's processing, and whether other websites are slow too. If you're only waiting for generation, the cause may be service load, account status or the request itself; switching networks alone won't explain it. If the request never goes through or the connection drops, check the client logs and routing rules. For more context, see the AI guide.

Don't use a data allowance tier as a performance diagnosis

Monthly plans with different data allowances describe how much data is available; they don't imply different speed guarantees. Monthly data resets on the plan's activation date. Mid-cycle upgrades are prorated for the remaining days. Data add-ons remain available until used and never expire. If your account shows that you've run out of data, check your account status first. If you still have data but one target is slow, continue troubleshooting the connection path. See plan pricing for full prices and plan details.

Change only one condition at a time: the server or the local network. Keep the target, rules and action the same so any improvement after switching routes is useful troubleshooting evidence.

When reporting slow speeds, say whether the issue is constant or limited to certain times, and include a reachable target for comparison. A screenshot showing only the app's home screen doesn't show where buffering or delays occur. If you've found a server that works, you can keep using it for everyday tasks while support investigates the problematic setup. There's no need to keep changing your configuration while you wait.

Sessions and background activity

Frequent disconnects and background drops: find the trigger

Tell disconnects, network loss and app reconnections apart

Check whether the client toggle turns off, the system VPN indicator disappears, or the app simply reloads its content. If the client still says connected but webpages stop responding, the connection path may have dropped. If the toggle switches off on its own, check whether the client core stopped or lost system permissions. If only one app reconnects, it may be an app-session issue. Record these separately; don't treat every sign-in prompt as a VPN disconnect.

Think about whether the issue consistently happens when you lock the screen, switch networks, enable battery saver, close a laptop or wake it from sleep. A network change can disrupt the underlying connection, so the session may need to be established again. Sleep pauses app activity, and reconnecting after wake can take time. If you can reproduce the trigger, test that condition first instead of switching servers at random. Save logs from before and after the issue, especially entries about the core stopping, network changes and reconnections.

On mobile, check background activity and network permissions

On Android, first confirm that system VPN permission is still granted, then check the client's battery and background-running settings. Menu names vary by device and are usually under app info, battery or background management. Adjust settings only for the client that needs to maintain a connection; there's no need to exempt every app from restrictions. Afterward, test with the screen locked and note whether the system still stops the client process.

Also check whether the client is allowed to use the current network in the background and whether a power-saving mode is limiting background activity. Some devices' app-cleanup tools also stop the connection core, making it look like the connection dropped on its own when the interface comes back. Rule out manual cleanup before blaming the route. For full setup steps, see the Android client and subscription guide.

On iOS, check in system VPN settings that the configuration is present and that its connection status matches the client, then confirm the selected connection in the client. Don't confuse a VPN configuration created by another app with the one you're using now. If only the target app's session ends after the screen locks while the system connection remains active, check that platform's session policies. For initial permissions and subscription import, see the iPhone setup guide.

Troubleshooting sleep and network changes on computers

On Windows, macOS and Linux, sleep, re-enabling a network adapter or switching Wi-Fi networks can all disrupt an existing connection. First make sure regular internet access is back, then reconnect the client manually and see if it stays stable. Don't permanently disable all power-saving features just to preserve a session. First check whether the issue only happens after waking from sleep. If reconnecting fixes it, mention the wake-up trigger in your ticket to avoid unnecessary route tests.

A weak Wi-Fi signal can cause repeated disconnects and reconnects, and your device may switch between access points. Test again from the same location on the same network and check whether other real-time apps also drop. If all apps are affected, troubleshoot the local network first. If regular internet stays stable but the client core keeps stopping, check the error logs and permissions. If the same core error occurs across different local networks, submit a support ticket.

Restore your usual settings, then check whether the issue persists

Some clients offer options such as auto-reconnect, on-demand connection or keep-alive. Names and behavior depend on the client. Read the option's description before enabling it to make sure it restores the connection rather than changing rules. Auto-reconnect can help restore a connection, but it won't fix an invalid subscription, depleted data or a broken configuration. If repeated reconnects still don't restore access, stop the retries and return to the connection troubleshooting section to check the basics.

Don't ignore certificate errors, disable system protection or repeatedly force-quit processes to keep a connection alive. Check background permissions and the client-core status before investigating route interruptions.

After a test appears to fix the issue, repeat the action that originally triggered it—for example, lock the screen and reopen the app, or wake the device from sleep and visit the same webpage. If it still disconnects, note the reproducible steps, device OS, client name and selected server, and attach redacted logs from before and after the drop. Support needs to know what triggers it, not just see a static screenshot saying “disconnected.”

Subscription access and account status

Subscription update failed? Check retrieval and parsing separately

First, identify which stage failed

A subscription update usually retrieves content from the server, passes it to the client for parsing, then refreshes the server list. A network timeout, permission error and config parsing failure happen at different stages. Read the full update message to determine whether content could not be retrieved at all or was retrieved but couldn't be recognized. An unchanged server list doesn't necessarily mean the update failed; the server-side content may simply be unchanged. Check the client's message to confirm.

Open Account Overview and check that your plan is active, your data is available and the subscription entry is accessible. Don't keep using old information that may have expired or been reset. No email address is required; create an account with a username and password. Login details are for accessing your account, while subscription details are for connecting your client—they aren't interchangeable. Don't paste your login password into the subscription URL field or share the full subscription link in a support ticket to prove account ownership.

Check the copied link, its source and client compatibility

When retrieving your subscription from the dashboard, use the appropriate copy or import option and make sure a chat app or text editor hasn't inserted line breaks into the address. If pasting it manually, check for extra spaces and make sure you copied the full address, but don't send the complete link to someone else for inspection. Clients may support different config formats, so use the option that matches your client. A config file, webpage URL and subscription URL aren't interchangeable just because they look similar.

If the dashboard opens in your browser but the client times out during an update, check whether the client uses a different network path from the browser. Some clients retrieve updates through the system network; others let you use the current connection. Check the client's settings for details. If your existing servers aren't working, relying on one to update your subscription can create a loop. First try a supported update method while basic internet access is working; don't rewrite the URL blindly.

If the update returns a webpage, sign-in page or error message instead of the config the client needs, parsing will fail. Check that you're using a valid entry from the dashboard and whether a public-network sign-in page is interfering. Don't save the returned webpage as a config and keep importing it, and don't upload your subscription to an online “universal converter.” That could expose your account access details to an unfamiliar service.

Keep your existing config and isolate format issues

If your existing config still works, keep it. Create a separate test config using a method supported by your client, then try updating that one. This helps distinguish local overrides in the old config from the new subscription content. Don't set the test config to launch automatically or delete settings your original config needs. If the new config works but the old one fails, check your local changes. If both show the same parsing error, share the field name in the error with support.

If the client says a field or config type isn't supported, first check whether the subscription entry matches your client. Don't simply delete unfamiliar fields. They may control DNS, routing rules or connection behavior; removing them could make the config load while changing how your requests are handled. Get clients through the dashboard download page. Sign in to retrieve your subscription; your available client options depend on your plan status in the dashboard.

Distinguish data resets, plan changes and list updates

Data on monthly subscriptions resets each month on the plan's activation date; the start of a calendar month doesn't mean your data has reset. Mid-cycle upgrades are prorated for the remaining days. Check your account status in the dashboard. Data add-ons remain available until used and never expire, but that doesn't mean the connection will continue to work after the data is used up. Updating a subscription refreshes connection configuration; it doesn't add data or correct an order status. Check your account and order details separately for billing issues.

Subscription links contain sensitive access information. Redact the full URL, tokens and QR codes from logs, screenshots and public posts. Never paste a live subscription into an online config-analysis tool.

After updating, make sure the client has selected the newly updated config, then check the server list and current selection. If multiple configs are present, the update may have succeeded for one that isn't in use. If your dashboard status is normal but the update still fails after trying another network and retrieving it again, submit the failed stage, client name, type of subscription entry and a redacted error message. For account or order questions, include the relevant order details and handle them separately in a support ticket.

Apps, rules and exit regions

One app won't use the proxy? Check which rule it matches

First, check whether the app's requests reach the client

If your browser can access international websites but one app consistently fails, first check whether that app's requests appear in the client's connection logs. If nothing appears, the app may use its own network settings, ignore the system proxy or be allowed through by an earlier rule. If requests are logged, check the matched rule and selected server. A connection icon or successful browsing in another app doesn't prove that this app is using the same route.

The system proxy provides an entry point for apps that respect that setting; it doesn't automatically route every program. Some apps manage their own network connections, while clients may offer other routing modes. Read the current mode's description before deciding whether to change it. Don't enable broader traffic handling without understanding the permissions and routing effects. On work devices and managed networks, follow existing policies rather than changing your organization's required network path.

Use a temporary comparison to check routing rules

If your client supports different rule modes, save your current settings, briefly switch to a global proxy mode suited for troubleshooting and restart the target app before testing. If that fixes it, the original rules are worth checking; it doesn't prove that the route was at fault. After testing, switch back to your original mode and review the connection logs for a missed or incorrectly matched domain. Don't keep the temporary diagnostic settings as a permanent fix, since they may change how other apps connect.

An app may connect to separate domains for sign-in, content, media and resources, so covering only its homepage may not be enough. Check the requests associated with the failed action—for example, sign-in works but images won't load, or the homepage works but playback fails—then look for relevant rules. Don't add broad matches based on keywords or replace the entire ruleset with one from an unfamiliar source. Identify which type of request isn't reaching the expected server, then make a supported change.

Local overrides, custom user rules and subscription rules may have different priorities. If the client says a domain should use the proxy but the logs show a direct connection, check whether an earlier rule is taking precedence. Rule names don't prove what actually happened; connection logs are a better indicator. Save the rules and test results from before and after changes. If there's still a conflict, share a redacted excerpt rather than uploading a full config that contains your subscription and account details.

Handle regional restrictions separately from connection errors

If a target platform shows a region, account or eligibility notice, the request may have reached the platform but failed to meet its requirements. That's different from a network timeout. Platforms may assess the exit region, account settings, payment details or existing session. Choosing a VPNFZ server doesn't override platform policies. Check the target platform's requirements before switching regions; access to any third-party app or content catalog isn't guaranteed.

Accessing an AI tool's website and using its account features are separate checks. If the site opens but a feature isn't available, check the account message, supported service regions and app permissions. If requests time out, return to the connection logs and route troubleshooting. For more on region checks and usage conditions, see the Claude server selection guide. Keep the exit region consistent during testing so frequent changes don't add more variables.

Cached data and old sessions may keep using the previous route

After changing rules or servers, the target app may keep reusing an existing connection. Stop the current task, quit and reopen the app, then check the new request logs. If needed, clear only the relevant app cache. Before deleting sign-in data, make sure you can log in again. Don't clear data across every app and browser at once: a new sign-in verification issue could mask the original network problem and make it harder to tell whether the change worked.

Useful evidence for app routing includes the specific action, related request, matched rule, selected server and platform response. “The browser works but the app doesn't” isn't enough to identify where routing went wrong.

If the same target behaves differently in a browser and an app, describe the difference in your ticket and attach redacted logs from around the failed action. If every server returns the same account notice, follow the platform's requirements first. If requests are rejected only under a particular rule, include the rule match details. For streaming, see the streaming access guide, but rely on actual results and the platform's policies.

Platform differences and account sharing

Platforms and multiple devices: pinpoint a problem on one device

If you see a “device limit exceeded” message, check where it came from

VPNFZ supports unlimited simultaneous connections. If you see a device-related warning, check whether it came from the account dashboard, the client or the third-party app you're using. The target platform may have its own session and device policies; don't assume the message means VPNFZ has imposed a limit. Save a redacted screenshot and note where it appeared and what you were doing. Don't change plans or delete configs on other devices just because the message mentions devices.

If the same account behaves differently on different devices, first check that they use the same active subscription and that the selected config and server match. One device may still have an old entry or different local rules. The same account status doesn't mean the local connection settings are the same. When comparing with a device that works, check the config source, rule mode and network instead of copying all its system settings.

Compare devices and networks in both directions

Connect the affected device to the network used by the working device, then connect the working device to the network where the issue occurs. Keep the target and server the same. If the problem follows the network, troubleshoot the local connection. If it follows the device, check permissions, the client core and system proxy. There's no need to reinstall everything on every device at home or switch servers on all of them at once. Keeping a working comparison makes it easier to isolate the cause.

When multiple devices share a local network, uploads, cloud sync and video can all use the same connection capacity. Unlimited simultaneous connections describes the service's connection policy; it doesn't mean your router, Wi-Fi or target platform has no resource limits. If performance drops when several devices are active, pause nonessential transfers and compare one device with the same devices running concurrently. For details on family sharing and what counts as a device, see the multiple-device guide.

Check how each platform handles network traffic

On Windows, if regular websites stop working after you exit the client, check whether the system proxy still points to the local program that has stopped. Exit the client normally or use its reset option, then check your system network settings. On macOS, make sure you're checking the network service currently in use, not an inactive interface. Don't enter a fixed local proxy port based on something you found online; use the port and routing method shown in your client.

On Linux, desktop apps, terminal processes and system services may use different proxy settings. Terminal programs may also read their own environment variables, so a working browser doesn't prove command-line tasks use the same route. Check the app's documentation and the current process configuration, and note any differences for troubleshooting. Don't leave a diagnostic proxy in global startup files, and never paste environment variables containing credentials into a ticket.

Keep settings consistent, but don't copy them blindly between platforms

On mobile, focus on system permissions, network changes and whether the app stays active in the background. Desktops are more likely to have multiple proxy entry points. The same subscription may appear differently and offer different settings in different clients. Import it through the supported method for each platform rather than copying another system's config path or permission settings. For first-time setup and import, follow the Quick Start Guide.

When sharing an account, keep login and subscription details secure and use them only on trusted devices. If you think your details may have been exposed, use the dashboard's available account-security and subscription-update options, then retrieve a fresh config on your other devices. Don't turn troubleshooting account sharing into a public post containing your subscription. Check screenshots for QR codes, links and account identifiers as well as passwords.

If the warning really comes from the VPNFZ dashboard and conflicts with its unlimited simultaneous connections policy, stop guessing how limits are counted. Submit a screenshot and describe how the message appeared so support can investigate.

For a multi-device support ticket, specify which device works, which doesn't, and whether they share a network, subscription and server. “It works on my computer but not on my other devices” leaves out important details. If the problem still follows a particular device after cross-testing, include that device's OS, client and core error. If it follows a network, describe the type of connection and how to reproduce the issue.

Organize evidence and hand it over to support

Support tickets: share steps others can reproduce

Know when to hand the issue over to support

Submit a support ticket if your basic network works, your plan is active and the client core starts, but the same connection error recurs across different networks and servers. Contact support if a subscription still fails to parse after you retrieve it again, the dashboard and order status don't match, or you see a message that contradicts the unlimited simultaneous connections policy. Don't keep changing settings just to try one more thing; preserving the issue as it is can be more useful.

If the issue involves a managed device, system permissions or organizational network policy, contact the appropriate administrator instead of removing managed components yourself. If the target platform clearly shows an account or region notice, follow its requirements and describe the account issue separately from the network connection. Support can help check the connection path, but can't approve a third-party account or guarantee that a target service will always accept your current access environment.

Use a consistent format to organize the details

Submit a ticket through the user dashboard after signing in. Start with one sentence describing the issue, such as “After I lock the screen, the client still says connected but the target website times out.” Then list when it happened, your device OS, client name, selected server, rule mode and type of local network. Finally, summarize what you tested and what happened so support doesn't have to repeat the same basic checks.

Symptom: what specifically goes wrong after connecting
Environment: device OS, client name, type of local network
Configuration: selected server, rule mode, subscription status
Trigger: opening the target, switching networks, locking or waking the device
Comparison: results after switching servers, networks or devices
Error: on-screen message and redacted logs
Expected outcome: restore the connection, check the subscription or review the order

When sharing client details, use the name and information shown in the app rather than relying on memory. Give the time you observed the issue and your time zone so support can match it to the logs. You can describe the local network as home Wi-Fi, public Wi-Fi or another type of connection; there's no need to provide your exact address. For the target app, give its name and the action that failed. Don't include personal content, conversations or files unrelated to the issue.

Redact logs and screenshots before sharing

Include only the relevant records from before and after the issue; you don't need to export your entire history by default. Logs may contain domains, network addresses, subscription links and account identifiers, so review them before submitting. Hide passwords, tokens, full subscription URLs, QR codes and other access credentials. Keep the error type, server name and sequence of events. Don't redact all the context around the error, or support will be left with nothing but “failed” to investigate.

Include the screen showing the error and enough context to understand it, but close unrelated windows and hide personal content. For an app-routing issue, include the matched rule and server. For a subscription update, show whether it failed during retrieval or parsing. For an order issue, include the relevant details from the dashboard. Don't post a full subscription link in public comments or share your account password to make things easier for support.

Keep your test results together in the same ticket

If you continue troubleshooting after submitting a ticket, add new results to the same thread and note what you changed and whether it helped. If support recommends a settings change, save the original state first, then test as advised. If the issue clears, explain which action worked. Don't reinstall, switch networks and servers, and change the target all at once. Otherwise, you won't know what fixed it, and the result won't help if the issue comes back.

If you find a server that works temporarily, you can use it for everyday tasks while keeping the original failing setup and its evidence. A recovered connection doesn't mean every diagnostic setting is suitable for long-term use. Undo temporary rules, restore normal validation and check that other apps still connect as expected. When closing the ticket, note the final server, whether you restored your configuration and whether the issue still occurs—not just “it works now.”

Check billing and refunds separately

Connection troubleshooting and billing may be related, but they require different information. For a billing issue, include the order, dashboard status and what you want checked rather than just attaching a network error. VPNFZ offers a 7-day no-questions-asked refund policy. See the refund policy for application details and the Terms of Service for usage conditions. Repeated connection attempts don't mean you have to keep using the service, and don't guess how long a refund will take.

A support ticket should include your environment, trigger, comparison, error and expected outcome—not your access credentials. You can provide complete facts while keeping your information secure.

Keep a short record of your own troubleshooting: the original symptom, what you confirmed was working, the final cause and the fix that worked. If the same issue comes up again, check whether the conditions match before reusing that fix. If the failure occurs at a different stage, return to the relevant section rather than treating the last fix as universal. For general questions, see the FAQ. For support, visit the contact page and submit a ticket through the dashboard.