VPNTC Connection Troubleshooting

Can't connect at all: establish a diagnostic baseline

First, pinpoint what “can't connect” means. The control panel won't load, the subscription won't update, the client won't establish a connection, and a website errors after connection are different problems with different troubleshooting paths. This section covers cases where the client hasn't connected yet. Note the exact error and when it appears. Don't rely on the status icon alone, and don't change the route, protocol and mode all at once.

Check your local network first

Disconnect in the client, then visit a website that normally opens without it. If that fails too, troubleshoot your local network before switching international routes. Public Wi-Fi may require you to confirm access in a browser. A device showing that it’s connected to Wi-Fi only means it has joined the network; it doesn’t guarantee normal internet access.

If direct access works, start the client and watch whether the connection is pending, succeeds or fails. Note whether the error appears as soon as you click Connect or only after a wait. An immediate failure makes permissions, configuration and local ports more likely suspects. A later failure may involve route reachability or the handshake, but the wait alone doesn’t prove a route is faulty.

Verify the active configuration came from the control panel

Check your plan status and remaining data in the control panel, then confirm which subscription the client is using. If an old and a new configuration are both present, the selected one may not be the latest. Don't manually enter a server address from an old screenshot or copy someone else’s configuration from a chat. Those steps introduce variables that can’t be verified.

If the route list is empty, check the update result in the subscription section first. If routes are listed, connect using one suited to your purpose, then try another for comparison. Keep the client, network and mode the same. Hong Kong, Singapore and Japan are just selection criteria; a shorter distance doesn’t guarantee a better route on your current network.

Check permissions and connection conflicts

The first time a client creates a system-level connection, your device may ask you to approve network configuration access. If you previously denied permission, check again in system settings or through the client. Only features that use a virtual network interface need the corresponding permission. Don't run every program as an administrator or leave system security protections disabled to troubleshoot.

Check whether another proxy client, corporate networking tool or system-level tunnel is running at the same time. These programs may compete for routes, ports or network extensions. Quit tools unrelated to this test normally, then try again. On a managed device, follow your organization’s requirements and don't disable corporate security components yourself; ask an administrator to check for conflicts.

If the error explicitly says a local port is in use, check the listening port configured in the client and identify the program using it. Don't end an unfamiliar process if you don't know what it does. First quit duplicate client instances. If you change the port, update any apps that refer to it too; otherwise, the connection may recover while those apps still can't connect.

Narrow it down by comparing networks

If possible, switch to another network with working internet access and test the same configuration. If it fails only on one network, look into that network’s access rules, routing or protocol compatibility. If it fails on every network, keep checking the account, configuration and client. Switching networks may change your apparent location; pay attention to verification prompts before signing in to sensitive services.

Troubleshoot in this order: Does direct access work? Is the account and data balance okay? Is the configuration correct? Have permissions been granted? How do routes and networks compare? Record each result instead of guessing.

Supported protocols include VLESS, Trojan and Hysteria2, but a protocol name doesn't indicate how serious a problem is. If the client lets you switch, use only configurations available in your subscription; don't change server parameters yourself. For a certificate error, check your system date, time and time zone first. If they're correct and the error persists, save the message for support rather than bypassing certificate verification.

If direct access works, the control panel shows a normal account status, you’ve refreshed the configuration, and similar errors persist across multiple routes and networks, submit a support ticket. Include the client platform, the stage when the connection fails and a redacted error message. For a first-time import, review the Getting Started Guide so an incomplete setup isn’t mistaken for an unavailable route.

Connected but websites won't load: requests & DNS

A connected status usually means one connection stage completed; it doesn’t prove browser requests are taking the right route. First check whether every website fails or only one domain. If all sites fail, check the system proxy, routing and DNS first. If only one domain fails, also consider site maintenance, account access, regional requirements and browser cache.

Use the browser error to choose your next step

Note the key wording in the browser error. A name-resolution failure usually points to DNS. A connection timeout means the request didn't complete in time, but the cause may be local, on the route or at the destination. A certificate warning calls for checking the system time, domain and security software. Don't lump every error together as “unstable internet”—that hides the most useful clues.

