VPN Troubleshooting Guide

Can't Connect at All: Find Where It Fails

“Can't connect” can mean the client won't start, an error appears when you tap Connect, or it stays stuck on Connecting. Start by describing exactly what happens: Does the subscription list appear? Can you select a route? Does the system ask for permission? Does the failure happen before or after you tap Connect? These details are more useful than reinstalling repeatedly. For now, don’t delete your account, clear your settings or pay again. A connection issue by itself doesn’t mean your plan has expired.

Check your internet connection without the VPN

Disconnect normally in the client, then visit a local website you can usually access and check that your device shows an internet connection. If local sites won’t load either, check your Wi-Fi signal, router connection or network sign-in page first. Public Wi-Fi may require you to confirm access in a browser, and the VPN can prevent that prompt from appearing. Complete the sign-in before connecting. Managed workplace or campus networks may have access policies; ask the administrator what’s allowed rather than changing managed settings yourself.

If your basic connection works, try another available network for comparison. Keep the device, client and selected route the same; change only the network you connect through. If the result changes with the network, investigate the original network environment before switching accounts. Keep any data charges from the network itself in mind. If every device has trouble on one network but works on another, that’s especially useful evidence for narrowing down the cause.

Check your account status and system permissions

Check your plan’s status and remaining data in the user panel, and confirm the client is using the subscription for your current account. Seeing routes in the subscription doesn’t necessarily mean the account can connect; an old configuration may still be stored locally. If the status looks wrong, read the panel message before deciding whether to update the subscription or address your plan. See the Plans page for prices and billing rules. There’s no need to place another order just to test a connection.

Check permissions for the platform you’re using. On Windows, see whether the client asks for elevated permissions or a network component to be installed. On macOS, check for a network extension awaiting approval in System Settings. On iOS and Android, check whether the app is allowed to add a VPN configuration. On Linux, check the status of the network service and required components. Menu names vary by system, so follow the prompts on your device. Approve requests only from the official HiHiVPN client; don’t grant access to unfamiliar software.

Check whether one route or all routes are failing

Once the account and permissions check out, manually select a route and try again, then compare it with another route type in the same region. Don’t use automatic switching while diagnosing a route, since the actual exit may change. If only one route fails, note its name, type and error. If all routes fail, recheck your local network, system permissions, other proxy apps and subscription status first. When route names look similar, make sure you’ve selected a different entry.

Quit proxy, network-filtering or acceleration apps you aren’t using for now. They may compete to control the system proxy or virtual network interface. Pause the relevant features to test; don’t uninstall security software or leave system protection disabled. If the error mentions a certificate, time or handshake, check the device date, time zone and automatic time setting. Don’t “fix” the connection by ignoring certificate checks—that can hide the real cause.

Check in this order: internet connection works → account and data are in good standing → system permissions are granted → other network tools are paused → routes are compared manually. When something changes, follow that branch first.

If every route still fails after you switch networks, and the system permissions are granted and the subscription updates normally, contact support. Include the stage where it fails, the exact error text and the comparisons you’ve already tried. Don’t just say “it doesn’t work,” and don’t include your full subscription URL in a screenshot. Support needs conditions they can reproduce, not your account credentials.

Websites Won't Load: Check the Connection and DNS Separately

A Connected status in the client only means the tunnel or proxy process has connected. It doesn’t guarantee that your browser’s requests are going through it or that the destination website accepts the current exit. First check whether no websites load, only international websites fail, or just one domain is affected. Note whether the browser says it can’t find the address, timed out, reports a certificate problem, or shows a message from the website itself. Each type of error points to a different part of the connection.

Rule out browser and website issues first

Close the problem page and reopen it, then compare with another browser or a fresh browsing session. A private window can help isolate some session and extension issues, but it won’t clear every network state or prove that your privacy settings are correct. If only your usual browser has trouble, check proxy extensions, content filters and the browser’s secure DNS setting. Pause and test them one at a time so you don’t mistake a browser setting for a route-wide failure.

If just one website fails, check whether it displays a service outage, account verification or region-related message. If it loads after you change routes, that only shows the exit path or region conditions have changed; it doesn’t guarantee the site will keep accepting that exit. For AI Tools and Streaming services, also check account eligibility, service regions and platform rules. If the site has already returned an error page, changing local DNS is unlikely to help.

Understand how the system, browser and client resolve domains

