VPN Troubleshooting Guide

Break “can't connect” into symptoms you can check

A connection failure could mean the client won't start, the subscription has no routes, or the client stays on “Connecting” after you select a route. These point to different layers. Note the exact message and when the issue occurs: when opening the app, updating the configuration or establishing a connection. If the client hasn't loaded any routes, go to the subscription update section first; switching proxy modes repeatedly won't restore missing configuration.

Next, disconnect the client and check whether your current network works on its own. Use a browser to visit a site you can normally access directly, then check whether a network sign-in page is waiting in your system browser. Hotels, business travel venues and public Wi-Fi may require you to accept access terms first. Until the basic connection is online, the client can't establish an external connection either. Don't assume this means your subscription has expired, and there's no need to delete your account or pay again.

Tell a single route issue from a broader connection problem

Check your subscription status, remaining data and expiration date in the user panel, then manually update the configuration in your client. Monthly subscription data resets on the activation date each month, not at the start of the calendar month. Data packages remain valid until used and never expire. If your account is in good standing, keep the error message and try a route in another region or of another type. Change only the route, not the network, so you can tell whether the route made a difference.

If just one route fails while others can reach the same destination, focus on how that route interacts with your current network. Note the region, route name and type, and use a working alternative for now. If all routes fail, keep the same route and compare it on another available network. If switching networks fixes the issue, the original network environment, authentication state or network policy may need a closer look—but that alone doesn't establish the server's status.

Check permissions, leftover proxy settings and security alerts

Check whether your system allows the client to add network configurations and whether any required background components are disabled. When a system permission dialog appears, verify that the request comes from the client you're using, then follow the platform's instructions. Don't download supposed repair components from unfamiliar sites. If you've used other proxy software, exit it normally and check whether it left a system proxy enabled. Multiple tools managing network traffic at once can send requests to a local endpoint that is no longer running.

If security software reports a block, check what was blocked, the file path and the reason instead of disabling all protection. Work-managed devices may also have centrally enforced network policies; ask your device administrator about settings you can't change. If the client reports that a service or driver failed to start, fully quit and reopen it, then grant permissions as prompted by the system. Reinstallation should be a later step. Before reinstalling, make sure you can retrieve your subscription again and save any useful diagnostic information.

Recommended order: basic network → account status → configuration loaded → compare individual routes → compare networks → system permissions. Keep the result of each check so different issues don't get conflated.

When to stop troubleshooting locally

If your basic network works, your account is active and the configuration updates successfully, but routes in different regions still produce the same error across different networks, submit a support ticket. Include the client and system details, exact error, when it occurs and the comparisons you've already made. If the error specifically mentions a certificate or device time, check that your system date, time and time zone are set to sync automatically. Don't bypass certificate checks to force a connection; that can hide a configuration or security issue.

Once connected, open the destination that failed before to verify access rather than relying on a status indicator changing color. If the client says it's connected but websites still fail, continue to the next section—you don't need to repeat the account checks. To learn about route differences, see the Routes page. To repeat the initial setup, return to Quick Start. Keeping setup instructions separate from troubleshooting makes the process clearer.

A connected status doesn't guarantee access to a destination

A “Connected” status usually means the relevant network component has started or a connection has been established. It doesn't mean every app is using the proxy, or that a destination accepts your current exit route. Compare different destinations first: do all websites fail, or only one? Does the browser fail, or do desktop apps fail too? Classify the error as a DNS lookup failure, connection timeout, certificate warning or an explicit rejection by the site. That points to the layer to check next.

In the same browser, visit a site that normally works without the client, then try a destination that needs an international route. If even basic sites stop loading after you enable the client, check the system proxy, routing mode and DNS first. If only one destination fails, keep its error page and test other sites on the same route. One inaccessible site doesn't prove that every route is down; the site may be under maintenance, or account permissions or regional rules may be involved.

Check the system proxy and connection mode

Check whether the client has enabled the system proxy and whether the proxy address points to the client currently running. Don't guess and enter a local port manually; use the value shown in the client. Some apps follow the system proxy while others make connections independently, so a working browser doesn't prove that every app uses the same route. If the client offers a virtual network adapter mode, compare results only after you understand its permissions and scope. Don't enable every traffic interception feature at once.