Try the same URL in another browser, or compare it in a new session in your usual browser. A new session may still use the system proxy and browser-level DNS settings, so it isn’t a fully independent network test. If only the original session fails, check extensions, site cache and sign-in status. Before clearing data, make sure you know how to recover your account so you don't delete anything you need.

Check whether the request reaches the client

Look for the target domain in the client’s connection log. If no new request appears when you open the page, the browser may not be using the current proxy entry, or another network tool may be handling the request. Check that the system proxy is enabled, points to the current client and hasn't been left behind after the client exits. Don't just keep clicking Connect.

If the request appears in the log, check which rule matched, whether it used a direct or proxied connection, and which route it selected. A page and its resources may use different domains. If the main page loads but images, scripts or a sign-in window fail, check those requests separately. A rule for the homepage domain alone may not cover every part of the service.

Separate DNS resolution from the data path

DNS translates a domain name into an address; the subsequent connection then accesses that address. A browser may use its own encrypted DNS, the system may use a resolver provided by the network, and the client may also handle DNS. First find out which settings are active instead of changing them all at once. Otherwise, if the page starts working, you won't know which DNS path made the difference.

You can use a system terminal to check whether a domain resolves. The example below checks a public example domain and doesn't use subscription or account credentials. A successful command only confirms that the resolver path used by that command returned a result. It doesn't prove the browser or client uses the same resolver, or rule out differences between DNS paths.

nslookup example.com

If an address is returned but the website still won't load, go back to checking the connection path. If resolution fails, check your network and the client’s DNS settings first. Don't replace the website URL with the resolved address as a definitive test: HTTPS certificates, virtual hosting and content delivery may depend on the domain, so direct access to an address often isn't equivalent.

Compare rule mode and address families

If access fails in rule mode but works after a temporary switch to global mode, check rule matching and how DNS resolution interacts with the rules. Global mode is for a short comparison, not proof that the problem is fixed. Restore the original mode afterward so services that should connect directly don't unexpectedly use a different route and trigger new sign-in or regional prompts.

Some networks provide more than one address family, and clients or apps may handle them differently. If the same domain works intermittently or a particular app bypasses the proxy, check the relevant settings and request logs. Note the original value before temporarily changing an address-family option. Don't treat disabling an address family as a permanent fix for everyone or make bulk changes to an organization’s network policy.

A website loading doesn't mean every DNS query followed the expected path. Checking your exit route and checking DNS resolution are separate tasks; verify the client settings and actual requests for each.

Use Network Check to see the current exit result in your browser and compare it with the region selected in the client. This result applies only to that browser request, not other apps. If DNS works, the request reaches the proxy, and multiple routes still can't access the same destination, note the domain and error so support can distinguish a destination-side restriction from a route issue.

Slow speeds and peak-hour slowdowns: compare routes

“Slow” can mean a delayed first response, low sustained download throughput, video buffering or lag during real-time interactions. Each points to different parts of the connection. Download performance doesn't predict how calls or chats will feel, and reference latency in the route list doesn't represent the destination service’s response time. First describe what feels slow, then compare like with like instead of choosing a route based on a single number.

Rule out local resource contention first

Pause syncing, updates and large transfers unrelated to the test, then check Task Manager or your system’s network activity. Other devices on a shared network may also be using bandwidth. If directly accessed websites are slow too, start with the network you're connected to. A strong Wi-Fi signal doesn't rule out interference; if you can, compare with a wired connection or try again closer to the access point.

Check device load as well. Browser extensions, background scans, busy storage or video decoding can make a page feel slow even when the network isn't the problem. If the content has downloaded but the interface still lags, look at the app and device instead of switching routes again. Don't leave security software disabled to troubleshoot; if you need to compare, use its normal settings and restore them promptly.

Keep the destination the same when comparing routes

