VPN Troubleshooting Guide

Can't connect at all: identify the cause

Turn “can't connect” into a symptom you can verify

A client stuck on “connecting,” an immediate error, and a connected status with no access are different problems. Note what changes on screen after you tap Connect, and save the exact error message. Don't confuse a failed subscription import with a connection failure: if no routes appear in the list, the configuration isn't ready; if routes are listed but the selected one won't connect, follow this section. Check both the client's connection status and whether you can actually access the internet. A VPN icon in the system status bar only indicates that the related network interface is enabled.

Pause the proxy and use your current network to open a website you can normally access. Check whether you need to complete a sign-in step for the public Wi-Fi. If the basic connection isn't working, troubleshoot Wi-Fi, network authentication, or the router before trying different routes. A public network's sign-in page may not load while the proxy is on; disconnect temporarily, complete network access in your browser, then try connecting again. Never enter your MingVPN account password on an unfamiliar network sign-in page.

Narrow it down with cross-checks

Keep the client configuration unchanged and test on another available network. Then keep the network unchanged and select a different route in the panel. The first check shows whether the issue follows the network; the second shows whether it follows the route. If switching networks fixes it, note the original connection type and authentication requirements. If only one route fails, keep its name and stop changing system settings. Changing several things at once makes the result hard to interpret—for example, if you switch networks and update the subscription together, you won't know which change fixed it.

Next, check the plan status and remaining data in your account overview, and confirm that the subscription in the client belongs to the account you're using. A completed payment doesn't guarantee that an old configuration in the client is still valid; order status, plan status, and configuration import are separate steps. If your account status looks wrong, check the account dashboard overview rather than repeatedly creating accounts. You can create an account with a username and password—no email address required—but use the original account when checking an old order.

Check system permissions and overlapping network controls

The first time you connect, your system may ask you to allow a VPN configuration or authorize a network extension. If you deny permission, the client may still show a route list but won't be able to activate the network interface. Open system settings, check for permission prompts related to the client, and follow its instructions. On a device managed by your employer or school, these permissions may be controlled by policy. Ask the device administrator what use is allowed; don't remove management profiles yourself.

Running multiple proxy clients, an old system proxy, and other VPNs at the same time can send traffic through the wrong local entry point. Exit other network-control tools normally, leave only the current client running, and check again. If you need to investigate security software, review its block log or create a specific allow rule for the trusted client; don't disable all protection. An incorrect system clock can also affect certificate checks. Restore automatic time sync using the system setting and try again rather than turning off certificate verification.

When to stop troubleshooting locally

If the same connection error occurs on multiple networks, devices, and routes—and you've confirmed the account and configuration—submit a support ticket. Include when it happened, the route name, the exact error, your platform, and the cross-checks you've completed. You can also submit a ticket if the issue occurs on just one network, but say whether other networks work. Reinstalling repeatedly isn't a substitute for troubleshooting; it can erase logs and remove existing permissions, configurations, and environment details.

Once connected, retest the same website and check that a regular site you could access before still loads. If the connection succeeds but websites still fail, go to the next section to check DNS, routing rules, and certificate warnings. This distinction avoids further troubleshooting account or permission issues after the connection is already established, and helps support determine whether the problem happens before or after connection.

Connected but can't open websites? Check routing and DNS

First determine whether all websites fail or just one

Once the client shows Connected, try both a regular website and the site you want to reach over an international route. If regular sites work but the target site doesn't, first check whether its traffic is being routed through the proxy and whether the selected exit is suitable for that service. If no sites work, check the system proxy entry point, DNS, and network interface. A DNS resolution error, connection timeout, certificate error, and access denied message mean different things. Keep the full error when reporting the issue; don't send only a screenshot of a blank page.

Try the same address in another browser, or compare the service's website with its app. A problem in just one browser may be caused by an extension, proxy settings, cache, or separate secure DNS settings. If all apps fail, the issue is more likely at the system network level. Before clearing your cache, try a separate browsing session, but keep in mind that your sign-in state may change: a signed-in service page and its public pages may follow different access rules, so a change in account state can look like a route issue.

How to confirm a DNS issue

DNS translates domain names into network addresses. A connection in the client doesn't guarantee that your browser is using the expected DNS resolution path. Your browser's secure DNS, encrypted system DNS, the client's built-in DNS, and your router's DNS settings may all be in play. First check the client log for a domain resolution error, then see whether the browser uses its own DNS settings. Don't enter a DNS address you found online at random; check the current client documentation to confirm the resolution method and when it applies.

