QiuVPN Troubleshooting

Before the connection is established

Can't connect at all? Find out which layer is failing

First check whether your regular network is working, then see whether the client can establish a connection. “Can't connect at all” could mean the client won't start, the subscription list is empty, the connection hangs after you select a route, or simply that one page won't load in your browser. These symptoms occur at different layers. Before troubleshooting, note the exact message on screen, the route name, your network and what you were doing when the issue started. Don’t delete the configuration yet. Removing it may clean up the interface, but it can also erase the most useful clues.

Disconnect the client and check your network

Disconnect the client, then open a local website that normally works. Check that your Wi-Fi connection isn’t waiting on a captive portal. Public Wi-Fi may require you to accept its terms, but the browser doesn’t always open the sign-in page automatically. Complete the network’s own sign-in first, then start the client. If local websites won’t load with the client disconnected, check your Wi-Fi, router and broadband connection first. If possible, compare with another trusted network, but there’s no need to change advanced router settings just to test.

Once your network is working, check that your system date, time and time zone are set automatically. An incorrect clock can interfere with certificate validation and cause handshake failures or secure connection errors. Next, check your plan status, remaining data and subscription validity in the user panel, then make sure the client hasn’t selected an empty configuration. If the panel won’t load either, note whether panel access and route connections are both failing. Don’t assume that means your plan is invalid: opening the page also depends on your current network and browser.

Use the error message to distinguish permission, port and route issues

If you see a system prompt for network access after tapping Connect, verify the app’s source and name, then grant permission. If permission was denied, check the relevant network extension or VPN setting in your system settings. If the logs mention a port conflict, quit other proxy clients, packet capture tools and duplicate client processes. Closing a window may not stop a background process; use the app menu to quit. Don’t follow unfamiliar instructions to terminate system processes or disable your device’s overall security just to connect once.

Once permissions and account status check out, test a different route in another region or of another route type. Keep the original route name for reference, change only the route, and leave other settings as they are. If the alternative works, the client can connect; focus next on the path between the original route and your local network. If all routes fail, test again on another network. If that works, describe the differences between the two networks in your support ticket rather than repeatedly importing the same subscription.

“Connecting” doesn’t mean the connection has succeeded, and it isn’t a diagnosis on its own. Check the permission prompt, client logs and your basic network connection before deciding what to try next.

When to stop troubleshooting on your own

Submit a support ticket if the same configuration fails on different networks and the logs keep showing the same authentication or handshake error. Include the error message with sensitive details redacted, your operating system, the route name shown in the client and whether you recently updated the subscription. If the issue occurs only on your current network, say whether it’s home broadband, a workplace network or public Wi-Fi. For a device or network managed by your organization, ask an administrator to check permissions instead of changing organizational policies. If you’re unsure about installing the client or importing a subscription for the first time, check the main steps in the tutorial.

After the connection is established

Connected but websites won't load? Check DNS and connectivity separately

When the client says Connected, it confirms that a connection has been established; it doesn’t prove that every website request is taking the expected route. Test different kinds of pages: a local site you use regularly, a standard international site and the service you’re having trouble with. If only one site fails, check its regional requirements, account status or whether the site itself is having issues. If no domain loads, check proxy routing and DNS. The browser’s full error message is more useful than a general report that “the network isn’t working.”

Check whether the error occurs during DNS lookup or connection

DNS translates website names into network addresses. If your browser says it can’t find the server address or resolve the name, focus on DNS. If it reports a connection timeout, reset or certificate error, also check the proxy route, system time and destination website. One address responding doesn’t prove that DNS is working for every domain. Don’t replace a website’s domain with its IP address, either: modern sites usually rely on domain names for certificate validation and routing, so direct IP access can lead to the wrong conclusion.