Use the same destination, network and similar steps for each comparison. Results from different speed-test sites, video sources or download servers aren't directly comparable. Try another route in the same region first, then other regions suited to your needs. Note page response and performance over time. Repeatedly signing in to a service from different regions may also trigger extra checks and complicate the comparison.

VPNTC offers 90+ countries / 190+ routes, but that coverage doesn't mean every route performs the same on every network or at every time. Consider both the route type and what you want to use it for. IEPL, relay and direct routes describe how traffic is routed; none guarantees access to a particular platform or replaces a real-world test.

Keep evidence from peak-hour slowdowns

If slowdowns happen only during peak hours, repeat the same request during a normal period and an affected period, and note your local time and time zone. Check whether all international destinations slow down or just one platform, whether another route in the same region helps, and whether switching networks makes a difference. Without these comparisons, “slow at night” alone makes it hard to distinguish local congestion, route congestion and destination load.

For video, check continuous playback rather than just the homepage. Starting playback, changing quality, seeking and resuming may use different resources. If only high-quality video buffers, try a lower quality to check playback continuity, then investigate the network path. The platform’s automatic quality selection can also depend on the device, account and content; don't attribute everything to the subscription service.

Waiting for AI tools also involves server-side processing and queues. If a page opens quickly and a prompt submits successfully but the response takes a long time, data transfer may not be the issue. Compare the sign-in page, loading a past conversation and other lightweight pages. If only generation is slow, check for a notice from the service. For the difference between exit location and sign-in environment, see Accessing AI Tools.

Data and protocols aren't speed controls

Check your remaining data in the control panel so you don't keep testing network quality after you've run out. Upgrading a plan addresses data usage; it isn't a confirmed fix for slow speeds. Protocols may perform differently on your current network, but use only configurations included in your subscription. Don't change server parameters, transport settings or certificate checks to chase speed.

A reliable comparison keeps the destination, access network and steps the same and changes only the route. If the problem tracks the time rather than the route, include comparisons across both time periods and networks.

After testing, keep a route that suits your current needs instead of chasing reference numbers. See the server page for regions and route types. If every available route is slow on one network but works on another, focus on the access network. If the issue persists across networks, note the affected destinations and times, then submit a support ticket.

Frequent disconnects and mobile background drops

First distinguish a real client disconnect from an app losing its connection. If the client still shows connected when you return but a chat or call has dropped, the issue may involve the app’s persistent connection, routing rules or a network change. If the client itself has stopped, check whether the system terminated its background process, the network changed or an explicit error appeared.

Note what triggers the disconnect

Check whether the issue follows locking the screen, switching Wi-Fi networks, waking the device, enabling battery saver or opening another networking tool. If the same action triggers it each time, investigate that branch before changing protocols. If there’s no obvious trigger, compare with the app open in the foreground. If it stays connected there but fails in the background, focus on system background management and the app’s own keep-alive behavior.

A network switch changes the path used by the existing connection, so the client may need to establish a new one. The destination app may also need to sign in again or restore its session. Even after the client reconnects automatically, the app may remain in its previous state. First confirm that new requests work, then reopen the affected page. An error from an old session alone doesn't prove the route is still down.

Android background management

In system settings, check the client’s battery management, background activity and network permissions. Menu names vary by device, so look for the relevant function rather than copying the steps for a specific model. Allow the client to run in the background as needed, then compare behavior with the screen locked and after returning to the app. Don't remove background limits for every app at once.

Task cleaners, automatic optimization and manufacturer background management may stop the client process. Some systems show connection status separately from the app process, so a persistent notification doesn't necessarily mean the process is healthy. When you return to the app, check whether it restarted and whether the original configuration is still selected. If needed, save relevant system notices; a restarted state isn't evidence of what happened before the disconnect.

iOS network extensions and sleep

In network settings, check the active connection configuration and make sure it isn't an old profile or one created by another tool. The system may change connection state during sleep, network switches or app activity, so a missing status bar icon isn't conclusive. After waking, open a regular webpage first, then check whether the client and destination app each recover.