Routing rules can change the result too. Rule mode may send some domains directly. Temporarily switching to global mode can help identify a missing rule. If global mode works but rule mode doesn't, check how the destination domain and related resource domains match your rules instead of repeatedly changing the exit route. Return to your usual mode after testing so local services aren't all sent through the proxy. Global mode is a diagnostic aid, not a substitute for checking app-specific rules.

Choose the next check based on the error

If a domain can't be resolved, go to the DNS section and check the resolver and client logs. For a connection timeout, compare other routes and networks. For a certificate error, check the system time, destination domain and whether a network sign-in page is required. Don't enter account details on unfamiliar redirect pages or install an unknown root certificate to dismiss a warning. If a site clearly reports a regional or account restriction, follow that service's rules; a network connection can't grant account eligibility.

If a page title appears but images never load or sign-in fails, the main page and its resources may be taking different routes. The browser's developer tools Network panel can show the failed request's domain and error type. Record only the domains and status you need; don't share full request headers, session details or URLs containing authorization parameters. When contacting support, “Page loads, but sign-in resources time out” is more useful than simply saying “the site doesn't work.”

First check whether requests are passing through the client, then whether the exit route can reach the destination. System proxy, virtual network adapter and routing mode are separate things to investigate. Don't change them all in the same test.

Rule out browser-specific settings

Browser extensions, separate proxy settings, secure DNS and cached data can all make results differ from your system configuration. Try a temporary browser profile, temporarily disable extensions clearly related to networking, and revisit the same destination. Private browsing doesn't necessarily disable all extensions or system settings, so it isn't a guaranteed clean environment. If another browser works, compare browser settings first instead of reinstalling the whole client.

After service returns, test websites, sign-in and the apps you actually use separately. For more checks on a “connected” status when traffic may not be using the route, see the guide to checking your exit IP, DNS and per-app routing. If you need support, share the failed domain, exact error, proxy mode and what changed after switching modes. You don't need to send private browsing history or your full account page.

Start by finding out what's slow

Slow page loads, video buffering, slow downloads and laggy interactions can have different causes. Initial page loads depend on DNS lookups and connection setup; sustained downloads rely more on available bandwidth; interactive apps are more sensitive to latency, jitter and packet loss. Describe what you actually see—for example, “text appears, but images keep loading”—instead of just saying “it's slow.” A single probe result in the client doesn't reflect the full app experience.

Check whether downloads, cloud sync, system updates or other devices are using your local network at the same time. Wi-Fi performance can also be affected by signal strength, interference and access point load. Keep the current route, pause known high-bandwidth tasks and retry the same action. If possible, compare another type of network connection. Only once your basic network is stable can you tell whether the bottleneck is on the international link, exit route or destination service, rather than mistaking local congestion for a subscription issue.

Compare routes using the same task

Compare different routes using the same destination, app and similar conditions. Don't test video on one route and downloads on another. Geographic distance is only a rough guide; a nearby location doesn't guarantee a shorter ISP route. IEPL dedicated lines, relay routes and direct connections use different path setups. Actual performance also depends on your local connection, the specific route and the destination service. Start by comparing route types in a suitable region before changing the exit region.

Avoid running repeated speed tests or refreshing long videos over and over to track changes. This uses more data and can skew results through caching or a platform's adaptive quality. A better approach is to use a normal task and note when you used it, which route you selected, where it failed and what you observed. If you do use a speed test, note the test destination and conditions; one result can't guarantee speeds across all apps.

Keep track of the time during peak-hour issues

If everything works during the day but slows down in the evening, first check whether your basic network also slows down at the same time. Shared access, heavy household usage and congestion on cross-region links can all contribute. Keep the app and destination the same, compare different route types, and note which combinations work and which still fail. Repeatedly restarting the client usually won't resolve time-of-day congestion, and can interrupt connections that would help you diagnose the issue.

After switching routes, don't judge performance by the moment a page first opens. Video services may reuse an old connection or cached data, and a download may continue over an existing session. Restart the test task after switching, then observe how it performs. If only live streams stutter while on-demand video works, consider that live streams have less room to buffer and popular events can put more load on the destination. On-demand playback working doesn't prove that live streams will be just as smooth.

Don't confuse plan data allowances with speed

Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. These figures are data allowances, not speed ratings; a larger allowance doesn't necessarily mean faster speeds. To compare usage and billing, see Plans & Pricing. If your account shows that your data is used up, address the usage issue first rather than changing DNS settings or repeatedly switching regions.