You can use a system command to look up a public domain and see whether it resolves. The command below doesn't include account information or change network settings. Its result only shows whether the DNS path used by that command is working; it can't prove that the browser, apps, or proxy use the same DNS path. Some clients resolve domain names inside a virtual interface, so the system lookup may differ from actual proxied requests. Check the access log as well.

nslookup example.com

Check routing, certificates, and exit region

Open the client's connection log and check which rule matched the domain and whether the request went direct or through the proxy. If it was routed directly, check the rule mode and whether the rules have updated. You can temporarily switch to the client's global proxy mode as a comparison to see if routing rules are the cause, then restore your usual mode. Global mode changes the network path for other apps, so it shouldn't be used long term as a workaround for an unresolved issue. Pay particular attention to its impact on local network services.

Handle certificate warnings separately. Check that the system clock is correct, the domain in the address bar is spelled correctly, and the browser isn't on a public network sign-in page. If only one site's certificate is invalid, check that site's service notices first. If several legitimate websites show certificate problems at the same time, check local security software or certificate handling on a managed network. Don't install an unfamiliar certificate or disable browser checks just to load a page; that changes the scope of troubleshooting and increases the risk of exposing your information.

What DNS checks can—and can't—tell you, and what to send support

IP lookup can help identify the exit used by a web request, but one IP lookup is not a full DNS leak test and doesn't cover every app. To check the DNS path, review the client log, browser settings, and system configuration together. After making a change, reopen the target app, let its existing connections close, and test again. Otherwise, it may keep using an old cache or session, making it look as though the change didn't work.

If the issue persists, tell support whether all websites fail or only a specific domain. Include the error type, current proxy mode, selected region, and the result for a regular website. Don't attach your full browsing history; include only requests related to the problem and remove personal information from URLs. If the target service restricts account regions or access methods, a working MingVPN connection doesn't replace the service's own usage requirements.

Slow speeds and peak-hour slowdowns: compare conditions

Break the wait into observable steps

“Slow” might mean a website takes too long to open, video buffers, downloads crawl, or interactions pause occasionally. First specify which task is affected. A slow first page load can involve DNS, establishing a connection, or the server response. Slow transfers after they start call for a closer look at local bandwidth use, the exit route, and the destination server. Don't judge the whole experience by a route name or a single speed test, or assume one website's performance represents every route.

Use the same device, network, and task, then compare a different route. During the test, pause unnecessary cloud sync, file transfers, and background updates that compete for bandwidth. Switching routes won't fix local congestion if other devices at home are transferring data. If your Wi-Fi signal is unstable, improve the connection or switch to a more reliable one. Confirm regular internet use works normally before comparing international routes.

Route types are options, not speed guarantees

MingVPN offers IEPL, relay, and direct routes; available options are shown in the panel. Use an IEPL route to compare path stability when it matters, a relay route to compare traffic forwarded through an intermediate path, and a direct route to test another connection path. A route type doesn't guarantee a fixed speed or ensure that a particular service will always accept its exit. See the Nodes page for route selection guidance, then test against your actual use case.

How to document peak-hour issues

If slowdowns happen only during peak hours, compare the same task at another time of day. Note when it happened, how you connected to the internet, which route you used, and what you observed. There's no need to test every route one after another. If switching networks fixes the problem, shared load or the path on the original network may be a factor. If the other network is still slow but a different route works, the route is worth investigating. “It doesn't work well at night” doesn't distinguish between time, network, and destination service.

A nearby region isn't necessarily a smoother route, and a farther one isn't necessarily worse. Start by comparing available regions in the panel, such as Japan, Singapore, or Hong Kong, then adjust for the target service's requirements. Coverage of 90+ countries / 150+ routes describes the available selection; performance won't be the same for every service in every region. Keep the routes that suit your tasks rather than cycling through every region. Frequent exit changes may also prompt the target service to recheck your sign-in.

Assess streaming and interactive apps separately

If video stutters, check whether the player is adjusting picture quality, whether downloads are running, and how the same video performs on another route. Access to a catalog, account region, and sustained streaming are separate issues: being able to open a catalog doesn't guarantee smooth playback, and a playback error doesn't necessarily mean you lack bandwidth. For regional catalogs and streaming bandwidth requirements, see the Netflix regional catalogs and bandwidth guide. This page doesn't promise any particular picture quality.