DNS translates domain names into addresses that devices can connect to. Your system may use a resolver provided by your network, your browser may have its own encrypted DNS feature, and the client may handle DNS requests according to routing rules. Different settings at each layer can lead to a browser working while an app fails, or different results for the same domain in different programs. Before troubleshooting, note your current settings. Restore the client’s recommended defaults first rather than copying DNS addresses from an unverified source.

You can use your system’s built-in tools to check whether a domain resolves. The command below only looks up an example domain; it doesn’t test the target website or tell you which region your traffic exits from. Windows, macOS and most Linux systems have suitable tools. If yours doesn’t, use the system’s network diagnostics instead; there’s no need to install software from an unknown source just to troubleshoot.

nslookup example.com

A timeout means the current DNS query path didn’t get a response in time. If an address is returned but the browser still can’t load the page, check proxy routing, the connection to the destination or its certificate rather than assuming DNS is fine. The client may use a different DNS mechanism internally, so the command result is only a clue about the system’s DNS path. Comparing results before and after connecting, and across different networks, is more useful than looking at one output in isolation.

Cache, certificates and dual-stack networks

After changing DNS settings, old cache entries can cause inconsistent results for a while. Fully quit and reopen the relevant apps; if needed, clear the DNS cache using your system’s official instructions. Don’t run unknown “network repair” scripts or reset all network settings at once, since a reset may remove existing connection settings. If your browser reports an invalid certificate, check the device time, the domain spelling and whether you’re on a network that requires sign-in. Don’t ignore the warning to access sensitive pages.

Some networks support more than one address family, while the proxy’s routing coverage, DNS responses and the destination’s support may not line up. If certain domains or apps keep failing, note whether the client’s virtual network mode is enabled and whether you have custom network settings on your system. Don’t permanently disable system networking features for convenience. Restore the recommended settings first, then share the differences with support.

Resolving a domain doesn’t prove the request went through the proxy, and seeing the expected exit region doesn’t verify the DNS path. Use the IP lookup page to check your exit, but don’t treat it as a full DNS leak test.

If the issue happens consistently, note the domain, browser error, results before and after connecting, and the type of network you’re using. The domain alone is enough; don’t include a full URL that could reveal private search terms, account details or access tokens. If the browser and DNS checks don’t help, use the checklist at the end of this guide to contact support.

Slow Speeds: Compare Like with Like

Slow speeds don’t always point to the route exit. Wi-Fi signal, network congestion, device performance, background uploads, destination-side limits and the download server itself can all affect performance. Start by identifying what feels slow: a webpage’s initial load, images loading progressively, file downloads, or video buffering after playback starts. Don’t use one speed-test result to describe every app, or treat response information in the client’s route list as real-world download capacity.

Check your local connection and the destination first

Pause unnecessary cloud sync, system updates and large transfers, and check whether other devices are using the same network. When uploads max out, webpages and interactive apps can feel sluggish too. Test somewhere with a stable signal; if possible, compare with a wired connection. Don’t move the device, switch routes and compare results all at once. The network conditions would keep changing, making the cause hard to identify.

Keep the device and network the same. First visit a local service you normally use to check your baseline, then connect the proxy and try the destination. If it’s slow even when disconnected, focus on the local network. If only one download URL is slow, compare it with another public file on the same site or a different site. The destination server may assign different resources by region, account or content type. Use ordinary content you can access repeatedly, rather than repeatedly loading private pages.

Choose a route by region, type and use case

Geographic distance isn’t the only factor when choosing a route. A nearby region is a good place to start, but the path from your network to the entry point, the cross-border segment and the path from the destination service to the exit can all affect results. Keep the destination the same, compare the actual experience on an IEPL dedicated route, a relay and a direct route in the same region, then decide whether to try another region. Route types describe how paths are set up; they aren’t a speed ranking that holds for every user and time of day. The name alone doesn’t tell you how well a route will perform.

HiHiVPN covers 90+ countries and offers 170+ routes, but you don’t need to test every entry. Start with comparisons that reproduce the difference, then check regional and route-type details on the Network page. For general route selection tips, see How to Choose a VPN Route. A long list of favorites doesn’t mean the routes have been tested.

Check responsiveness, sustained transfers and device load separately