If only one app stops receiving content after the screen locks, check its background behavior and notification permissions. A restored proxy connection doesn't mean the app will rebuild every session automatically. Use on-demand connection features only if the client actually offers them. If there’s no such option, don't install a configuration profile from an unknown source to add it.

Desktop sleep and persistent connections

Windows, macOS and Linux may retain an old route, stale DNS result or expired session after sleep or a network-interface switch. Stop and reconnect the client normally, then reopen the destination app. If the problem occurs only after waking, note the network before sleep, the network after waking and the connection status. This is more useful for finding interface changes than reinstalling straight away.

Persistent connections in meetings, collaboration tools and apps such as Discord are more sensitive to brief interruptions. A website loading proves only that a new request can complete; it doesn't mean an existing persistent connection was unaffected. Test page access, sending a message and maintaining a session separately. For Midjourney connection issues, see AI Image Generation and Discord Connections.

Don't let repeated reconnects hide the cause

Repeatedly reconnecting by hand may restore service temporarily, but it can erase useful error context and prompt the destination platform to ask you to verify your account again. Save the error and triggering action before reconnecting. If only one route is affected, compare it with another on the same network. If every route drops after the screen locks, address the device’s background settings before switching regions repeatedly.

A “disconnect after screen lock” can involve the client process, system connection and destination app session. Each may recover independently; the status of one doesn't tell you the status of the others.

In your support ticket, say whether the app stays stable in the foreground, whether locking or waking the device reliably triggers the issue, whether switching networks causes it, and whether reconnecting resolves it. Send only relevant, redacted logs—not a full device backup. Background policies on managed devices may be set by an administrator. Support can help identify the issue but can't change your organization’s device policies.

Failed subscription updates and data status

Updating a subscription and connecting are two separate processes. A client may still use saved routes even when it can't fetch an updated subscription. A successful update doesn't guarantee access to a destination website. First check your account status in the control panel, then review the update error and finally check the import format. A failed subscription update doesn't automatically mean the account is inactive.

Use the control panel to verify account status

Sign in to the control panel to check your current plan, its status and your remaining data. If you can't sign in, troubleshoot account access first instead of inferring plan status from old records. VPNTC requires no email address; you can register with a username and password. If there's an account issue, don't create multiple accounts as a workaround—it can make it harder to identify the right order and subscription.

Monthly plans: ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date. To check whether your data should have reset, use the activation and reset information shown in the control panel instead of calculating by calendar month. If you upgrade partway through a cycle, the price difference is prorated by the remaining days. Use the account status shown in the control panel as your reference after upgrading.

Data packages: ¥158/300GB, ¥358/1000GB and ¥658/3000GB. They last until used and never expire. “Never expire” doesn't mean unlimited data; when the data runs out, check your plan status in the control panel. See the Plans page for a full comparison. When troubleshooting, first confirm the type of plan, then check whether the issue involves its duration, data balance or configuration.

Check that copying and importing are complete

Get the current subscription link again from the control panel and confirm which configuration the client is using. Copying may introduce spaces, line breaks or a redirect URL wrapped by a messaging app. Importing through the control panel’s supported method helps preserve the correct format. Don't assemble a link by hand or paste a page title or control panel URL into the subscription field.

A subscription URL grants account access and should be treated like a credential. Hide the entire URL in screenshots, especially the query string after the domain. Tutorials can use an obvious dummy value, but it won't work for a real connection. The example below shows only the field format. Get your actual subscription from your own control panel, not a public page.

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

Check the retrieval path based on the error

If the update times out, first check whether the control panel opens over your current network. Then compare by updating while the proxy is disconnected. Some clients let you choose whether subscription requests use the proxy; check what that setting actually does. Trying to fetch a new subscription through an old route that isn't connected properly can create a dependency loop and repeated failures.

A content-format error may mean the client received a webpage, a network access confirmation page or an incompatible configuration format instead of the expected subscription. Complete any public network access confirmation, then get the import link again from the control panel. Don't paste the response into a public forum; it may contain account configuration and server parameters.