When reporting a speed issue, include when it happened, your connection type, route name, destination app and what changed after switching routes or networks. A speed-test screenshot without context isn't enough. For route selection for live sports, see Choosing a route for low latency and peak-time events. For basic troubleshooting on work trips, see Hotel Wi-Fi and cross-border work.

First identify what's disconnecting

A disconnect may mean the client has stopped, the route still appears connected but apps time out, or only a long-running task is interrupted. Note whether the client is still running, whether the system network changed and whether other apps lost their connection too. If the client stays connected but requests fail, check the website access and DNS sections. If the system has stopped the client, check background operation and power management before changing your subscription.

Notice whether disconnects happen when the screen locks, you switch apps, the device sleeps, Wi-Fi changes to a cellular network or you leave an access point. A network change alters the connection path, and an existing session may not continue unchanged. Distinguish “briefly reconnects after switching, then recovers” from “can't reconnect at all after switching.” These point to different issues and should be described separately in a support ticket.

On mobile, check system background restrictions first

On Android, check the client's battery and background activity permissions in system app settings. Menu names vary by device, so use the options shown on your system. If the system has put the client into strict battery saver mode or limited its background network access, adjust those settings to suit your needs and test again with the screen locked. Don't disable power management for every app just to keep the client alive, and don't install unknown background booster tools. First make sure you're changing settings for the client you actually use.

On iOS, check whether the system VPN configuration still points to the client you're using and whether another tool has left a connection profile behind. Network extensions on iOS work differently from ordinary apps, so switching to another app doesn't necessarily mean the connection has ended. If only one app stops responding after the screen locks, reopen it and check its connection status. If the system VPN status also turns off, note the network change and any system alert.

On desktop, check sleep and network component conflicts

After waking from sleep, Windows, macOS and Linux may need to restore network interfaces, routes and DNS settings. First make sure the system is back online, then reconnect the client. If it fails after every wake but works when you reconnect manually, the issue is likely related to the resume process. Saving the state and error from before and after waking is more useful than reinstalling repeatedly. Also check whether the system proxy still points to a local process that has exited.

Multiple VPNs, proxies, virtual network adapters or enterprise security components may compete to control routes and network traffic. For troubleshooting, exit nonessential tools normally and leave only the network components you need before reproducing the issue. On managed devices, don't disable required organizational software without permission; ask your administrator first. If closing a tool fixes the problem, that suggests a compatibility issue. It isn't a reason to delete unfamiliar system services or drivers.

Allowing background activity only addresses device-side conditions; it doesn't guarantee a route won't disconnect. Test screen lock, sleep, network changes and destination timeouts separately.

Choose a fix based on conditions you can reproduce

If one route disconnects frequently, keep the device and network the same and try the same task on another route. If all routes drop on the same network, compare them on a different network. If only one app disconnects while the browser and other tasks work, check app routing, session timeouts and the destination service. Change one clear variable per test so a temporary recovery isn't mistaken for a fix.

Don't change MTU, connection timeouts or low-level transport settings at random. The right parameters depend on the client and network; copying settings blindly can break apps that already work. If support asks you to test a parameter, save the original value, agree on what the test is meant to show, then decide whether to keep or restore it. Start with permissions, background restrictions, network changes and alternative routes before sending support a diagnostic report with context.

Consider submitting a support ticket if you can reliably reproduce the disconnect, the client keeps closing after the screen locks, the same disconnect error occurs on different networks, or the system network remains broken after reconnecting. Include the action that triggered it, whether the app was in the foreground, any system alert and how you restored the connection. Share only the relevant error excerpts, not entire personal files. If you have a working alternative route, you can keep using it while the original issue is investigated.

Separate fetching, updating and connecting

A subscription link lets a client fetch the configuration associated with your account. Fetching a subscription, downloading its configuration and connecting to a route are separate actions. An update failure doesn't necessarily mean saved routes will stop working immediately, but changes to those routes won't sync. Conversely, a successful update only means the client received the configuration; it doesn't prove that every route works on your current network. Note which action failed so you don't mistake a subscription issue for a connection issue.