First check that the client has enabled the expected system proxy or network interception mode. Then see whether your browser has its own proxy extension or Secure DNS setting. Browser-level DNS can operate alongside client rules, so the same domain may resolve differently in different apps. For a quick test, temporarily restore the browser’s default network settings, disable extra proxy extensions and reload the page. Change one setting at a time and note its original value. If restoring the defaults doesn’t help, revert promptly to avoid piling on unrelated changes.

Use system tools to inspect DNS before changing resolvers

These commands show the current system DNS configuration and the lookup result for a sample domain. They don’t change your subscription or network settings. On Windows, run the relevant command in Command Prompt; on macOS and Linux, use Terminal. If a command isn’t available, there’s no need to install extra tools—check your system’s network settings instead. A resolver address in the output could belong to your router, a local proxy or your current network. Don’t infer a leak from the address alone; check the client’s DNS routing behavior and the actual request path too.

# Windows: Check network and DNS settings
ipconfig /all
nslookup example.com

# macOS: Check system resolvers
scutil --dns

# Linux: Check status on systems using systemd-resolved
resolvectl status

If the system can resolve names but your browser can’t, check the browser cache, extensions and Secure DNS. If multiple apps fail to resolve names, check the client’s DNS module and the resolver provided by your current network. Disconnecting the client temporarily can help show whether the issue appears when network traffic is intercepted. Don’t copy random resolver addresses from the internet into every available setting, or change your router, system and client settings all at once. The more sources of configuration there are, the harder it is to tell where requests are going.

Check caches and certificate errors

After changing rules or switching routes, existing connections and DNS cache entries may remain in use. Fully quit and reopen your browser; if needed, follow your operating system’s official instructions to flush the cache. If a page shows a certificate name mismatch, don’t ignore the warning or enter account details. Check the system time and website domain, and make sure you aren’t on a public Wi-Fi sign-in page. If only one service says it isn’t available in your region, visit the global routes page to check its regional requirements instead of treating a region mismatch as a DNS issue. When you contact support, say whether the system lookup result matches what you see in the browser, and redact local addresses and other unnecessary details.

Speed and performance

Slow speeds and peak-time lag: make a fair comparison

Start by describing what’s slow: the first page load, sustained downloads, video buffering or occasional pauses during interaction. These symptoms can point to DNS, connection setup, ongoing data transfer or local device load. Pause large downloads and cloud sync on other devices, keep the test site, device and network the same, then compare routes. Don’t treat a single peak speed test as representative of everyday performance, or compare results from different regions and servers as if they were equivalent.

Rule out Wi-Fi signal and device load first

On the same network, move closer to your wireless access point and reload the same page. If possible, compare with a wired connection. If local websites are slow too, the cause may be Wi-Fi interference, broadband congestion or device performance—not just your international route. Check whether your system is downloading updates, syncing files or running resource-intensive tasks. Too many browser tabs, low storage space and video decoding load can all feel like a “network slowdown.” First distinguish slow page loading from sluggish overall interface performance.

When comparing routes, keep the destination website and video content the same; change only the route. Start with a region that meets the service’s requirements and suits your current network path, then compare route types. A nearby location doesn’t always mean a shorter data path, and labels such as dedicated, transit or direct don’t replace testing in your own environment. See our guide to choosing a route by region, route type and use case to understand the selection process before testing, rather than switching randomly through the whole list.

Reproduce peak-time issues under the same conditions

If everything works normally except at certain times, note when it happens, which network you’re on and what you were doing. Also describe when the same activity works normally. Peak-time slowdowns can involve changes to your broadband, cross-border path and destination service; the time of day alone doesn’t identify the cause. When comparing another route or network, keep the content and video quality settings the same. If only your current broadband has trouble at that time and an alternative network works, that difference is more useful than a vague claim that “all routes are unstable.”

Troubleshoot streaming and AI interactions separately

Watching 4K content also depends on your platform account, source video, player settings and device capabilities. Automatic quality reduction alone doesn’t prove the route is failing. First check the player’s current quality setting and whether the same thing happens with every video. For more detail, see our guide to bitrate, bandwidth and streaming quality. Long waits with AI tools may occur while the service is generating a response. If the page remains responsive but generation is still in progress, don’t disconnect immediately—you could interrupt the request.