For a certificate error, check the system time and any network security inspection software. For an authorization error, first confirm that the URL is complete and belongs to the current account. Don't guess what the server returned if you haven't seen the exact error. Redact any error before sharing it; support needs to know the type of failure, not see your full subscription URL.

Confirm the selected configuration after updating

After the update, check whether the list changed, whether the current configuration is still selected and whether the previous route selection has become invalid. The client may keep an old selection or choose another route automatically. Don't stop at an “update successful” message. Select a valid route again, connect and visit the service you actually need.

Keep the old configuration’s name and settings before trying a fresh import. Don't export the full configuration to a public location. Before deleting the old entry, confirm that the new one connects and that any apps referring to it have been updated.

If payment is complete but the control panel doesn't show the expected status, check the order history rather than paying again for the same thing. Alipay / WeChat Pay / USDT are supported. Contact support through a control panel ticket about an order issue. VPNTC offers a 7-day no-questions-asked refund; see the Terms of Service. Describe the technical issue and any refund request separately to keep the details clear.

An app won't use the proxy: check split tunneling

If a browser works but one app can't connect, first check whether the app’s requests reach the client instead of assuming every route is down. Apps may use the system proxy, their own proxy settings or a direct connection. Desktop and mobile clients handle traffic differently, so trace the actual request path rather than applying results from another platform.

First check whether the request appears

Open the client’s connection log, then perform a specific action in the app, such as refreshing a list or loading a page. Look for a matching domain, app process or connection entry. No entry doesn't necessarily mean the app isn't online; its requests may be bypassing the current proxy entry. Check the app’s proxy settings and the scope of traffic handled by the client.

If an entry appears, check the matched rule, outbound method and route. If the rule chose a direct connection, first confirm whether that was expected. A target app may use separate domains for sign-in, content, resources and verification. If only some requests use the proxy, the homepage might work while sign-in fails, or text might load while attachments don't.

System proxy and virtual network interfaces

A system proxy usually affects only apps that follow that setting; it doesn't route all traffic on the device. Some apps have their own proxy settings, while others may ignore the system proxy. If the client offers virtual network interface mode, it may handle more traffic, but it also involves routing, permissions and compatibility with other networking tools. It isn't a universal fix.

To test virtual network interface mode, save the original settings, quit conflicting tools normally and grant permissions as prompted by the client. Check whether the target app works again and whether regular websites and local network resources still work. If the device is managed, used for remote work or connected to a corporate tunnel, ask an administrator first rather than overriding existing policies.

Use global mode only to isolate rule issues

If the app works after a temporary switch to global mode, the issue may involve rule coverage, DNS interaction or outbound selection. Save the relevant request log, then return to rule mode and look for the difference. Global mode is still subject to the client’s traffic-handling scope; changing modes won't necessarily catch an app that never uses the proxy entry.

When adding rules, use a format supported by the client and check the order. An earlier rule may match first, so an entry added lower down may never take effect. Don't send an entire public suffix or a broad IP range through the proxy without a specific reason; this can change routes for unrelated services. After editing, check both the target requests and destinations that worked before.

Check terminals and developer tools separately

Command-line tools may use their own environment variables or configuration files; they don't automatically follow the browser. Check whether the current terminal inherited old proxy settings and whether the tool points to a client that has stopped. Test application configuration changes separately from environment variable changes. If both are changed at once, it may be unclear which setting took effect.

The commands below work in terminal environments that support them and show common proxy environment variables. Their output may include internal addresses or credentials, so redact it before sharing. An empty variable doesn't prove a tool is connecting directly; it may read its own configuration. A variable with a value doesn't prove the client is serving connections at that address.

printenv http_proxy
printenv https_proxy
printenv all_proxy
printenv no_proxy

Treat regional prompts separately from network errors

If an app explicitly says a region isn't supported, an account is restricted or verification is required, review the destination service’s rules. Switching routes won't guarantee that an account is eligible. This is especially relevant to AI tools and streaming: reaching a website and having permission to use an account are separate matters. A use-case label also doesn't guarantee access to every platform in every region.