Check your account and plan status in the user panel, then retrieve your subscription using the method shown there. No email address is required; create an account with a username and password. If you already have an account, sign in with it instead of creating new accounts to work around a configuration issue. Your subscription is an access credential: don't post it in public forums or enter it on unfamiliar conversion sites. Redact authorization parameters in links and personal session details from troubleshooting screenshots.

Use the error message to tell whether the download completed

If you see a network timeout or can't resolve the subscription domain, first check whether your basic network can reach the user panel. Then compare update results with the client disconnected and with a working connection. Some clients use their own network settings for updates, which may differ from your browser's. If the panel loads but the update fails, that only confirms the browser path works; check whether the client's update request is using a broken local proxy or an inactive route.

If the client reports an unsupported format, a parse error or missing fields, check whether the import method matches the client's expected format. Don't use a regular webpage URL as a subscription link, or copy the link with quotation marks, line breaks or extra explanatory text. Use the import option for your client provided in the user panel. If copying manually, check that the beginning and end are intact—but don't post the full link publicly to prove that you copied it correctly.

Handle old configurations, empty lists and duplicate imports

If the update completes but you see no routes, check that you're using the newly updated configuration rather than an older one with the same name. A client may store several configurations and remain on the previous group after a successful import. Check which configuration is active, then see whether the route list needs to be expanded. If only some routes appear, check for an active filter or favorites view. Don't delete every old configuration before confirming which one is active; you could lose a working fallback.

If the same account updates successfully on another device but consistently fails on this one, compare the import method, client settings and local network. Keep the old configuration, import a fresh one as a clearly named test configuration, then remove duplicates after confirming it works. If every device gets the same account or subscription error, check the user panel and contact support instead of reinstalling on each device. Repeating the request won't automatically fix an account-side issue.

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

The address above only illustrates what a subscription link looks like. It isn't a real YuanVPN subscription and can't be imported. Retrieve your actual subscription from the user panel. The authorization portion of a link grants access; don't include it in ticket titles, public screenshots or shared documents. If support needs to identify your account, provide only the information requested in the ticket. Don't share your password or proactively attach the full subscription link.

Account data allowance and subscription link security

If an update error is related to exhausted data or plan status, check the applicable terms on the Plans page. Monthly subscription data resets on the activation date each month; when you upgrade mid-cycle, the price difference is converted into remaining days. Data packages remain valid until used and never expire. Clearing your local cache won't change these rules. An update failure alone isn't a reason to upgrade—base your next step on the status shown in the user panel.

If you suspect your subscription link has been exposed, use the security options available in the user panel. If you can't find a relevant option, submit a support ticket instead of assuming that changing your password will invalidate the old link. After resolving the issue, reimport the subscription on affected devices and check that the old configuration is no longer enabled. For a full explanation of subscription links and import steps, see the guide to getting, importing and updating subscription links. This section focuses on identifying where the problem occurred.

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

Desktop apps, browsers and background services may use different network methods. Some follow the system proxy, some have their own proxy settings, and others need the client to manage a broader range of network traffic. So if “the browser works, but the app doesn't,” first investigate differences in how requests are routed rather than assuming the route is down. Check how the same destination works in a browser, then note whether the app fails during sign-in, resource loading, message sending or a persistent connection.

Check whether the app has its own proxy settings. An old local address, port or automatic configuration URL may override the system settings. Don't configure proxies in several places and expect the system to choose the right one. Find out which settings the app uses, then compare them with the values shown by your client. Some apps need to be fully quit, including background processes, before they apply changes. Closing the visible window alone may not be enough.

Compare modes to find a missing rule

If your client supports it, temporarily compare rule mode with global mode. If an app fails in rule mode but works globally, its requests may be taking an unsuitable route. Check the client's connection log to find the domains accessed when the failure occurred, the matching rules and the selected policy. Don't add a rule for just the app's main site: sign-in, static resources, attachments and live connections may use different domains. Check each one against actual requests.

If global mode still doesn't cover the app but the browser works, check whether the app ignores the system proxy. If your client offers a virtual network adapter mode, read its permission details before using it for comparison. Then confirm system permissions and network components are working. A checked virtual adapter option doesn't prove that traffic is being intercepted. Don't change system routing tables without understanding the impact; use actual request logs to see whether traffic is reaching the client.

Special cases with AI tools and media apps