If an AI tool or other interactive service takes a long time to respond, distinguish between a page that won't connect, a request that failed to send, and a service that accepted the request but hasn't returned a result. The last case may involve the platform's processing queue, account limits, or service status; switching routes may not help. Save the message and check the platform's guidance to avoid submitting duplicate tasks. For connection checks in these scenarios, see the AI access guide.

If the issue persists across different times and routes, submit a reproducible task and its results. Plan data limits and route speed are different metrics, so upgrading a plan shouldn't be the default fix for an unknown performance issue. Support needs to know which condition the problem follows to investigate the route. If every network task is slow, check your local connection first instead of attributing an access-side issue directly to the subscription service.

Frequent disconnections and mobile background drops

First determine whether the network interface or app disconnected

A paused video, an app asking you to sign in again, and a disconnected client aren't the same issue. When it happens, check whether the client still shows Connected, then see whether other websites work. If only one app disconnects, its session or server connection may have ended. If the client disconnects too, focus on network switching, system background limits, and client logs. Don't rely on the status bar icon alone: some systems keep showing it while the interface is active even if the route needs to reconnect.

Check whether the problem consistently follows locking the screen, switching apps, leaving Wi-Fi, or waking from sleep. These actions can change the device's network or process state. If the device switches between Wi-Fi and another connection, the existing connection may need to be re-established. Whether an app retries automatically depends on the client and target app. For a clear comparison, keep the network unchanged and confirm that the connection stays up while the app is in the foreground. Then test screen locking and network switching separately.

Android background and battery settings

Android background behavior varies by system and device manufacturer. Open the app info for the client and check battery use, background activity, and background data permissions. If your system offers an option to allow background activity, check the client documentation for the required setting. Menu names differ, so you don't need to follow a screenshot from another device. After making a change, restart the client and confirm that the system still allows it to establish a VPN connection. Then test with the screen locked rather than checking only while the app is open.

Don't disable battery restrictions for every app at once. Make only the necessary changes for the client you're troubleshooting, and keep a note of the original settings so you can restore them later. If the client is stopped in the background, reopening it may create a new interface instead of reusing the old connection. Record the client status and any system messages before and after locking the screen. For more on background operation and app-specific settings, see the Android clients and battery settings guide.

What to check on iOS and desktop platforms

On iOS, distinguish between closing the app and disconnecting the system VPN configuration; closing an app window doesn't always stop the network extension immediately. Check the VPN settings and client messages to confirm the actual connection state. Note Low Power Mode, network changes, and device management policies, but don't assume that a particular setting caused the disconnection. If the device has other VPN configurations, check which one is active and avoid switching between them without recording the results.

On Windows, macOS, and Linux, the system proxy or virtual interface may need the client to take control again after sleep or a network reconnect. Disconnect and reconnect normally first, then check whether service resumes. If a device only recovers after a restart, review the logs for messages about interface creation, permissions, and routes. Don't manually delete all routes or network interfaces; this can affect other apps. If regular internet access is still broken after closing the client, check for leftover system proxy settings.

Use the recovery process to gather more evidence

After a disconnection, don't immediately switch routes repeatedly. Note whether the client tries to reconnect, which apps still have issues after it recovers, and whether reopening an app helps. If the client is back online but an app is still using an old session, close the app normally and reopen it for comparison. If you have to reimport the subscription just to restore service temporarily, check the configuration in the subscription section; repeated imports aren't a way to keep the client running in the background.

If disconnections happen frequently but aren't related to screen locking, compare another route and another network connection. If the issue follows just one route, provide its name and connection log. If it follows just one device, provide the platform, client name, and any changes to background settings. Don't keep the screen on indefinitely to prevent disconnections or install unfamiliar tools that claim to remove all system restrictions. Limit troubleshooting to settings provided by the system and trusted client.

In your support ticket, describe the complete sequence of events—for example, browsing works in the foreground, the client disconnects after the screen locks, and reconnecting works after unlocking. Specific actions are more useful than “it disconnects a lot.” If the device is managed by an organization, mention its management policy and check with the administrator about network permissions first. Support can help investigate the service connection, but can't change device policies or guarantee that every app will maintain a background session.

Subscription update failed: download or parsing?

A failed update doesn't mean the route is down

A subscription update has two stages: requesting the configuration and parsing it. A network timeout, an account message, and content the client can't recognize each call for a different response. Keep the exact error from the client and confirm whether the failure happened during download or parsing. If an existing route still connects, the current configuration may still work for now, but that doesn't mean the subscription update succeeded. Don't immediately delete the only working configuration; back up anything you need and check the account first.