For services such as ChatGPT, keep a suitable exit environment, avoid changing regions without a reason and compare the sign-in page with the conversation page. See ChatGPT Sign-in and Long-Term Use for more context. For video platforms, see the Streaming guide to distinguish access to content from account authorization.

If an app’s request never reaches the client, fix the traffic-handling path. If it reaches the client but uses the wrong outbound route, check the rules. If the outbound route is correct but the platform shows a restriction, check the destination service’s requirements.

For an app-related support ticket, include the app name, platform, action that fails and the results of browser and mode comparisons. Keep relevant domains and matched rules, but hide conversation content, work file names and account details. Support needs evidence of the request path, not your full browsing history. Whenever possible, reproduce the issue with an action that contains no personal information.

Platform differences and “device limit exceeded” messages

VPNTC supports Windows / macOS / iOS / Android / Linux, with no limit on the number of devices connected at the same time. So if you see a “device limit exceeded” message, don't assume it's a limit on your VPNTC plan. First identify whether the message comes from the control panel, client, operating system or destination platform. Note where it appeared and the exact wording, then check the relevant source of the restriction.

Identify which of the three parties applies the limit

A destination service may limit account sessions or playback devices; an operating system may limit active network configurations; and another tool may have its own licensing rules. These are separate from VPNTC’s simultaneous-device policy. Don't buy a higher-tier plan just because a similar message appears. Check which product issued it before upgrading data for an unrelated problem.

If the message appears in the VPNTC control panel or a client using this service’s configuration, save the surrounding details and submit a support ticket. Include the platform and steps to reproduce the issue, but don't share personal names from your device list. No device limit doesn't mean account credentials can be shared publicly; protect your account and subscription.

Compare devices using the same configuration

If another device works, first compare their networks, subscription update times, selected routes and modes. Only once these are similar is it useful to look for differences between operating systems. If the devices use different networks or routes, the results can't directly prove a system issue—or that the account status is identical on both.

If one device fails on the same network while another works, check permissions, system proxy settings, background policies and conflicting software first. If every device fails on one network but works on another, focus on the network path. Test only the devices relevant to the issue; there's no need to reinstall everything. Keeping a working device as a comparison is more useful.

Stale configuration on desktop platforms

On Windows, check that the system proxy points to a running client. A proxy address left behind after an old program exits can stop every browser from working. On macOS, check network extension permissions and the configuration for the network service currently in use; avoid changing an inactive interface. On both platforms, stop the connection normally first, then test direct access after quitting the client.

Linux desktop proxy settings and terminal environments may be independent. If GUI apps work but the terminal doesn't, check the tool’s environment. If the terminal works but the browser doesn't, check desktop proxy and browser settings. Don't replace each tool’s troubleshooting with a global environment file or overwrite system route files just to make settings match.

Mobile platforms and local network resources

Mobile connection permissions, background policies and destination app permissions are separate settings. Permission for the client to connect doesn't mean a destination app can use the network in the background. If local device discovery, local network files or casting are affected, check local network bypass rules. Working international access doesn't prove that local network traffic is taking the same path as before.

Change local network rules only for the current network and actual resource needs. Don't copy address ranges from an unfamiliar network or treat a remote-work network like a home network. Follow your organization’s routing policies for internal resources. If managed settings are involved, ask an administrator which destinations should connect directly and which should use the corporate network.

Use VPNTC’s stated policy as the source of truth: there’s no limit on simultaneous devices. App session limits, system network configuration conflicts and account data status are separate issues, not a single “device limit.”

The control panel download section is the only client download source; this page doesn't provide public installers. Reinstall only after checking configuration, permissions and conflicts. If you need to reinstall, first keep relevant redacted errors and settings, then import your own subscription again. Don't erase all the evidence needed to reproduce an issue before contacting support.

Support ticket details, recovery checks and rollback