If the same activity keeps failing across several available routes and you’ve ruled out local downloads and Wi-Fi issues, send support the route name, time, activity type and comparison results. There’s no need to upload large files or use a lot of data just to demonstrate buffering. QiuVPN offers 110+ countries / 150+ routes; narrow your choices by use case rather than assuming every route performs the same on every network at every time.

Connection stability

Frequent disconnects and mobile background drops: identify the trigger

First determine whether the client actually disconnects or the app simply stops updating its content. Note whether the drop follows a screen lock, app switch, Wi-Fi change or device sleep. If only one app stops refreshing while the client still shows Connected, check that app’s background restrictions and routing rules. Recording what triggered the issue is more useful than saying only that it “disconnects a lot.” During troubleshooting, stick with the same route where possible so network changes and route changes don’t get mixed up.

Issues after locking the screen? Check system background settings first

Android power-saving settings may restrict background network access or stop long-running processes. Open the app settings and check the client’s battery use, background activity and network permissions. Menu names vary by device, so follow the descriptions on your screen. Adjust permissions only for the client that needs a persistent connection; don’t disable your device’s overall power-saving or security features. If the client displays a foreground service notification, leave the necessary status notification enabled. Hiding the service can make it look as if the client has stopped.

On iOS, check that the system VPN configuration is still present and that the app’s connection status matches the system status. Network extensions behave differently from ordinary apps in the background, so don’t assume methods for other platforms will work. If the device has multiple network extensions, content filters or other VPN configurations, note what each one is for, then stop nonessential services one at a time for comparison. Don’t remove configurations managed by your organization. On a personal device, make sure you know how to restore a setting before changing it, so you don’t disrupt normal connectivity.

A disconnect after switching networks doesn’t mean the route has failed permanently

When you switch networks, your local address and outbound path may change, so existing connections need to be re-established. Wait for the client to finish updating its network status, then open a new page to test. Don’t rely only on a download that was already stalled before the switch. If the client offers automatic reconnection, you can enable it as described in its documentation. It will try to restore the connection, but it won’t necessarily resume existing sessions in every app. Check whether the app itself supports resuming long transfers or interactive tasks.

Desktop devices can have similar issues after sleep. Once the device wakes, make sure Wi-Fi has reconnected before checking whether the client has re-established its connection. If the system proxy remains enabled while the client is no longer running, pages may appear inaccessible. Starting the original client or restoring the system proxy as described in its documentation is more targeted than resetting all network settings. Don’t copy a fixed proxy address into multiple apps: if the client quits, those apps may keep trying to connect to a local service that’s no longer running.

Check whether disconnects affect a particular route or service

If the device stays awake and the network doesn’t change but the connection keeps dropping, compare another route and check the error category shown just before the disconnect. If only one destination app stops working, the cause could be an expired session or the service’s own connection policy. If every app fails at the same time, a connection-level issue is more likely. Temporarily quit extra proxy clients, network acceleration tools and packet capture software to check for conflicts from overlapping traffic interception. Restore any tools you normally need once testing is complete.

Don’t use repeated toggling as a substitute for observing what happens. First identify a common trigger—“after locking the screen,” “after switching networks” or “during extended use”—then change the setting that corresponds to it.

If you can still reproduce the issue after adjusting background permissions, send support your operating system, device power mode, client status before and after the drop, and whether the network changed. Include only log excerpts near the event and redact subscription URLs and account details. If one route disconnects during continuous foreground use, include results from an alternative route. If every route fails after the screen locks, focus on the system’s background behavior. For help with the initial platform setup, return to the client quick-start guide; there’s no need to uninstall and reinstall first.

Configuration access and account status

Subscription update failed? Check download and import separately