Chats, remote interactions and switching between webpages make delays more noticeable. Large downloads depend more on sustained transfer speed, while video performance also depends on caching and content delivery. The same route might load webpages smoothly but buffer on one streaming platform. Describe the specific action that feels slow so support can try to reproduce it. If your device heats up, its fan runs continuously or the client uses unusual resources while loading complex pages, check background apps and system status too—not just the network.

Avoid changing connection concurrency, packet size or transport settings without a clear reason. They interact with the system, network and client implementation, and copying settings at random can make a working connection unstable. Start with the recommended defaults and check whether the issue is limited to a particular route, network or destination. If settings need to change, base it on the specific error and support guidance, and keep the original values so you can restore them.

If your local network is fine, several destinations are slow, and route types keep performing differently, gather the test conditions and contact support. Note whether background tasks were running, whether you changed networks, and whether loading or sustained downloads were slow. Don’t estimate route bandwidth or treat a brief peak as a service guarantee. Real-world usage and repeatable comparisons are more useful.

Peak-Time Slowdowns: Separate Network Congestion from Route Issues

A connection that works well during the day but slows down in the evening has a time-of-day pattern, but that alone doesn’t identify where congestion occurs. More people using a home network, a busy access network, changes along the route to the entry point and higher demand on a destination platform can all look similar. Note the local time range, network type and activity when the slowdown occurs. You don’t need to run speed tests all night; keep conditions you can compare again.

Keep the device and content consistent when comparing times

Compare using the same device, network, route and similar content. Streaming platforms may automatically lower video quality based on network conditions, so “no more buffering” could simply mean lower resolution. Note whether auto quality is enabled. Live sports and on-demand video aren’t directly comparable: live streams depend more on real-time delivery and player buffering, while on-demand content can often be cached ahead of time. Keep your viewing method consistent while troubleshooting.

During a slowdown, first check local services and other devices on the same network. If local video, websites or voice calls are affected too, focus on your home network and connection quality. If local services work but international services are generally slow, compare routes next. When switching networks, keep the content and account the same; otherwise, you won’t know whether the route improved or the platform assigned different resources.

Make sure route comparisons use meaningfully different paths

Routes with different names in the same region may not take sufficiently different paths under current conditions. Fix the current route manually, then compare it with another type in the same region, or try another suitable region if needed. After switching, reconnect the destination app so the browser or player doesn’t reuse its old connection. Automatic route selection is convenient for everyday use, but it can hide what changed during troubleshooting. Switch to manual selection to see the difference.

If one route gets noticeably worse only during busy periods while others still work, you can temporarily keep the better-performing option and report the original route name and time range to support. That doesn’t mean every exit in the region is affected or that one route type is always better. Conversely, if every route slows down on the same network and switching networks resolves it, focus on the access network and reachability to the route entry point.

Check live streams, streaming services and AI tools separately

If a live stream buffers, check whether the playback page shows a maintenance or content availability notice, then compare other content on the same platform. Don’t mistake a problem with the stream source for a route failure. For sports streaming, see VPN Picks for Live Sports. The article offers ways to evaluate your options; it doesn’t guarantee ongoing access to a particular event or platform.

Slow responses from AI Tools during busy periods may be caused by platform queues, model load, account limits or session handling. If webpages and other services work normally but generation takes a long time, check the platform’s response first. Repeatedly changing exits may trigger account verification and interrupt your work. For access requirements, see the AI access guide and assess network reachability separately from account eligibility.

The key to troubleshooting busy-period slowdowns isn’t finding one impressive result. It’s confirming which content repeatedly fails, at what time, on which network and with what route type.

Separate short-term workarounds from long-term troubleshooting. For now, pause background transfers, stick with a route that performs better and reconnect the destination app. For a lasting fix, compare results across times and report routes that remain problematic. Don’t reinstall repeatedly or upgrade your plan just to address a brief slowdown. Plan data determines your available allowance; it doesn’t explain route performance at a particular time, and paying for a change isn’t a substitute for diagnosing the issue.

If the issue follows a pattern, tell support what happens during normal and affected periods, whether you changed networks, whether another route helped, and whether the service is live, on-demand or interactive. You can report the issue without measurement tools; don’t make up latency or bandwidth figures. A reproducible description like “the stream kept buffering; switching routes and reopening the player fixed it” is more useful than “it’s really slow at peak time.”

Frequent Disconnections and Mobile Background Drops