A support ticket isn't a pile of screenshots; it should describe a failure that can be reproduced. Explain how things worked before, which action fails now, what comparisons you've tried and the result of each. This helps support distinguish account, access network, route, client and destination-service issues with fewer follow-up questions.

When to contact support directly

Submit a ticket if your control panel account or order status is wrong, you can't retrieve your own subscription after repeated attempts, or the same connection error occurs across multiple routes and networks. Also stop retrying and check with support if you see a certificate error, an unexpected authorization prompt or signs that configuration details may have been exposed. For permissions on a managed device, contact your administrator too.

If only one website or app fails, compare browsers, routes and modes first. If it fails only on one network, note the network type and whether access confirmation is required. If it fails only after the screen locks, note whether it works in the foreground. You don't need to complete every step in this guide before asking for help; share the useful evidence you already have.

Include enough detail to protect your credentials

Submit through a control panel support ticket, not a public comment. Include the platform, the name shown in the client, selected route, mode, time and time zone of the issue, target domain and exact error. Share only the device details needed to diagnose it; full hardware serial information isn't necessary.

Don't include subscription URLs, passwords, access credentials, payment details or full configurations in screenshots or logs. Check the browser address bar, QR codes, configuration details and query strings—not just the text in the page. If a log contains request content, share only the connection stage or matched rule where possible. Don't expose work files or private conversations.

Time details matter especially for intermittent and peak-hour issues. Give the local time and time zone when it happened, and say whether you were on Wi-Fi, Ethernet or another type of connection. Use the route name exactly as it appears in the client, not a nickname; otherwise support may not be able to match the issue to the route and time.

Describe how to reproduce the issue in a consistent format

A reproduction report should include the steps, expected result and actual result. For example: start the client, select a route and mode, open the destination page, then note the error. Don't just write “it doesn't work.” If the issue isn't consistently reproducible, describe the conditions from the most recent occurrence and make clear which details are recorded and which you remember.

Support ticket details: symptom and triggering action; platform and network type; route and mode; exact error; time and time zone; comparisons already completed; whether the issue still occurs.

Attach only what's needed to diagnose the issue. Before submitting, check that subscription URLs, QR codes, account credentials, private domains and business documents are hidden.

Don't repeat an action for a support ticket if it could affect your work or account. A disrupted meeting, payment flow or sensitive sign-in isn't suitable for repeated testing. Use a regular webpage or an action without private content to check the route instead. Support needs a clear description of the network issue, not actual conversation content, meeting recordings or complete business requests.

Retest the real-world scenario after recovery

After the client connects, check website access first, then retest the destination and action that originally failed. If the issue happened in the background or after waking, repeat that trigger. If it happened in rule mode, restore rule mode and test again. Opening a homepage only in global mode doesn't prove that app routing, background connections or resource loading are fixed.

Confirm that the exit region, destination-service prompts and request rules are as expected, then test sustained use. The recovered route doesn't have to be the same one you started with, but note which combination now works. For platforms sensitive to sign-in location, don't switch through several regions just to prove the issue is “completely fixed”—that can trigger new account checks.

Keep a rollback option and undo changes that didn't help

Review each temporary change made during troubleshooting, including DNS, address family, global mode, background permissions and app proxy settings. Keep a change only if it helped and you understand what it does; restore the original value if it didn't. Don't leave multiple temporary fixes in place, or it will be harder to know what’s needed the next time something goes wrong.

If recovery depends on a temporary workaround, update your support ticket instead of marking the issue fully resolved. Note which network, platform and destination the workaround applies to, and distinguish “working for now” from a confirmed cause. If support suggests another change, alter one variable at a time, compare the results before and after, and keep a way to roll back.

If you’re unfamiliar with key terms, see Subscription, Routes, Protocols and Split Tunneling: Quick Reference. To go over the setup process again, return to the Getting Started Guide. This page explains troubleshooting paths; it doesn't replace your account control panel or the destination platform’s rules. Use account status, the actual request path and retest results together to confirm recovery.