Open the account dashboard to check plan status and remaining data, then get the subscription again from the account you're using. A subscription URL contains access credentials and should be protected like a password. Copy the complete value provided by the panel; don't retype it from a chat screenshot or use an address that was shortened for display. Newlines, leading or trailing spaces, or other copied text can cause the client to reject it.

Checks during the download stage

Update requests may go direct or use the current proxy, depending on the client. If the selected proxy route isn't working, the client may be unable to download the update through it. First confirm that regular internet access works, then check whether the client offers a setting for how updates connect and compare according to its official instructions. Don't paste a subscription URL into a third-party checker or converter. That takes configuration credentials outside your account's control and adds another service to the troubleshooting process.

If the panel opens but the client can't fetch the subscription, note the difference between loading the panel in a browser and updating in the client. They may use different DNS, proxy entry points, or system permissions. If your plan recently changed, confirm the new status appears in the panel before requesting the configuration again. Don't place repeated orders to fix a sync issue. The client may also have cached an old address; check the name of the item being updated so you don't update a backup configuration while continuing to use another old one.

Check parsing compatibility and configuration

If the client downloads content but reports a format error, check that the import method matches the client you're using. Clients can support different configuration formats and import options, so don't assume one address can be pasted into every tool. Use the panel's option for your client, or follow this site's instructions for a supported import method. Don't save a web error page as a configuration file and keep importing it. The client may be receiving an account or network message page instead of subscription data.

If you manually edited rules, proxy groups, or configuration fields, compare against an unmodified copy of the original configuration first. Keep the old configuration so you can restore it, but don't change several parts of the same configuration at once. A bad parameter can prevent the entire configuration from loading. The field name and parsing location in the log are more useful than the general “import failed” message. If you need to share a configuration snippet, remove the subscription URL, credentials, and personal information. Keep only fields related to the format error and the error message.

Check download access and subscription access separately

Find client downloads in the account dashboard download page. Once signed in, you can download for Windows, macOS, Android, and Linux. A sign-in is required to get a subscription; iOS downloads also require an active plan. Being able to download a client doesn't mean the account has a usable subscription. Likewise, a working subscription doesn't prove that the installed client is configured correctly. For the full first-time import process, go back to Quick Start.

If you suspect your subscription URL has been exposed, use the relevant account management option in the panel and import the updated configuration. Available actions and their location depend on the panel. After the old URL is invalidated, devices still using the old configuration may need an update. Don't repeat the exposed URL in a support ticket to prove what happened; describe the incident and the steps you've taken. See the VPN security guide for beginners for account and link security tips.

If the same update error persists after checking your internet connection, account status, URL, and client compatibility, submit a support ticket. Include when the update happened, your platform, client name, import method, whether the error occurred during download or parsing, and results using an unmodified configuration. If the error only occurs on a particular network, say whether the update works on other networks. This saves support from repeating checks you've already completed.

One app won't use the proxy: check its route

A working browser doesn't mean every app uses the same route

If a browser can reach a website but an app can't connect, start by checking the exact error from the app. It may use separate domains or a different network library, ignore the system proxy, or reject the request because of account region, sign-in state, or server rules. Don't immediately conclude that the route doesn't support the app. When comparing a service's website and app, use the same account state and equivalent actions where possible. Opening a public homepage isn't a fair comparison if the app is requesting an account-restricted feature.

Check whether the client logs a connection for the app. If there are no related requests, first check whether the app is excluded, is still using an old connection, or isn't covered by the client's current mode. If there's a log entry, check the matching domain rule and exit route. If the request went through the proxy but still failed, investigate the target service's message and the route region rather than continuing to change app-specific settings. Filter logs around the steps that reproduce the issue; you don't need to collect all network activity from every app.

System proxy vs. virtual interface

A system proxy is typically used by apps that follow system settings; not every program does. A virtual interface mode offered by the client may route more traffic, but check the client documentation to confirm what's supported and how to authorize it. Before enabling it, check existing rules and other network tools. After enabling it, make sure local network services still work. Don't copy route fields or permission commands from an unfamiliar configuration, and don't enable multiple virtual interfaces at once.

If the app works after you temporarily switch to global proxy mode, review the routing or exclusion settings; that doesn't mean you need to stay in global mode. Identify the affected request and rule, then switch back to your usual mode and test again. If it still fails in global mode while the browser works, look more closely at the app's network path and the target service's account requirements. For work apps, also follow your organization's access rules. The client's ability to route traffic doesn't replace organizational authorization.