First, tell whether the client shows a disconnection or still shows Connected while apps stop sending and receiving data. The first is more likely to involve the tunnel, process or system network changes; the second could also involve app sleep, routing or the destination. Note whether it happens right after locking the screen, changing networks, putting a computer to sleep, installing a system update or opening another network app. Finding the trigger is more useful than repeatedly tapping reconnect.

Check network changes and power settings

When a device switches from Wi-Fi to another network, the existing connection may need to be re-established, and the destination app’s old session may also expire. Wait for the system to reconnect, then check whether the client needs to reconnect. Once it does, reload the destination app’s page or session. If the problem only happens after a network change, don’t treat it as a persistent disconnection right away. Note the network types before and after, and whether the client status changed too.

When a computer wakes from sleep, its virtual interface, proxy process and internet connection may recover in a different order. Check that your local connection is back, then disconnect and reconnect normally. If you need to fix it after every wake, keep the system and client error details and ask support to review your setup instead of repeatedly resetting the network. On a managed device, first check with the administrator about power or network policies.

Check background activity and network permissions for your platform

Mobile operating systems may limit background activity, especially in power-saving mode, when memory is low or after you manually clear apps. On Android, check the app’s battery settings, background activity and network permissions; menus vary by device. Allow reasonable background activity without setting every app to unrestricted. On iOS, check the VPN configuration status, whether another VPN app has taken over and whether the system is asking for permission again. Don’t apply settings meant for another platform.

If the connection drops after you lock the screen but returns when you open the client, test with the client in the foreground and change only the screen-lock state. If it also disconnects in the foreground, background restrictions alone don’t explain it. Conversely, if the client stays connected but a messaging app is delayed, the app may have its own background settings. Check its system permissions too rather than changing only the VPN client.

Rule out competing network tools and stale connections

Multiple VPN apps, network filters or security components may compete for interfaces and routes. Check which app currently controls the connection, then temporarily quit tools you aren’t using and test again. Closing a window doesn’t always stop a background service; use the app’s own Stop or Disconnect option. Don’t delete system network interfaces or run unknown cleanup commands, or a reproducible issue could become much harder to recover from.

If disconnections happen only on a specific route, manually try another one while keeping the network and background state the same. If all routes disconnect after the same action, focus on the device. Running out of plan data or a change in plan status can also prevent a connection, so check the user panel. Don’t assume every reconnect issue means you’ve hit a device limit: HiHiVPN allows unlimited simultaneously connected devices.

When contacting support, describe what happened before the disconnection, whether the screen was locked, whether the device entered power-saving or sleep mode, whether the network changed, and what the client displayed. If you can reproduce it, list the steps from a working connection to the failure and include redacted errors from the relevant time. Don’t leave the device unlocked for long periods or weaken system protection just to collect evidence. Keep your usual security practices in place while troubleshooting.

Subscription Update Failures and Device Limit Notices

The subscription provides route configurations to the client. Account sign-in, plan status and route connectivity are separate steps. Signing in to the user panel doesn’t mean the client’s subscription has updated, and an update failure doesn’t necessarily mean all existing routes have stopped working. Check whether the message points to a network retrieval error, a configuration parsing error or an account status issue. Keep any working configuration until you’ve confirmed the new one imports successfully.

Check the subscription source in the user panel

Use the user panel to check your current account and plan, and confirm the client is using a subscription from that account. Copy it using the panel’s built-in option to avoid extra spaces, line breaks or punctuation added by chat apps. If you’ve saved multiple account configurations, check their names and update times to make sure you’re updating the right one. Subscription URLs are sensitive; don’t post them publicly, put them in shared notes or include them in help screenshots.

If you see a message that the subscription can’t be retrieved, try updating it while your basic internet connection works and other network tools are paused. Your current proxy connection may affect the update request, so note its original state, disconnect and try again. Don’t paste a full subscription URL into a public URL checker or online converter. Those tools can access the URL and increase the risk of exposing your credentials.

Tell retrieval failures apart from configuration errors

A retrieval failure usually calls for checking your network, account status and whether the URL is complete. A parsing error means the client couldn’t recognize the content it received as the required configuration. In that case, make sure you’re using the client’s subscription import option rather than entering the link in a manual server settings field. Import formats can vary, so follow the panel’s instructions instead of randomly editing configuration fields.