AI tools may use separate processes for web sign-in, API calls and persistent connections. If you can open the account page but can't submit a task, check the network path for the API domain and the process making the request. Developer tools such as Cursor may send requests from an extension process or remote environment, where your local browser proxy settings may not apply. First determine whether the request comes from your computer, a container or a remote host. Then check which part the local client can affect.

Streaming apps may cache region, session and resource details. If they still show the previous region after you switch routes, that doesn't necessarily mean the change failed. Start a fresh app session, then check access under the destination service's rules. Don't present network reachability as a promise about content availability; that also depends on the platform, account and regional rules. For AI tools, see the AI acceleration guide. For route types, see Route details.

Restore your usual routing and keep changes minimal

Once you've found the cause, keep only the necessary rule changes and note what each one is for. Broad rules can send local services or apps that used to work down the wrong path, making future troubleshooting harder. If a new rule doesn't help, restore the original value before the next test. Don't leave temporary test settings mixed into your everyday configuration without documenting them. Otherwise, after a subscription update, it may be hard to tell whether an issue came from the service configuration or a local override.

When reporting an app issue, include the app name, failed action, routing mode and whether the request appeared in the client log. If it never appeared, focus on traffic interception. If it reached the client but the destination rejected it, focus on the exit route, destination rules or account status. Redact documents, conversations and authorization details from screenshots. This helps support focus on the relevant layer instead of asking again whether websites load.

First confirm that it's really a DNS issue

DNS translates domain names into addresses that your device can connect to. “Server not found” in a browser or a resolution failure in the client log are clear reasons to check DNS first. Connection timeouts, account rejections and certificate errors aren't necessarily DNS issues. Note the failed domain and exact error, then compare other domains. If none resolve, check the local resolution path. If only one domain fails, also consider the destination's status and your routing rules.

Being able to open one address doesn't prove DNS is working properly. Don't replace a website's domain with a bare IP address and assume that's a valid test. Modern websites rely on domain names, certificates and virtual host information; connecting directly to an IP can produce a completely different result. Instead, use a system lookup tool to see whether the domain resolves, then compare that with the actual browser or client request. A command-line lookup only tests the resolution path it uses, not every app's.

Use system tools and keep the original results

On Windows, run nslookup in a terminal. On macOS or Linux, use the system's nslookup, or dig if it's already available. The examples below use a public test domain; for troubleshooting, replace it with the domain that's failing. Check whether the query times out, returns an address and shows the expected resolver. If the tool isn't installed, don't download it from an unfamiliar site just for troubleshooting; start with the diagnostics already available in your client.

nslookup example.com

dig example.com

curl -I https://example.com

These commands aren't a sequence of fixes you have to run. The earlier queries check domain resolution; curl shows the HTTPS request result from your current command-line environment. Whether the terminal uses a proxy depends on its environment settings. If a lookup returns an address but curl fails, that doesn't prove DNS is entirely ruled out. A browser may use its own secure DNS, and a client may have its own resolution policy. Check each request path separately.

Trace where the system, browser and client get DNS results

Check whether your system network settings have a manually configured resolver, whether the browser uses separate secure DNS and whether the client intercepts DNS. Having several settings doesn't automatically mean something is wrong, but it can explain why changing system DNS has no effect. First note which settings are active, then remove any clearly outdated or unused manual overrides. Don't combine resolvers and rules from different guides without knowing which one handles the request.

Some clients use a virtual address or a Fake-IP-style resolution method, so an app may see an address that differs from a public lookup result. That isn't necessarily an issue. What matters is whether the client can properly intercept and forward the request. If an app bypasses the client, or a local network service isn't compatible with this mechanism, check the client's instructions and exclusion rules. Don't delete the whole configuration just because you see an unfamiliar address, or edit your system hosts file to hide the problem.

First find out which resolver is handling the request, then decide which cache to clear. Clearing a cache won't fix a broken resolver, incorrect routing or a problem with the destination service itself.

Caches, network changes and local network boundaries

After changing DNS settings or routes, old cache entries and existing connections may temporarily affect what you see. Fully quit the affected app, then reopen it. If needed, use the official instructions for your operating system to flush the cache. Make sure the new settings have taken effect first; otherwise, you'll get the same error again after clearing it. If the problem started after sleep or a network change, confirm that the system received the correct settings for the current network, then reconnect the client.