A subscription update has two stages: retrieving the configuration and parsing it. If the client reports a network timeout, check how it downloads the configuration. If it reports an unsupported format, invalid fields or no usable configuration, check the returned content and import method. Don’t keep deleting the subscription just because the update failed. Save the error message, check whether the existing configuration still connects, then verify the subscription entry in the user panel. Subscription URLs are sensitive: don’t post them in public forums or submit them to unfamiliar conversion sites.

Check the panel first, then verify the import destination

Check your account and plan status in the user panel, and make sure you’re using the subscription for your current account—not an old record or another account. QiuVPN doesn’t require an email address; you can get started with a username and password. If you can’t sign in, first check that you’re entering the right username rather than treating a login issue as a route failure. If different browsers have saved different accounts, confirm which account is active before importing.

Get the appropriate configuration from the client entry in the panel. When copying, don’t include surrounding instructions, extra spaces or line breaks, and don’t mistake the panel page URL for a subscription URL. If the client supports direct import, confirm that the intended app will receive the import request. On devices with several similar clients, the system may hand it to an older app. After importing, check the configuration name and route list. A “success” message alone doesn’t confirm that the active configuration has changed.

The next steps depend on whether the old configuration still works

If the old configuration still connects, keep it and try updating it as the client documentation describes. Depending on your network, retrieving a subscription may require an active connection, while other networks may make the panel easier to reach with the client disconnected. Test both possibilities instead of assuming one is always right. If the old configuration doesn’t work either, check your basic network and panel access, then verify your plan status and available data. If the request never reaches the subscription endpoint, importing the same URL again usually won’t help.

If the error points to a parsing problem, use the import method in the panel that matches your client. Different clients may accept different configuration formats; a file for one app may not work as a generic file in another. Don’t delete fields at random just to pass validation, and never copy authentication details from logs into unfamiliar scripts. You can share the names of the fields and the error category with support, but don’t attach the complete configuration unless you’ve removed all sensitive details.

Distinguish data resets, plan upgrades and configuration updates

Monthly plan data resets each month on the activation date. If you upgrade mid-cycle, the price difference is converted into the remaining days. Updating a configuration simply fetches the available settings again; it doesn’t change the data reset schedule or update your plan status. Data packs don’t expire, but are used until depleted, so their balance doesn’t follow the monthly plan reset schedule. To compare the two billing options, see the plans and pricing page or our guide to data packs and monthly plans. First check which type your account uses.

Don’t include the full subscription URL in a support ticket screenshot. The error message, client name and steps you took are enough. Redact sensitive URLs before sending anything.

If your panel status is normal, your network is working and you’re using the right import method but the update still fails, tell support whether the error occurred during download or parsing, whether the old configuration connects, whether you changed networks, and the exact error shown in the client. If the issue began after changing subscription credentials, mention that a change was made, but don’t share either the old or new credentials. Remove the old entry only after confirming you can retrieve the configuration again, so you don’t lose a backup that still works.

Request routing and destination services

One app won’t use the proxy? Check traffic routing and rules

If your browser works but one app can’t connect, don’t assume the route is down. Apps may use different network interfaces, DNS methods and caching behavior; enabling a system proxy doesn’t automatically route all traffic. First confirm that the issue is limited to that app, then check the client’s current mode, app rules and exclusions. Note the name of the mode you’re using rather than copying a setting name from a guide for another platform. Features with the same name can behave differently across clients.

System proxy, network interception and app-specific settings

A system proxy is generally used by apps that follow the system proxy settings. Network interception may handle a broader range of requests through a virtual network interface. If an app doesn’t use the system proxy, a successful browser test doesn’t prove that its traffic is routed too. If your client supports network interception, enable it as documented after confirming the system permissions. If it doesn’t, don’t install unfamiliar drivers or configurations. For apps with their own proxy settings, check that they aren’t still using an old address or port.

App exclusions and per-app routing can also affect the result. Check whether the app is set to connect directly or its category is assigned an unsuitable policy. After changing a rule, existing app connections may not move immediately. Fully quit and restart the app, then try the request again. Don’t change the interception mode, route and rules in the same test. Even if that fixes the issue, you won’t know which change helped, making it harder to reproduce a stable result.