Get the client and subscription through the user panel. You need to sign in to get a subscription, and a valid plan is required for the client to retrieve it. Visit the client download page to see the currently available options. This page doesn’t provide direct installer links or real subscription examples. If your client reports an incompatible format, note the client name, system and exact error, then ask support which import method to use. Don’t replace the app with one from an unfamiliar source.

Use plan details to understand account status—don’t guess

Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on your activation date, and mid-cycle upgrades are prorated based on the remaining days. Data add-ons are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they’re used as needed and never expire. Check the active status and remaining data shown in your user panel. Don’t assume every account resets at the start of the calendar month.

If you see a message such as “device limit exceeded,” first check whether it came from the HiHiVPN panel, the client or the destination website. HiHiVPN allows unlimited simultaneously connected devices, so don’t assume the message means this service requires you to pay for additional device slots. Third-party apps may have their own device or session rules, and old configurations can contain outdated information. Keep the original message and note where it appeared so support can check it; don’t pay to dismiss it.

No email address is required. Create an account with a username and password. Keep your sign-in details and subscription URL secure while troubleshooting; support doesn’t need your password to investigate.

If you’ve shared your subscription publicly, check in the user panel whether you can reset or update the related credentials, and follow the instructions shown. If you can’t find the option, contact support rather than sharing the URL again. Update old configurations on your other devices after making a change. If you’re only having a route connection issue, don’t reset the subscription unnecessarily and risk affecting every device.

If your account is in good standing but updates keep failing, send support the error type, time, client and network details, and import methods you’ve tried. Redact subscription URLs, account credentials and sensitive payment details from screenshots. For billing or refunds, see the Terms of Service. HiHiVPN offers a 14-day no-questions-asked refund; describe technical troubleshooting and refund requests separately.

An App Isn't Using the VPN: Check Routing and Traffic Rules

If a website opens in your browser but fails in a desktop or mobile app, the requests may be taking different paths; this doesn’t necessarily mean the route has failed. An app may ignore the system proxy, use its own network settings or be routed directly by a traffic rule. On the same device and route, compare the browser with the app, then check whether the app reports a timeout, sign-in error or region notice.

Understand system proxy and virtual network modes

A system proxy only works for apps that follow the system setting. Some programs have their own proxy options; others connect directly. Virtual network modes handle traffic at a different layer, require the relevant system permissions and may be affected by other network components. Check the client’s actual interface and documentation for its available modes. Turning on a proxy doesn’t automatically mean every app handles traffic in the same way.

Check whether the app has an old proxy address or connection method saved, then check the client’s current mode. If the app has its own proxy setting, follow its official instructions and use parameters provided by the client. Don’t copy an unverified local port from a forum. If the app doesn’t support the system proxy, ask support which routing mode fits your platform. Don’t disable system security features or change network policies on a managed device yourself.

Test traffic rules with a temporary comparison

Rule mode uses conditions such as domains, addresses or apps to decide how requests are routed. If only one app has a problem, check whether the client can show which rule matched its requests. If it can’t, keep a copy of your settings and briefly switch to the client’s global proxy mode for comparison. Restore the original mode when you’re done so unrelated apps don’t change exits. Global mode is a diagnostic tool, not the right long-term default for every situation.

If temporarily enabling global mode fixes the problem, the issue may involve rule coverage or request matching. Don’t broadly add every domain associated with a platform to your rules: sign-in, payments, content delivery and account verification may use different services. Check the requests that actually failed, one at a time, and use rule sources recommended by the client. If global mode fails too, check the app’s own settings, system permissions, DNS or destination status instead of endlessly adding rules.

Connection reuse, sessions and regional rules

Changing routes doesn’t guarantee that an existing app connection moves immediately. Apps may reuse an old session, and background processes may keep existing connections open. Save your work, fully quit and reopen the app, and check whether its background process has stopped if necessary. Don’t force-quit an app while editing documents, uploading files or making a call—you could lose unsaved work. Repeat the same action after reconnecting to compare the new path.

AI Tools and streaming services often have their own account and regional requirements. Even after the exit changes, account subscriptions, content rights, supported regions or platform risk checks may affect access. If you see a clear account or region restriction, follow the platform’s instructions rather than repeatedly switching regions. HiHiVPN provides network access paths but doesn’t guarantee access to every AI account or content library, and can’t grant eligibility on a destination platform’s behalf.

Make the smallest change needed to avoid affecting other apps