App lists and old sessions

An Android client's per-app list may mean “proxy only these apps” or “exclude these apps.” Read the interface description to confirm the current mode; don't guess based on which apps are checked. Review the list again after app updates or installation changes. After changing it, fully close the target app and reopen it to establish a new connection. Returning to the home screen often leaves the old session running, so you may not see the change right away.

On iOS, system VPN settings and client capabilities together determine how traffic is routed. Don't promise that typical users can set a separate route for every app. First check the rules in your client, then see whether another VPN configuration is active. For App Store region and client import questions, see the iPhone clients and configuration profiles guide. Don't confuse an App Store region restriction with a network issue in an installed app.

Terminals, services, and target platform restrictions

Command-line tools on Linux and desktop systems may use environment variables instead of the desktop system proxy. When a terminal starts determines which environment it inherits; existing terminal sessions may not pick up later changes to system settings. Check the tool documentation for its proxy options, then confirm which entry point it actually uses. Don't set a fixed local port without knowing the client's listening settings. Background services and interactive terminals may also have different environments, so test them separately.

If the logs show that an app's request went through the proxy but it still reports a region, account eligibility, or access restriction, check the target platform's requirements. Trying another exit region can help with comparisons, but can't be guaranteed to remove every platform restriction. Frequent region changes may also trigger another sign-in check. In your support ticket, include the app name, action that failed, exact message, proxy mode, and matching rule. Distinguish between no request in the log, a direct request, and a request that went through the proxy.

Check account, data, and device notices

First identify the order linked to your current account

If you see a plan unavailable, low data, or device-related message, open the account panel and check the signed-in username, plan status, and order status. Your browser may still be signed in to another account, and the client may be using a subscription from an old account. A payment screenshot can help with an investigation, but it doesn't replace the order and plan status shown in the panel. Don't create another account or pay again just to troubleshoot; first confirm that the original order is linked to the account you're using.

If the payment process was interrupted, return to the order page and check its current status, then follow the panel's instructions. Payment methods are Alipay / WeChat Pay / USDT; follow the on-page steps for your payment method. For support to check a payment, you can provide the order reference and a screenshot of its status, but hide your balance, personal payment details, and unrelated transactions. Never share your payment password in a chat, and don't use a subscription URL as proof of payment—it doesn't replace the order record.

Checking monthly plans and data packages

Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on the activation date. Don't estimate the reset date from the start or end of a calendar month; check the activation and reset status in the panel. If your plan is still active but you've used all the data, importing the configuration again usually won't restore it. For plan options, visit the Plans page. Check whether the issue is the plan period or data allowance before deciding what to do.

Data packages are ¥158 for 300GB, ¥358 for 1000GB, and ¥658 for 3000GB. They last until the data is used and never expire. Never expiring doesn't mean the data is unlimited; once the balance is used up, follow the instructions in the panel. When troubleshooting, confirm whether your account uses a monthly plan or a data package. Monthly reset rules don't apply to data packages. Local transfer statistics in a client may not match your account balance; use the account panel to check remaining data.

If several devices are online at the same time, check each one for cloud sync, app updates, downloads, or other ongoing transfers. Background data use can happen even if you haven't opened a video yourself. Stop any tasks you can identify and check the panel again; don't assume this proves a billing error. If you still think the usage record is wrong, provide the relevant time period, device activity, and a screenshot of the panel. You don't need to upload your full browsing history or ask someone else to sign in to your account to test it.

Don't take a “device limit exceeded” message at face value

MingVPN has no device limit for simultaneous connections. If you see a “device limit exceeded” or similar message, don't assume that MingVPN imposes another device allowance or suggest upgrading to add devices. First check whether the message comes from the MingVPN panel, the current client, or the target app. Client activation limits, another service's account rules, and a target app's session policy can use similar wording. Identify the source before attributing it to the subscription service.

Check whether the client is using a subscription from your current MingVPN account and whether configurations from other services are still saved. If the message comes from a target website, check its device or session requirements. If it comes from a client feature authorization, consult the client documentation. Don't delete every device in an attempt to clear a message from an unknown source; that destroys useful evidence and could affect configurations that were working.

When upgrades, refunds, and connection issues are separate