Check the rules against actual requests, not just the home page domain

A service may use different domains for sign-in, static assets, media and API requests. Routing only its home page domain may let the page load while sign-in fails, or show text without images. If your client provides connection logs, check which rule matched a failed request, but don’t export request contents or account credentials. Checking related requests the service actually needs is more reliable than routing every unknown domain the same way, and helps preserve normal access to local services.

Temporarily expanding the proxy scope can help establish whether routing rules are involved, but first consider the effect on local services and restore your intended mode after the test. If expanding the scope fixes the issue, find the missing or conflicting rule rather than treating the temporary setting as a permanent solution. If the issue remains, check the route region, app cache, account status and the destination service. For managed devices and enterprise apps, follow your organization’s policies instead of changing its required connection settings.

Separate regional restrictions, account eligibility and connection problems

AI tools and streaming services may consider your exit region, account settings and where the service is available. A working network connection doesn’t guarantee that your account is eligible to use a service. If you see a clear region or account message, check the service’s own guidance and choose a route that meets its requirements. Avoid switching regions repeatedly, which may trigger extra account verification. For AI use, see the AI tools access guide. For video, see the streaming guide to learn how connection, region and playback access differ.

To tell whether traffic is being routed, check the policy matched by the actual request—not whether the client window is open. An app still running doesn’t mean it has re-established its connection.

If only one app keeps failing, include its name, the action that fails, whether the same service works in your browser, your current interception mode and the matched routing rule in your ticket. Keep screenshots on the error message page; don’t show private conversations, files or account details. If you share logs, include only the records around the failed request. If the message is about account review or content access from the destination service, contact that service. Route support can’t determine third-party account eligibility.

Platform differences and device notices

Device limit or permission error? Check where the message comes from

QiuVPN allows unlimited simultaneous devices. If you see a “device limit” message, don’t assume QiuVPN limits the number of connections or that you need to upgrade your plan. First check whether the message appears in the client, user panel or a third-party website or app. Content services may have their own session or device policies, separate from your network subscription. Note the page and app where the message appears, and redact account details before investigating to avoid troubleshooting the wrong service.

Distinguish service policies, client limits and third-party sessions

If the message appears in a streaming service or work app, follow that service’s guidance to check signed-in devices, sharing rules and authorization status. Changing network routes won’t change a third-party account’s device policy. If the message comes from the client, check whether the active configuration belongs to QiuVPN and whether another subscription or old account remains in the app. Some apps display their own license, import or management limits. These aren’t the same as the number of devices that can use a route subscription; share the exact message with support for clarification.

Unlimited devices refers to the number of devices; it doesn’t automatically grant system permissions on each one. Windows, macOS, iOS, Android and Linux each require their own client setup and network authorization. Importing a configuration on one device won’t install the client on your other devices or change their system proxy settings. Use the client downloads in the panel to find the right files for your platform. Don’t download installers from chat attachments or unfamiliar websites.

Check permissions for each platform; avoid resetting everything

On Windows, check that the app is running, the system proxy matches the client’s status and any network interception component has the required permissions. On macOS, check system authorization for the network extension and make sure it isn’t still waiting for approval. If the system blocks an app, verify its source and follow the official setup process; don’t copy terminal commands that disable security protections in bulk. For more detailed first-time authorization steps, see our macOS installation and setup guide.

On Linux, check whether command-line and desktop apps use the same proxy settings. Environment variables in a terminal may apply only to the current session, so they don’t prove the whole system is routing traffic. Likewise, a working desktop browser doesn’t prove that command-line tools are using the system proxy. Check the official proxy guidance for the tool you’re troubleshooting. Don’t put proxy settings containing credentials in public scripts or permanently add temporary troubleshooting variables to every user’s startup configuration.

Keep a way to restore settings before changing the device