Local devices, internal organization domains and public websites may need different resolution paths. If devices like printers, file sharing or internal services stop working after enabling broader DNS interception, check whether local domains should continue to use direct connections and local resolution. Have an administrator verify settings on managed networks; don't replace required internal settings with a public resolver. The goal is to restore the right path for each use case, not send every domain to the same resolver.

If the same domain keeps failing to resolve on different networks and routes, submit a redacted query result, the source of your DNS settings and relevant client log excerpts. Internal domains and resolver addresses may reveal organizational information, so don't share them without permission. For a combined check of DNS routing and the actual exit route, see the guide to checking whether your connection is working as intended. Don't treat a single lookup as proof of overall privacy or connectivity.

If you see a device limit warning, check where it came from

YuanVPN allows unlimited simultaneous devices. If you see a warning such as “device limit exceeded,” first check whether it came from the YuanVPN client, the user panel or a third-party platform you're using. A third-party platform may have its own session or device rules, which aren't covered by this service's device policy. Note the full message and where it appeared. Don't assume from a clipped alert that your subscription needs more device slots, and don't buy the same plan again just to clear it.

If the warning appears in an interface for this service, first confirm you're signed in to the intended account, the current configuration belongs to that account and no outdated client or saved configuration is interfering. Unlimited devices doesn't rule out permission, network or configuration conflicts on a device, and it doesn't override limits set by a destination website. If you're using the right account and the warning persists, save the screen and steps that triggered it, then submit a support ticket. Don't invent an extra device limit to explain the problem.

Write a support ticket that others can reproduce

Submit the issue through support tickets in the user panel, or check the Support page for available contact options. Give the ticket a title describing the symptom and context, such as “Connection drops after screen locks” or “Subscription update fails with DNS error.” Organize the details by time, platform, selected route, action and result. Say whether it worked before, what you changed recently and whether other devices have the same issue. Those details are more useful than a vague description.

Find system and client details in Settings or About, and report what you see rather than guessing the version. For the route, include its name, region and type. For the network, describe the situation—such as home Wi-Fi, public access or a cellular network—without volunteering private addresses. Name the destination domain or app, when it failed and the exact error. The time can help with comparisons, but don't present one incident as a long-term outage.

Suggested ticket format: what happened; the conditions; how to reproduce it; what you've already tried; and what changed after each attempt. Subscription links, passwords and session credentials aren't necessary attachments.

Share only the necessary logs and screenshots

Client diagnostic logs may contain visited domains, device paths, local network details or authorization parameters. Find the error excerpt around the time of the issue, check it for sensitive content, redact as needed, then submit it through a support ticket. Don't attach your entire desktop, private documents or full browsing history by default. If you're unsure whether a field is safe to share, describe the error first and ask support what they need. Treat subscription QR codes in screenshots as access credentials and redact them too.

“No activity logs” describes YuanVPN's service privacy policy; it doesn't mean your device can't generate local diagnostic information for troubleshooting. Understand the service policy, local client diagnostics and material you choose to submit in a support ticket separately. For questions about data handling, see the Privacy Policy. Collect only what's relevant to your issue. Don't send more than needed to prove it, and don't publish support conversations as troubleshooting instructions.

Verify the fix and undo temporary changes

After resolving the issue, repeat the action that failed and check that local services that already worked still do. Restore temporary global mode, test rules and manual proxy settings to a suitable everyday configuration. Make sure no leftover proxy points to a client that's been closed. If you created duplicate configurations while testing, confirm the active one works before removing the extras. Keep a brief note of the change that fixed the issue so you can refer to it next time instead of starting over with guesswork.

If you find that your data allowance doesn't suit your usage, compare monthly subscriptions and data packages on Plans & Pricing instead of treating a capacity issue as a route problem. Payment methods include Alipay / WeChat Pay / USDT. This service offers a 14-day no-questions-asked refund; see the Terms of Service for details. For refund or billing questions, contact support through a ticket. Troubleshooting won't change your billing method, data reset rules or refund terms.

Troubleshooting is complete when the original task works again, the result is repeatable and no temporary settings are interfering with other apps—not just when a status indicator turns green. If the issue persists, give support the layers you've already ruled out; there's no need to repeat every step from the beginning. For first-time installation and import, follow Quick Start. For brief answers to common questions, visit the Help Center. This page is the full handbook for troubleshooting by symptom.