If only a browser extension feature fails, include the extension’s own request path in your checks. If only a game, meeting app or other interactive service fails, note its network requirements and the error, then ask support whether the current routing mode could be involved. Don’t rule out network issues just because websites work, and don’t permanently send all system traffic through unfamiliar settings just because an app fails.

Browser works, app fails → check the app’s own settings → confirm the client’s routing mode → temporarily compare rule modes → reconnect the app → check the destination platform’s account and region requirements.

For macOS permissions and compatibility with Apple services, see Mac VPN Recommendations and Network Extension Guide. If you contact support, include the app name, the action that fails, whether the browser works, results from testing a temporary mode and whether quitting and reopening changed anything. Private chats, browsing content and account credentials aren’t needed; remove them from screenshots.

Restore Settings and Contact Support

The goal is to get back to a working setup and leave clear clues about the cause—not to change every network option. If you’ve already tried a lot, stop stacking more changes. Separate settings you had before from those changed during troubleshooting. Restore original values you know; note anything uncertain and ask support. Don’t replace your entire setup with a configuration from a stranger or clear all your data without a backup.

Set a baseline you can restore

Restore the client’s recommended connection and DNS settings, quit network tools you don’t need, use a current subscription from a trusted source and manually select a route you’ve verified works. This doesn’t mean deleting system network settings; it means reducing variables introduced during troubleshooting. If you rely on a proxy, workplace network or custom DNS for work, record why it’s there and involve the relevant administrator so fixing one app doesn’t disrupt other services.

If you decide to import the subscription again, first confirm your sign-in works, the user panel opens and any important non-sensitive settings are noted. If the old configuration still works, there’s no need to delete it just to try something. After importing, check the route list and basic access, then restore your personal rules gradually. For the full setup process, return to the quick start guide. For complex issues, use the relevant section on this page rather than making changes back and forth across multiple guides.

When to stop troubleshooting on your own

Contact support if the issue persists across networks and routes, or if you keep seeing permission failures, subscription format errors or an account status mismatch. If you aren’t sure whether it’s safe to change a system setting, ask before experimenting. Managed devices, enterprise certificates and network filtering policies may also require an administrator. Support can’t override your organization’s policies.

If only one website displays a clear account, region or content notice, contact the platform to check its service requirements and tell HiHiVPN what you’ve observed on the network side. Both issues can be investigated in parallel, but don’t present a website policy error as a route failure. See the Privacy Policy for service practices. HiHiVPN’s security policy is no logging; still, limit the information you share when asking for help.

Include reproducible details in your support request

Contact support through the Support page or the user panel ticket center. Include your device and operating system, client name, network type, route name and type, local time and time zone, then describe what you did when the issue began. Don’t send screenshots alone and expect support to guess. Screenshots show the message; your description explains the conditions. Together, they make reproduction easier.

Include the comparisons you’ve already tried and their results: whether your local network worked while disconnected, whether switching networks helped, whether other routes worked, whether the browser and app behaved differently, and whether locking the screen or changing networks triggered the issue. A test that made no difference is useful too. Don’t invent speed figures to make your report look technical. If you can’t reproduce the issue now, describe the original conditions and whether it later resolved.

Symptom: Client shows connected, but the target app reports a connection timeout
Environment: Enter your operating system, client name and network type
Time: Enter the local time and time zone when it happened
Route: Enter the route name and type shown in the user panel
Comparison: Describe how your basic connection, other routes and other apps behaved
Tried: List each action and what happened afterward
Attachments: Include only error screenshots or diagnostic snippets with sensitive details redacted

Redact Information, Follow Up and Verify

Before submitting, check your attachments and hide passwords, full subscription URLs, access tokens, sensitive payment details and unrelated personal content. If support needs diagnostic excerpts, confirm what they need first and share error details from around the time of the problem. You don’t need to upload your entire history. Don’t treat remote access to your device as a default troubleshooting step or post credentials in public comments. Send any additional materials through the same support ticket.

After you receive a suggestion, make one change at a time, repeat the action that originally failed and report the result. Once it works, confirm more than the client’s Connected status: check that your task works, and if relevant, test again after locking the screen, switching networks or reopening the app. Restore any temporary test mode to your normal settings and keep a note of what worked. If your request involves a plan, payment or refund, state each separately. Alipay / WeChat Pay / USDT are supported payment methods; see the Terms page for refund details.