Before removing an old configuration, confirm that you can sign in to the panel again and retrieve your subscription. Ask an administrator to handle authorization issues on managed devices; don’t try to gain access beyond your permissions. If another personal device works on the same network, compare the affected device’s permissions and traffic interception settings. If all devices have the same issue, go back to checking the network, subscription and route. For a “device limit” issue, include where the message came from, which configuration is active and how other devices compare. Don’t share a full list of device identifiers or unrelated personal data.

Organize your evidence and choose the next step

Contact support: include reproducible details and keep a way to recover

Once you’ve narrowed the issue down, a support ticket is more useful than making random changes. Contact support if your account is active but you can’t connect on multiple networks, a subscription repeatedly returns parsing errors, a particular route keeps disconnecting, or a system message conflicts with the unlimited-device policy. Start with the symptom, describe the comparisons you’ve made, then mention any working alternative. Support needs to know the boundaries of the issue—not your entire unfiltered network history.

Describe “it won’t load” as steps someone can follow

Explain where you started, what you selected, what you did, what you expected to happen and what actually happened. For example: start the client, select a route, open the destination service and get a connection timeout; switch to another route and the page works. This establishes the order of events. If you can’t reliably reproduce the issue, say it happens intermittently and describe the conditions you have in common. Use your actual notes for the time it occurred, and check the client and operating system versions on the device rather than relying on memory.

Submit your request through the user panel support tickets and add follow-up results to the same ticket instead of splitting one issue across unrelated threads. Don’t post account details on public pages. Keep the error name, page location and client status visible in screenshots, but redact your username, subscription details, sensitive order information and private work materials. If you need to send logs, review them first. A filename like “diagnostic report” doesn’t guarantee the file contains no sensitive information.

Symptom: connection status and the specific action that fails
Environment: operating system, client and network type
Scope: all apps / one app / one route
Reproduction: steps from launching the client to seeing the error
Comparison: results after changing routes or networks or quitting other proxies
Message: exact error text or a screenshot with sensitive details redacted
Current status: whether an alternative route works and whether ongoing tasks are affected

Avoid introducing new variables while support investigates

After submitting a ticket, keep the configuration reproducible. Don’t reinstall your operating system, clear the client and change your router all at once. If you’ve found a working alternative route, finish your everyday tasks first, then run targeted checks as support recommends. Note the original setting before applying each suggestion, then report whether the issue is fixed, partly improved or unchanged. If the issue resolves on its own, mention whether the network changed, the subscription updated or the device restarted. This can help distinguish a temporary path change from a configuration fix.

If you’re checking account status, start with the plan and data shown in the panel. Reimporting a subscription isn’t a substitute for checking billing. Monthly plans: ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrade differences are converted into the remaining days. Data packs: ¥158/300GB, ¥358/1000GB and ¥658/3000GB. They’re used until depleted and never expire. Check the plans page and panel for current options and changes. A connection issue alone isn’t a reason to change plans.

Handle billing, refunds and connection support separately

QiuVPN accepts Alipay / WeChat Pay / USDT and offers a 7-day money-back guarantee. For payment status, refund requests or plan changes, specify the issue in your ticket and check the relevant section of the Terms of Service. Don’t post full payment records publicly or use client connection logs as proof of payment. You can mention a connection issue alongside a billing question, but describe each request separately so support can address both the technical issue and the account matter.

Anonymous, no-logs is QiuVPN’s privacy policy. If you submit a support ticket, share only the information needed to resolve your issue. See the Privacy Policy for details on how information is handled.

To confirm the issue is resolved, check whether the activity that originally failed now works—not just whether the client says Connected. Reload the original page, make a new request and test under your normal usage conditions. If only some features work, return to the relevant section and continue checking one layer at a time: DNS for domain issues, routing for a single app, or background settings for screen-lock issues. For everyday questions, see the FAQ. To set things up again, return to the quick-start guide so your troubleshooting notes are useful next time.