Basic checks and troubleshooting order
When something goes wrong, note what you were doing instead of immediately wiping your settings. A page that won't load, a failed client connection and a buffering video may all look like network trouble, but the cause could be DNS resolution, connection setup or data transfer. Describe the symptom precisely to make the next steps more useful. Keep a note of the current server name, connection mode and error message, roughly when the issue occurred, and the network your device was using.
Check that your underlying network works
Disconnect the client temporarily and try a website that normally works. Check whether the network requires a sign-in or access confirmation. Hotel, campus and public Wi-Fi can connect to the wireless network before completing this step. Finish the network sign-in first, then reconnect the client. If familiar sites still won't load with the client disconnected, look at the router, internet connection or system network settings before switching servers.
When switching networks, leave all other settings alone. For example, move the same device from Wi-Fi to another available network and keep the same server and app. If the problem goes away, check the original network's access restrictions, signal and router. If it follows the device, look at the client, system permissions and proxy settings. If you can't try another network, compare with another device on the same network and note whether its client settings match.
Separate account, configuration and destination checks
Sign in to the user panel to check your plan and remaining data, then make sure the subscription is imported in the client. Being able to sign in doesn't guarantee a server is available. Likewise, a client showing “Connected” doesn't mean the destination website has responded. Account status, subscription details, the server connection and website access are related but separate steps. Check each one instead of treating a single success indicator as proof that everything works.
Next, narrow down what's affected: all websites or just one; the browser or a particular app; every server or only the current one. Don't judge the whole service by a single website. Compare destinations you normally use for different purposes, and keep the exact error from the one that failed. The destination itself may be undergoing maintenance, require a particular account region or have an app sign-in problem that looks like a network issue.
Keep a state you can restore. Before making changes, note the connection mode and server name. Don't switch servers, DNS, proxy mode and client all at once; even if that fixes things, you won't know which change made the difference.
Build a clear diagnosis with minimal changes
For each comparison, keep the device, app and destination the same, and change only the condition you're testing. After each change, repeat the original action, note the result, then decide whether to keep or undo the change. Browser caches, persistent app connections and system sleep can preserve old state. After changing settings, close and reopen the app normally rather than relying on a page that's already open.
Stop if you see a certificate warning, an unfamiliar sign-in window or a prompt to install a certificate from an unknown source. Troubleshooting doesn't require sharing your account password or disabling all system security. If your device is managed by your employer or school, its policies may restrict proxy access. Ask the administrator which connection methods are allowed; don't remove management settings to try to restore access.
This guide works from the underlying network through the client, server, DNS and app. If the symptom is clear, jump to the relevant section. If several things seem wrong, complete this section first, then narrow it down below. The goal is to reach a diagnosis you can reproduce and explain, not to make settings increasingly complicated. If comparisons don't identify the cause, organize what you've tested into a support ticket. Repeated trial and error usually adds noise.
Can't connect: troubleshoot connection setup
“Can't connect” usually means the client stays on Connecting, fails shortly afterward, or reports a timeout, authentication failure or refused connection. Read the full error before deciding what to try next. A timeout may indicate that the connection couldn't be established; an authentication failure points more toward credentials or subscription status; a refused connection could involve the endpoint, network policy or an invalid configuration. These are troubleshooting clues, not proof of a server-side failure.
Check whether the client is actually routing traffic
Make sure you're using a client obtained from the user panel, and that you've selected an imported subscription and a specific server. Seeing servers in a list doesn't mean one is active, and a tray icon doesn't mean the connection is switched on. If the client asks to create a system network configuration, grant permission when prompted. If you previously denied it, check system settings rather than repeatedly clicking Connect.
Check whether another network proxy, older client or network-control tool is running at the same time. System proxy settings and virtual network interfaces may be controlled by different programs, and a later app can overwrite an earlier app's settings. Quit other similar tools normally, leave the current client running, and try again. Don't delete network adapters or uninstall unfamiliar drivers. If the software is managed by your organization, check with its administrator first.
Narrow it down by error type
For an authentication error, check your account and plan status in the panel, then copy the subscription link from the panel again and refresh the client configuration. Don't enter your panel password in a server authentication field or edit server details from memory. The subscription provides the server settings; changing them manually can break a working configuration. Select a server again after refreshing so you don't keep using an outdated entry.
For a connection timeout, keep the client mode unchanged and try another server, then compare with a different region. If only one server fails, note its name and use another temporarily. If all servers fail, switch networks. If the same device connects on another network, focus on the original network environment instead of resetting the entire client. See the server list for coverage and selection guidance.
If the error mentions certificate validity, check your system date, time and time zone, and enable automatic time synchronization. A significant clock difference can interfere with secure connection checks and cause problems in both browsers and clients. Correct the clock, restart the relevant apps and test again. Don't disable certificate checks as a long-term workaround or install certificates downloaded from unknown sites. Diagnose certificate errors using the system time and the exact message.
| Symptom | Check first | Then verify |
|---|---|---|
| Authentication failed | Account status and subscription source | Refresh the subscription, then reconnect |
| Repeated timeouts | Underlying network and current server | Compare another server and network |
| Permission denied | System network configuration permission | Check for management policy restrictions |
| Certificate time error | Date, time and time zone | Sync the clock, then restart the app |
When to stop troubleshooting on your own
If the client won't start, the Connect button is unavailable or the system keeps revoking permission, address the local app or permissions first. Check whether the system explicitly blocked the app, and verify its source using the original download page. If security software shows a warning, review the reason instead of disabling all protection. If the client crashes, save the error and note what you were doing. When reporting it, say whether it closes on launch or only when connecting to a particular server.
If every option still fails after checking the account, refreshing the subscription and comparing different servers and networks, submit a support ticket. Include the exact error, operating system, version shown in the client and approximate time. List the conditions you've already tested. Use the version displayed in the app rather than guessing. Before sending logs, check for a full subscription link or credentials and include only the excerpts related to the connection error.
Connected, but websites won't load: DNS and routing
When a website still won't load after a successful connection, separate “the server connection is established” from “the website request succeeded.” A page that keeps loading, a domain-not-found error, a secure connection error and an access restriction point to different causes. Save the browser's exact error, then try another website. If only one site fails, check its own service and region requirements. If all sites fail, check proxy routing, DNS and network routes.
Check which route the website is actually using
Check whether the client is in rule-based routing, global proxy or direct mode. In rule-based mode, the route depends on the destination; not every website uses the same exit. Open IP check to see the exit location reported by the current browser request, then compare it with the client's connection logs. A normal exit location only confirms the path for that particular test request, not that every app or domain uses the same route.
If the client offers a global proxy mode, switch to it temporarily and reopen the site. If that works, check rule matching, app routing or DNS behavior. If it still fails, continue checking the server and destination site. Global proxy is a diagnostic tool, not a universal fix. When you're done comparing, restore your original routing mode so local websites and network resources don't take an unnecessary route.
Why DNS can fail on its own
DNS translates domain names into addresses used to connect. The client, operating system and browser may each handle DNS; browser Secure DNS, manually configured system resolvers and built-in client settings can all create different paths. So a domain can fail in one browser but work in another app. Note these settings before troubleshooting, and don't replace them all at once with public DNS addresses copied from different guides.
Start with the client's recommended default DNS settings. Check for old manual DNS settings, encrypted DNS configurations or local domain overrides. If the device has been used for development, check whether the hosts file pins the website to a specific address. Don't delete the entire hosts file. Back it up, then remove only entries you added yourself that are clearly related to the problem. Don't change settings managed by an organization.
On systems with the relevant command available, you can use the query below to check whether system DNS returns a result. The example domain demonstrates the command; it isn't the only test destination for international routes. A successful query only shows that this particular lookup received a response. It doesn't prove the browser uses the same resolver or that a secure connection to the website succeeded.
nslookup example.comIf the command isn't available, there's no need to install unfamiliar tools just to troubleshoot. Use the system's network diagnostics and client logs instead. If the query fails while the underlying network works, check whether the DNS resolver is reachable and whether the client is handling DNS. If the query succeeds but the browser still reports a resolution error, check the browser's own DNS settings and cache. Close and reopen the browser normally after making changes so an old process doesn't keep using its previous connection.
Don't use a bare IP address as a substitute for testing a full website. Many sites rely on domain names to select the right site and validate certificates. Failure to open an IP address doesn't prove the server is unavailable, and disabling certificate checks won't fix a DNS problem.
Tell DNS failures apart from a website denying access
If the page returns a region restriction, account error or access verification prompt, at least some requests have reached the destination service. Check the platform's account region, requirements and whether your current exit meets its rules instead of repeatedly refreshing DNS. Trying another server can help with comparison, but no region or website is guaranteed to work at all times. See Streaming for streaming-specific troubleshooting.
When asking support for help, include the domain, the browser's exact error, the current mode and whether other websites work. Don't send a full URL containing sign-in credentials; query parameters may also include personal information. If you suspect different DNS routes, describe the difference between system lookups and browser behavior. An exit IP check alone can't prove that the whole device uses no other DNS route.
Slow speeds and peak-time lag: compare like for like
Start by identifying what feels slow. A page that takes too long to open, a slow download, a buffering video and choppy voice calls aren't the same problem. Small requests are more affected by connection setup and DNS; sustained downloads depend more on data transfer, while real-time apps are also sensitive to jitter. Don't rely on a single speed test or client status value to judge how an app actually performs.
Rule out device and local network congestion first
Keep the current server and check whether the system is syncing files, updating apps or handling other high-bandwidth tasks. See whether any devices on the same network are using a lot of bandwidth. Pause those tasks temporarily, then repeat the original browsing or playback test. If performance improves, address local congestion first. A weak Wi-Fi signal, distance from the router or nearby interference can also affect every server.
If possible, move closer to the wireless access point or compare with an existing wired connection. Keep the client and destination the same so you can tell whether the wireless environment made the difference. If only the current device is slow while others on the same network work normally, check its background load, power-saving settings and conflicting network tools before blaming the whole connection.
Choosing a server isn't just about distance
WeiVPN covers 100+ countries / 240+ routes, but choosing a server still depends on the destination service and your network. A closer location often helps interactive apps, but the actual route, carrier interconnection and destination server all affect performance. For a site aimed at a particular region, try a server in that region, then compare with other available locations. A route type describes how a connection is set up; it doesn't guarantee a fixed speed every time.
| Route type | What it means | Useful for checking |
|---|---|---|
| IEPL | Focus on cross-border transport and the access route | Compare real-world app performance with other route types |
| Relay | Connection is forwarded through an intermediate entry point | Compare performance across access networks |
| Direct | Connects directly to the relevant server endpoint | Check performance from your network to the endpoint |
Different routes can exist in the same region, so a country name alone doesn't indicate quality. Repeat a brief, consistent action in the original app, then try another server. If websites work but video is slow, check the streaming platform, content delivery and playback settings. If all apps are slow, investigate the route or access network. See the server list for more options; availability in the client is authoritative.
Compare peak-time issues across different times
Peak-time lag needs comparison across time periods. Note how the same network, server and app perform during busy periods and at other times. Don't assume a brief improvement means the problem is fixed. If every server slows down on the same network, congestion on the access side is worth checking first. If only one server performs worse under the same conditions, note its name and the time, then use another server temporarily.
Don't run several speed tests at once. They use network capacity and can affect the video or call you're trying to assess. Automatic video quality changes also affect bandwidth use, so note the playback setting. The latency shown by the client can't be converted directly into download speed, and lower latency doesn't guarantee faster sustained transfers. Base your diagnosis on the task that actually failed, not a single number.
If lag only affects a particular video or download source, try other content on the same platform to see whether the destination server or content delivery is the issue. If changing the destination fixes it, include that difference in your support ticket. Don't conclude that every route is slow based on one site, and don't disable security checks, broaden permissions or install dubious “optimization” tools to improve speed.
Choose a higher-tier plan based on actual usage, not as a shortcut to faster speeds. Monthly subscription data resets each month on the activation date. Data packs last until used and never expire. These are billing and usage rules, not a promise that different tiers have different speeds. See data packs vs. monthly plans for help choosing, and check the plans page for prices and terms.
Frequent disconnects and mobile background dropouts
Start by checking when the disconnect happens: repeatedly after connecting, or only when the screen locks, you switch apps or leave Wi-Fi range. Then distinguish a client disconnect from an app session expiring. An app asking you to sign in again doesn't necessarily mean the server disconnected. A connected status in the system tray doesn't guarantee that an app's old background connection can recover. Note the sequence of events; it's usually more useful than repeatedly capturing a “Connected” screen.
Existing sessions may fail after a network switch
Switching from Wi-Fi to another network can change the device's access address and routes. The client needs to adapt, and the destination app may still be holding a connection made on the old network. Wait for the system to confirm the new network is available, then check the client. If needed, reconnect and reopen the app. Don't repeatedly toggle the connection while the system is still switching networks; it makes the state harder to diagnose.
If the problem only occurs when moving between wireless access points, note whether you had to sign in to the network or joined a Wi-Fi network without actual internet access. A device with multiple saved networks of the same name may also connect in a different environment. Repeat the test in a fixed location with a stable signal before deciding whether movement triggers the issue or the client disconnects while stationary too.
Android: check battery and background restrictions
Android background restrictions vary by manufacturer and system settings. Open the client's app settings and check whether background activity, battery use or network access is restricted. If the system offers an option to allow background activity, enable it if needed, then reproduce the issue with the screen locked. Menu names vary, so follow the setting's description rather than blindly changing unrelated permissions based on screenshots from another device.
Also check battery saver, data saver and automatic cleanup. If the client stops only after background cleanup, process management is an important clue. If the process stays active but the connection disappears, look at network switching and logs. Don't set every app to unrestricted background activity; change only what the client needs. Avoid unfamiliar tools that modify low-level system restrictions. Normal troubleshooting doesn't require unlocking the device or changing its security state.
iOS: check the system connection configuration
On iOS, first confirm that the system allows the client to add a network configuration. Then check whether another app is using the same type of system connection. Switching to a different network tool may replace the existing connection. When you reopen the original client, check which configuration is active. If system settings contain old configurations you created, identify and record what each one is for before following the client's instructions. Don't remove configurations needed for work or school.
If only one app stops receiving new content after the screen locks, also check that app's background refresh, notifications and network permissions. Notifications may use a separate system mechanism, so delayed notifications alone don't prove the client disconnected. After unlocking, check the client's status and connection logs, then reopen the app to test. If the client stays connected but the app needs a manual refresh, consider the app's background behavior too.
Desktop sleep and router interruptions
Windows, macOS and Linux may need to re-establish network state after waking from sleep. Confirm the device's basic network works, then reconnect the client. If the issue only occurs after sleep, use the before-and-after state as a reproduction condition. If all devices disconnect at once, check whether the router or access network reconnected. Don't change advanced network adapter settings without evidence; first compare a normal wake-up with a fresh connection.
A background disconnect doesn't mean you've exceeded a device limit. WeiVPN supports unlimited devices. Check system background management, network switching and client routing first; don't delete other devices to see if that helps.
For a disconnect support ticket, say whether the screen was locked, the network had changed, battery saver was on and the system had stopped the client. If one server repeatedly disconnects, include its name and the time. If all servers disconnect after the same action, highlight that action. A reproducible trigger is more useful than a large collection of screenshots and helps distinguish system behavior from a server issue.
Subscription update failures and unexpected server lists
Subscription updates and server connections are separate requests. If existing servers still connect but an update fails, the issue may involve the route or permissions used to retrieve the subscription. If the update succeeds but connections fail, the configuration was retrieved, but the connection still needs investigation. Save the update message and distinguish a network timeout, invalid response format, permission error or empty list. Don't treat every problem as a reason to reinstall.
Verify the subscription source in the user panel
Get your subscription from the user panel, not from old chat messages, search results or links forwarded by someone else. Copy the complete content provided by the panel; manual selection can omit the beginning or end. Chat apps, document formatting and copy-and-paste can insert spaces or line breaks, leaving a link that looks complete but won't work. Check it locally and never post the full link in a public discussion.
Make sure you paste the link into the client's subscription import or update field, not a server address, proxy server or account sign-in field. Import steps differ between clients, so follow the prompts in the current app. If the panel offers an import method for your client, use it. Don't convert the configuration to a different format or submit subscription contents to an unfamiliar online conversion site.
For update timeouts, check how the client retrieves the subscription
An update request may use the system network or follow the client's own proxy settings. If the existing connection has stopped working and updates depend on it, you can end up unable to retrieve a new configuration. First confirm the underlying network works, then see whether the client lets you choose how updates connect. You can temporarily disconnect a failed connection and retry if the client supports it. Don't assume all platforms work the same way.
If the panel itself won't open, start with the basic network and website troubleshooting sections. If the panel works, the copied link is complete and the client still can't update, save the status message. Repeatedly refreshing won't fix an address or permission problem and can make diagnosis harder. If the system clock is significantly off, correct it before testing a secure connection.
What to do about format errors and empty lists
A parse error, content-type mismatch or unrecognized configuration field may mean the import method doesn't match the content format, or the client received an error page instead. Don't share the returned content as ordinary webpage text; it may contain sensitive configuration. Choose the correct import method in the panel and verify the client source. If the client shows import details, report only the field name or error message, not the full configuration.
A shorter list or changed server names after an update don't necessarily indicate a problem; server configurations may change. Clear filters and expand groups to make sure you're not seeing only favorites or the selected region. If the list is empty, check that the original subscription is selected and that you haven't created an empty configuration by mistake. Keep the old configuration temporarily for comparison, and remove it only after confirming the new one works.
Keep your subscription link private like a credential. It may provide access to the connection configuration associated with your account. Hide the full link, QR code and any link behind an import button in screenshots. If you think it has been exposed, use the reset option in the panel or ask support for help.
Account status and configuration updates are separate
Monthly subscription data resets each month on the activation date. Data packs last until used and never expire. Rely on the plan status and usage shown in the panel; the start of a calendar month isn't a universal reset date. If the account status is wrong, repeatedly updating the subscription may not restore the connection. Mid-cycle upgrades are prorated into remaining days. Check the plans page for options and prices; don't assume an upgrade includes extra data.
If you need help, say whether the panel works, whether you just copied the subscription from it, what error the client shows and whether the old configuration still connects. You can include a screenshot of the update screen with the link hidden. For more on keeping account details safe, see the account and subscription link security guide. Support needs symptoms they can investigate, not your credentials. If you're unsure how to redact something, start with a text description.
An app isn't using the proxy, or a device limit warning appears
If the browser works but an app doesn't, first consider how the app connects, how its traffic matches routing rules and whether the destination service behaves differently. Not every app uses the system proxy; some have their own network settings, and some require the client to take over network traffic more fully. Check whether the browser on the same device can reach the same service, then see whether the client logs a connection from the app. Don't assume the server doesn't support that app.
How to use rule-based and global modes for diagnosis
Note the original mode and selected server, then temporarily switch to global proxy and test the same app. If it works, check whether a rule sends the relevant domain or process to a direct connection. If nothing changes, check whether the app bypasses the system proxy or uses its own proxy configuration. Global mode can only affect connections the client actually intercepts; it doesn't automatically cover every kind of traffic from every app.
Apps often connect to more than their main domain. Sign-in, images, attachments and messages may use different domains. A homepage that loads while sign-in fails may mean those supporting requests take a different route. If the client offers rule-match logs, check where the relevant requests went when the problem occurred. Don't delete all rules or permanently route every domain the same way to fix one app. Identify the missing match first, then use the options supported by the client.
Check routing and permissions by platform
| Platform | Check first | Common limitations |
|---|---|---|
| Windows | System proxy and network-routing permissions | Some apps don't use the system proxy |
| macOS | Network extension permission and active proxy configuration | Terminal and desktop apps may behave differently |
| iOS | System network configuration and other connection tools | Another app may replace the active connection configuration |
| Android | Per-app include and exclude lists | Per-app routing may exclude the target app |
| Linux | Desktop proxy, process environment and permissions | Background services may not inherit desktop settings |
On Windows, first check whether the target app has its own proxy option, then check how the client routes traffic. On macOS, an unauthorized network extension can leave the app open while system routing remains incomplete. See macOS setup: from installation to subscription import for initial setup and permissions, and Windows routing modes and compatibility for desktop mode choices.
On Android, if per-app routing is enabled, check whether the target app is excluded, then reconnect after making changes. On iOS, check the active system configuration and the app's network permissions. On Linux, terminal apps, desktop apps and background services may use different settings. Check the environment each process actually runs in; a working desktop browser doesn't prove that every process is routed through the client.
Check account requirements for AI tools and streaming
AI tools such as ChatGPT and streaming services may also depend on the platform's region, account, content licensing and service status. Reaching a sign-in page doesn't mean the account has access to every feature. If the network works but the platform reports an account region or eligibility issue, follow the platform's guidance. Don't use accounts from unknown sources or share sign-in details for someone else to test. A network route can't replace the platform's account requirements.
If the app has built-in proxy settings, note the original values and compare them with the local listening address shown by the current client. Use the port and protocol from your client, not values copied from another device online. Don't expose the local proxy listener to your whole network or put credentials in a public script. Reopen the app after changing settings, then check where its requests go so you're testing the new configuration.
What to do when you see a “device limit exceeded” warning
WeiVPN supports unlimited devices. If a device, connection or authorization limit appears, check whether the message comes from the WeiVPN panel, the client, a system management tool or the destination website. The same “device limit” wording can refer to entirely different products. Don't assume this service has an unpublished device quota or place another order to clear a warning whose source hasn't been confirmed.
Send support the exact message, where it appeared and what you did to trigger it. Keep the app name visible in screenshots but hide personal information. If the warning comes from a streaming or other destination platform, check that platform's account policy. If it appears while using this service, support can investigate. Authorization restrictions on work-managed devices must be handled by the administrator; this service's device policy doesn't change limits imposed by the device or other apps.
Support evidence, recovery checks and refunds
If you've checked the underlying network, account status, subscription and different servers but still can't explain the problem, submit a support ticket. You don't need to complete every advanced troubleshooting step before asking for help. Stop if permissions behave unexpectedly, you see a certificate warning, the client keeps crashing or you're unsure whether a setting is safe to change. Clearly describing what you haven't tried is more useful than losing the original state through trial and error.
Describe the impact first, then how to reproduce it
Start your ticket with what the problem affects: all websites, one particular app, a disconnect after locking the screen, or a server that slows down during peak hours. Then include the device operating system, the version shown in the client, network type, approximate time and time zone. Use the server name exactly as displayed. The destination domain is enough; avoid full URLs containing personal parameters or temporary credentials.
Describe the reproduction steps in order: whether the underlying network worked before connecting, which mode and server you selected, what you did, and what appeared afterward. Then list the comparisons you've already made—for example, whether switching networks helped, another region still failed, or the browser worked while the app didn't. Don't just say “tried everything”: that doesn't show which variables stayed the same or whether the problem only cleared under different conditions.
Organize your ticket in this order: symptom → conditions and time → system and client details → current server and mode → tests and results → redacted error text or screenshots. Submit it through user panel support tickets, not in a public comment.
Redact logs and screenshots before sending
Client logs may contain destination domains, account identifiers, subscription links and local file paths. Include only the relevant lines from around the time of the problem, and check for passwords, full links, QR codes or other account access details before sending. In screenshots, check the browser address bar, clipboard pop-ups and notification previews too. If you're unsure how to redact something, start with the error text and a description of what you did; support can tell you what else is needed.
WeiVPN's core privacy message is anonymous, no-logs service, but diagnostic material you choose to submit should still follow the principle of data minimization. A privacy commitment doesn't replace care when sharing information publicly. To learn how to assess such claims, read how to verify no-logs claims and refer to the site's Privacy Policy. Don't forward a full configuration as an ordinary attachment.
After recovery, test the original scenario—not just the status indicator
After making a change, repeat the action that originally failed. Confirm that the website, app sign-in or playback actually works, then test related features. If the problem only happened in the background, lock the screen and resume use. If it occurred only after switching networks, repeat that sequence. A successful connection indicator or a different website loading temporarily doesn't prove the original problem is fixed.
Once everything works, undo diagnostic-only global proxy and temporary DNS settings, and stop collecting logs you no longer need. Keep a note of the final working settings and what fixed the problem. Before deleting old configurations, confirm which subscription is currently in use. If switching servers was the only thing that helped, record that accurately rather than marking the old server as fixed. This note can help distinguish a recurring issue from a new one.
Billing and refunds follow the stated terms
WeiVPN offers a 14-day no-questions-asked refund. See the Terms of Service for full conditions. For billing or refund requests, use a panel support ticket and include the relevant order and request. You can describe the technical issue and refund request separately; don't include sensitive personal details from payment records. Don't convert a network problem into an assumed refund amount or extra service time.
Plan prices and payment information are listed on the plans page and in the panel. Alipay / WeChat Pay / USDT are supported. If the order status in the panel doesn't match your payment, keep the order details and contact support rather than paying repeatedly to “activate” it. No email address is required; accounts use a username and password. If you already have an account, recover your own sign-in details instead of creating multiple accounts to work around an order issue.
Finish by summarizing the diagnosis in a sentence you can repeat: which network and device you used, what action failed, which change fixed it and what remains untested. That's more reliable than “it seems fine now.” For quick answers, see the support page. To repeat installation and subscription import, return to Guides and follow the main setup steps without changing parts you've already confirmed work.