For a mid-term upgrade, the price difference is converted into remaining days. Check the panel for the exact account status. After upgrading, verify the plan and configuration again; don't estimate the resulting data or validity period from the price difference. An upgrade changes billing; it isn't a general fix for DNS, system permissions, or background disconnections. If the original issue still reproduces, keep the before-and-after status so support can distinguish an account change from a network change. Don't just report that you switched plans.

This service offers a 14-day, no-questions-asked refund. See the Refund Policy for how to request one. You can describe connection troubleshooting separately from a refund request; you don't need to provide excessive personal information to prove a problem. If the panel shows the correct plan and the configuration is from the right account but you still see an account or device restriction, send support the full message, where it appeared, your order reference, and the checks you've completed. Don't share full account details in public comments.

Submit a support ticket and retest after the fix

When to ask support to investigate

If you've completed the basic checks related to the symptom and can still reproduce the issue, submit a support ticket. You don't need to perform every step in this guide. Examples worth investigating include being unable to connect on multiple networks, the same configuration failing on different devices, a mismatch between the account status and the message shown, or a specific route repeatedly producing the same error. You can ask for help if the problem clearly follows one device too, but say whether other devices work so support can distinguish a local environment issue from a service-side one.

Open a ticket on the account dashboard support page. Use a title that describes the symptom and scope, such as “Subscription update fails while parsing” or “Client disconnects when screen locks,” rather than “Nothing works.” In the message, describe the conditions and exact error first, then list the checks you've completed. Don't invent a diagnosis or copy in lots of networking jargon. Reproducible facts are more useful than a guess about which layer is failing.

Provide enough detail, but not too much

Include your platform, client name, network type, selected route, and proxy mode. Provide your actual system and client versions from your settings; don't copy version numbers from this guide or someone else. Include the time and your local time zone so support can match its records. Describe the network as home, public, or managed; you don't need to provide your address. Screenshots should show enough context to be useful while hiding personal information and unrelated apps.

Describe one complete reproduction: the starting state, what you did, what message appeared, and what restored service. Then list comparison results, such as whether the same device worked on another network, whether the same network worked with another route, and whether the service's website and app behaved differently. Don't just say “I tried everything,” and don't claim checks passed if you didn't do them. If a permission or environment prevented a check, say that it wasn't tested and explain why.

Symptom: The client shows disconnected after the screen locks
Environment: Enter your actual platform, client name, and network type
Route: Enter the route name shown in the panel
Reproduction: Browsing works in the foreground; a disconnection message appears after the screen locks
Comparison: Enter the actual results from switching networks, routes, or devices
Checks completed: Enter the permissions, background settings, or configuration checks you actually performed
Attachments: Screenshots of the error and relevant logs with account information hidden

How to capture and redact logs

Find the log or diagnostics section in the client, reproduce the issue as instructed, and save the relevant entries from before and after it happened. A full log may contain domains, network addresses, configuration paths, or subscription credentials; review it carefully before sending. Remove or redact the full subscription URL, access credentials, passwords, and personal information. Keep the error category, event sequence, and route names related to the problem. If you're unsure whether something is sensitive, send a screenshot of the error first and ask support which fields they need.

Don't upload a full configuration to a public file-sharing service or post diagnostic files in a public forum. If support needs more information, add it through the account dashboard ticket and make sure the request relates to your issue. Remote troubleshooting is never a reason to share your account password. For basic account and subscription security, see the security guide for beginners. Sharing only what's necessary helps protect your account and makes your ticket easier to review.

Retest after changes and roll back if needed

After you receive troubleshooting advice, make one change at a time and retest under the original conditions. Record the results before and after each change. Once service is restored, check a regular website, the target website, and the app that was affected. If you changed proxy mode or DNS, confirm that your usual routing and local network services still work. If you changed background settings, test with the screen locked rather than checking only in the foreground. Don't declare everything fixed just because one page opens.

If nothing improves, add the failed result and the steps you took to the same ticket. Don't keep changing settings based on advice from different sources; that leaves support with a constantly changing environment. Save the original settings before making changes and restore them normally if needed. Confirm you have permission before changing system-managed settings. If reimporting the client configuration restored service, use the subscription import and connection verification guide to check the full setup again.

Finish with a brief summary of what the issue follows, what helped, and what you haven't been able to test. If it happens again, start by comparing your notes instead of reinstalling everything. Routes and target service conditions can change, so recheck methods that worked before. This handbook provides a troubleshooting sequence, not a guarantee for every network environment. Clearly documenting the scope, steps, and retest results is the most important part of troubleshooting.