V2Ray Troubleshooting Guide

01 / App → Local entry point → Core → Outbound

No internet: Trace the connection path

“Client connected” usually means only that the local service has started. It doesn’t confirm successful authentication with the remote server or that browser traffic is using the proxy. Before troubleshooting, note the client name, operating system, selected server alias, system proxy mode, routing mode, and Tun status. Also record which site failed and when. Don’t start by deleting configurations or resetting the network. The original logs and settings are essential for identifying the cause; once cleared, they’re hard to compare.

Check the network first, then the local entry point

Quit the client, restore your original system network settings, and test a site you can normally access directly. If direct access also fails, check whether Wi-Fi requires a sign-in page, the Ethernet cable is connected, the network adapter has an IP address, and a manual proxy is still configured. A captive portal on public Wi-Fi may not appear while the proxy is enabled, so sign in before starting the client. If only one site fails over a direct connection, that doesn’t prove the whole network is down. Test at least one unrelated site to compare.

Once the basic network is working, reopen v2rayN, select an imported server with complete settings, turn off Tun, and test using system proxy alone. Check the local listening address and port in the client settings, and confirm the core starts without errors in the logs. The command below applies only if the local port is 10808 and the entry point accepts HTTP proxy connections. Replace the port if yours is different. This bypasses the question of whether the browser uses the system proxy, but it doesn’t bypass the core’s routing rules.

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/

If the command returns response headers, even for an access-denied response, the request has usually reached an HTTP service; check the certificate and response body to confirm the target. If it can’t connect to the local port, first check whether the core is running and the port matches. If the proxy tunnel or remote handshake fails, troubleshoot the server connection instead. Don’t use an HTTP entry point as a SOCKS proxy. With the wrong protocol, the port may accept a connection, but it can’t correctly process the request.

Use logs to distinguish the entry point, outbound connection, and target site

Open the v2rayN log window, note the time, make one request to the target site, then check for the corresponding new log entry. If there’s no relevant entry, the app may not be using the proxy—or the current log level may not record successful requests. No log alone doesn’t prove that traffic failed to reach the client. Temporarily increase log verbosity and compare with a request made using an explicit proxy. A connection refused error means an endpoint was reached but rejected the connection. A request that keeps waiting until it times out calls for checks of the address, network path, and server status.

If the explicit proxy works but the browser doesn’t, check browser extensions, custom proxy settings, and secure DNS, then troubleshoot app interception in the system proxy section. If all proxy requests fail but direct access works, try a working server from an independent configuration source. If only one domain fails, check its routing rule and DNS results instead of immediately replacing the entire subscription. The server, target site, and client are separate components; test each one.

When done, turn off temporary debug logging, restore the system proxy or Tun mode you need, and reopen the app that initially failed. Browsers may reuse existing connections, so quit and relaunch if needed. Record which change affected the result, not just that it worked after a restart. Knowing the change makes recurring issues easier to diagnose; a restart alone doesn’t distinguish a setting fix from a temporary network recovery.

02 / Address → Port → Transport → TLS → Authentication

Server timeout: Identify the handshake stage

A server test timing out doesn’t necessarily mean the server is offline. The test may first resolve the server’s domain, establish a transport connection, complete the security handshake and protocol authentication, and finally request a test URL. Any of these steps can fail. Check whether the test uses a TCP connection check, a real connection, or a web speed test; each covers a different path. For configurations that don’t use TCP transport, a basic TCP probe doesn’t directly indicate whether the actual protocol works.

Check the server endpoint before changing protocols

In the server editor, verify the address and port. Make sure the address field doesn’t include https://, a path, or trailing spaces, and confirm the port matches the one the server actually listens on. For a domain name, first check that it resolves; for an IP address, confirm it’s still the current server address. On Windows, use the command below to test TCP reachability, replacing the example domain with your server address. Success confirms a TCP connection, not protocol authentication, TLS, or a successful request to the target.

Test-NetConnection -ComputerName example.net -Port 443

If the test fails, try another network, such as a mobile hotspot, without changing the configuration. If it works on the other network, investigate the original network’s outbound access, firewall, or routing restrictions. If it fails on both, check the server listener, inbound firewall, and whether the address is outdated. If you don’t administer the server, send the configuration provider the failure time, endpoint, and error stage. Don’t randomly cycle through ports; a port that doesn’t match the server will only cause another failure.

Distinguish TLS, transport settings, and protocol authentication

If the connection still fails after reaching the port, check the logs for certificate validation, handshake, authentication, or transport-path errors. For TLS, verify the server name—the field commonly called SNI—and make sure the system clock is accurate. The certificate name usually doesn’t need to match the IP address used to connect, but it must match the server certificate and configuration requirements. For WebSocket, check the path and Host. For gRPC, check the service name. Putting the server domain in every field isn’t a universal fix.

For REALITY, check the public key, short ID, server name, and other fields against the configuration source, in addition to the server address. REALITY uses different settings from standard TLS; don’t reuse the same parameters. Identity fields for VLESS, VMess, and Trojan aren’t interchangeable. After updating a subscription, an old server entry may remain in another group. Make sure the selected entry is the new one, even if its alias looks the same. For more on certificate errors, see System clock and SNI troubleshooting notes.

Don’t hide handshake failures by permanently skipping certificate validation, or keep increasing the timeout to make timeouts go away. The timeout threshold changes how long the client waits before failing; it can’t fix an incorrect address or authentication settings. After correcting a field, make another real request and check whether the logs advance to the next stage. If the port is reachable and the handshake succeeds but the test URL fails, the issue may be with the server’s outbound connection, DNS, or the test target. Try another target rather than continuing to change the client’s identity fields.

03 / Fetching a subscription ≠ connecting to a server

Subscription failure: Check retrieval and parsing

A subscription update is a separate web request, and may use a different network path from the selected server. First determine whether the request failed to download content or downloaded content that the client couldn’t import. The former often involves the URL, network, account status, or certificate. The latter may mean the response was the wrong page, the format was incompatible, or some fields aren’t supported. Keep your existing servers when an update fails; don’t delete the group. An older configuration may still connect and help restore the network path needed to fetch the subscription.

Check the URL and subscription group

In v2rayN, open the relevant group under “Subscription group” and check that the subscription URL was copied in full. Pay particular attention to query parameters after the question mark, trailing characters, and accidental line breaks. A token in a subscription URL is an access credential; don’t paste it into public logs, screenshots, or online decoding tools. Copying from a chat app may add punctuation, and a rich-text link’s label may not show its actual URL. Get the link again using the copy option provided by the configuration source.

Make sure you’re updating the same group you edited, then try “Update subscription (without proxy).” If your local network can reach the subscription service, this avoids relying on a server that isn’t working. If the direct request times out and the current proxy has been verified with a real request, try updating through the proxy. If both methods fail, note each error. Don’t assume the client used the expected route based on the button label alone; check the logs and current proxy status too.

Choose what to check based on the response

An unauthorized or forbidden response usually calls for checking your account status, subscription token, and server-side permissions; clicking update repeatedly won’t change permissions. If the request is rate-limited, stop retrying and wait for the interval set by the server. For certificate errors, check the device clock and certificate chain. If the request succeeds but no usable servers are found, the response may be a login page, maintenance page, verification page, or a format for another client. A successful HTTP request doesn’t guarantee valid subscription content.

A subscription may contain a collection of client-supported share links or encoded content. Not every block of text can be imported by every client. Don’t rename another configuration format and expect it to import, or paste a subscription URL into “Import share links from clipboard” expecting all clients to recognize it. Choose the import option for the client type specified by the source. If the client doesn’t recognize a new subscription field, check the client selection on the download page, back up your configuration, then update the client. Don’t edit the entire subscription by hand.

Check the selected entry after updating

When the update finishes, confirm the group contains the expected servers, then reselect the entry you want to test. Some group settings retain old servers or keep the current selection, so “Update complete” doesn’t necessarily mean every entry was replaced. Matching aliases don’t guarantee matching addresses, ports, or security settings. If the connection fails immediately after an update, compare the old and new protocol, transport, and security settings. Then ask the source whether the server was moved or its settings changed.

If scheduled updates fail but manual updates work, check whether the client was running when the scheduled task ran, whether the system was online, and whether a usable server was available through the proxy. A startup-order issue doesn’t require changing the subscription format. Once connectivity is restored, verify the complete flow: manual update succeeds, group contents appear, a new entry is selected, and a real web request works. For creating a subscription group, follow the quick-start guide; this section covers where that workflow can fail.

04 / Measure throughput, latency, and stability separately

Slow speeds: Set up comparable tests

“Slow speeds” can mean at least four different things: slow initial page loads, slow sustained downloads, video buffering, or intermittent disconnections. Slow initial loads often involve DNS, handshakes, and connection setup. Slow downloads are more likely to involve bandwidth, congestion, or target-side throttling. Disconnects also call for checks of Wi-Fi, device sleep, and server connection policies. First note exactly when the problem occurs, then choose a test that matches it. Low latency doesn’t mean high throughput, and one speed test can’t represent performance across every site.

Keep the network, target, and test time consistent

For each test, use the same device, network, file, or web page. Temporarily pause system updates, cloud sync, and other high-bandwidth tasks. Compare over Ethernet or a stable Wi-Fi connection where possible, so wireless interference isn’t mistaken for a server problem. Run several tests and note the time. Don’t test many servers at once: concurrent tests compete for local bandwidth and may hit connection limits on the remote side. Wait for each test’s connections to finish before starting the next.

First compare direct access to a reachable target, then compare the proxy path. Using different targets can show whether the local network has a general problem, but it can’t measure proxy overhead. For a fair comparison between two servers, use the same target and request method. A download source may throttle requests based on source IP or offer only a slow outbound route. So if changing servers makes it faster, that shows the new combination works better—not necessarily that the original server is slow overall.

Separate DNS lookup time from transfer time

If each site takes a long time to open the first time but downloads normally afterward, check for DNS timeouts, IPv6 fallback, and TLS handshake delays. A browser’s developer tools network timeline can separate DNS lookup, connection, waiting for a response, and content download. With a proxy, some stages may be handled by the proxy, so interpret the timings in context. Use an explicit proxy request to rule out browser extensions, then compare resolution paths in the DNS section. Don’t change buffer sizes or thread counts just because the first page load is slow.

If transfer speeds stay low but pages respond normally, try an unrelated download source to see whether only one target is slow. Then switch to another local network to determine whether the bottleneck is the local connection or the remote route. Routing rules can also affect results: a large download that should go direct may be sent through the proxy and take a longer path, while a site that should use the proxy may be sent direct and repeatedly retry. You can temporarily switch routing modes for comparison, but once tested, fix the specific rule rather than ignoring your split-routing needs.

Adjust advanced settings only when they match the symptom

Don’t assume multiplexing must always be enabled. Its effect depends on the core, protocol, and server support. It may reduce some connection overhead, but packet loss can also affect multiple requests. UDP forwarding likewise depends on the client, outbound protocol, server, and network; no single switch can guarantee it will work. For voice or gaming issues, first confirm the app is actually using the proxy and that the UDP path is established. Don’t rely only on whether web pages load.

If small pages work but large requests stall with Tun enabled, the path MTU is one possible cause, not a confirmed diagnosis. Turn off Tun first and compare with an explicit proxy. Only if the difference is consistently reproducible should you adjust the MTU using the setting available in your client; keep the original value. Corporate networks, virtual machines, and nested tunnels affect the effective packet size, so someone else’s value may not work for you. Retest the same large request after each change.

If the issue occurs only during regular peak hours, keep comparisons from different times and report them to the service provider. The client can’t fix upstream congestion or insufficient capacity on the remote outbound route. After testing, restore the log level and routing mode, and reopen any apps you temporarily closed. This keeps your test setup close to everyday use; otherwise, a successful test may not explain why normal browsing is still slow.

05 / Server resolution and target-domain resolution are separate paths

DNS issues: Find out what is resolving the domain

First distinguish the server’s domain from the target site’s domain. The client must resolve the server address before it can connect remotely. The target site’s domain, meanwhile, may be resolved by the app, operating system, core, or remote server. A browser with secure DNS enabled may also use its own resolver. So a successful system lookup doesn’t mean the proxy core got the same result, and a website working through the proxy doesn’t mean system DNS is fixed. Start by mapping the actual resolution path instead of immediately switching resolver addresses.

Test system and core resolution separately

On Windows, use the command below to check the system’s DNS response. Note the address type, whether the request timed out, and whether results change on another network. A domain returning several valid addresses isn’t necessarily a problem; content delivery services may return different results depending on region and network. Connecting to an HTTPS site by IP isn’t a reliable substitute because the server may rely on the domain for certificate validation and virtual hosting. A certificate error alone doesn’t prove the original domain resolution was wrong.

Resolve-DnsName example.com

Check the core logs for DNS timeouts, unreachable resolvers, or no available addresses. If the server address is a domain and remote DNS must go through a proxy that hasn’t connected yet, startup can get stuck in a dependency loop: connecting to the proxy requires resolving the server domain, but resolving that domain requires connecting to the proxy. Break the loop using the client’s bootstrap resolver or server-domain resolution settings. Make sure the address needed at startup can be resolved over the current network; don’t force every lookup through a tunnel that isn’t up yet.

Understand how domain strategies affect routing

In routing, AsIs, IPIfNonMatch, and IPOnDemand control how domain resolution is used for route matching. They aren’t simply three “DNS speed settings.” AsIs doesn’t actively resolve a domain to an IP for this step. IPIfNonMatch resolves the domain and tries IP rules when no domain rule matches. IPOnDemand triggers resolution when a matching rule requires an IP. Outbound connections may still need DNS resolution, so routing strategy and all DNS behavior aren’t the same thing.

The example below shows part of the core routing configuration, not a complete configuration. Don’t replace a client-generated configuration file with it. It illustrates matching domain categories first, followed by address categories. It requires the corresponding geodata files and an outbound named direct. When editing routing settings in v2rayN, make sure the client applies the rules to the routing set currently in use. Rule order and other rules earlier in the list can still affect the result.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

Check browser caching, IPv6, and Tun interception

If the issue occurs only in a browser, check secure DNS, extensions, and cache. If all apps are affected, check the system and core. An IPv6 lookup succeeding doesn’t mean the current network has a working IPv6 route; disabling IPv6 isn’t a universal fix either. Compare address families and connection logs first, and confirm whether one address type is consistently failing before changing DNS or outbound settings. After a change, you may need to wait for the cache to expire or restart the app so it stops reusing old results.

Whether Tun intercepts DNS depends on the client implementation, system routing, and app behavior. Don’t assume that enabling Tun sends all DNS requests through the same path. If the logs show unexpected virtual addresses, first check whether a FakeDNS-style feature is enabled. Don’t add those addresses directly to the system hosts file. Record existing results before clearing the cache, then compare again after changing DNS settings. For more on prefixes and match order, see Custom routing rules notes. For split-routing setups, see Direct, proxy, and block rules.

06 / Check system settings, app settings, and virtual adapters separately

Proxy not working: Check how traffic is routed

The system proxy is a setting that apps can use; it isn’t a master switch that routes all traffic. Tun routes traffic through a virtual network interface and system routes, so it works at a different layer. Start by enabling just one method. For a desktop browser, begin with “Automatically configure system proxy.” Confirm that both the local entry point and remote connection work before testing Tun. Enabling both methods and changing DNS at the same time mixes together different failure causes and makes it hard to tell which layer affected the result.

Check that the system settings match what the app actually uses

In the v2rayN status bar, select “Automatically configure system proxy,” then open the operating system’s proxy settings and verify that the local address and port were set. The port must match the client’s listening entry point; checking only that the address is loopback isn’t enough. If system settings keep reverting, look for another proxy app, browser extension, device management policy, or security software that may be changing them. Don’t let multiple clients manage the system proxy at once or repeatedly overwrite the same settings.

On Windows, some command-line programs and background services don’t use the desktop system proxy. Some read environment variables, while others have separate proxy settings. If a browser works but a command-line app doesn’t, that doesn’t necessarily mean the client is broken. Check the app’s documentation for its proxy settings, or compare with a request that supports an explicit proxy parameter. On macOS, proxy settings are tied to the current network service. After switching between Wi-Fi, Ethernet, or another service, check the active service, not just one configured earlier.

Use a single entry point to check ports and bypass rules

Check the system proxy bypass list and whether the browser has a direct-connection rule for the target domain. Bypassing local network addresses is usually reasonable; don’t force all local traffic through a remote server just to make it appear in the logs. If the target is being bypassed, adjust the specific rule to match how you need to access it. Connecting other devices to the local proxy is a separate use case involving the listening address, firewall, and access control. Don’t enable LAN listening just to fix a browser on the same device.

If Tun fails, check permissions and routes first

Turn off other VPN or tunnel apps, then grant the permissions required to create a virtual interface and change routes as prompted by the client. On Windows, this often requires administrator privileges. On other desktop platforms, follow the current client’s permission prompts. After enabling Tun, check the logs to confirm the interface was actually created; don’t rely on the switch appearing to be on. If a permission prompt was dismissed, the interface may not reflect the underlying state. Check the logs and actual interface status.

If enabling Tun cuts off internet access, turn it off and confirm the network recovers before checking network adapters, virtual machine networking, enterprise access software, and leftover routes. If the remote server connection is mistakenly routed back through its own tunnel, it can create a loop. Conflicting DNS interception can also make every domain appear to fail. Don’t delete system routes in bulk if you’re unsure what they do. Use the client’s normal stop function to undo its changes, then disable conflicting apps one at a time for comparison. Keep a way to restore connectivity.

After the fix, test apps that need the proxy, local network services, and system connectivity checks separately. A system network icon may show an error because its test target is unreachable; verify with an actual request. For the v2rayN main window, status bar, logs, and settings, see the v2rayN main window guide. Make the setup clear: which apps use the system proxy, which need their own proxy settings, and when Tun is necessary.

07 / Troubleshoot the app launch and core startup separately

Startup failure: Preserve the state before recovery

No window after double-clicking, a window that opens and then exits, and a GUI that stays open while the core stops are three different issues. First check Task Manager for an existing client process, and see whether the window is minimized to the system tray or on a disconnected monitor. Don’t double-click repeatedly to launch multiple instances; they may compete for local ports or configuration files, turning one issue into a multi-instance conflict. If you need to stop a process, save the logs and try a normal exit first. Force-quit only if it’s unresponsive.

Check the package format, architecture, and writable location

Check the operating system and processor architecture on the client download page. The Windows desktop and classic WPF editions use different UI technologies and may need different runtimes. Follow the package instructions and startup prompts; don’t assume the requirements for one edition apply to all. On Linux, distinguish between deb and rpm packages. On macOS, check whether the device uses Apple Silicon or Intel. An architecture mismatch, unsupported OS version, or missing dependency can’t be fixed by changing server settings.

If you’re using a portable, extracted version, fully extract it to a directory your account can write to. Don’t run it from the archive preview or copy only the main executable without its supporting files. If saving settings fails, check directory permissions, free disk space, and whether a sync app has locked files. Check security software logs to see exactly which file was blocked. Don’t disable device protection entirely just to launch the client, and don’t download supposed missing components from unknown sources.

For core startup failures, start with the first error

If the GUI works but the core won’t start, check the earliest error in the logs rather than the final “stopped” line. A port conflict, invalid configuration syntax, unknown field, missing geodata file, and insufficient permissions all require different fixes. If a local listening port is in use, identify the process before taking action. Don’t terminate an unfamiliar system service. On Windows, use the commands below to check the port and process. Replace the example port with the actual one used by the client.

Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

The process ID in the second command is an example; replace it with the value returned by the first command. If the port is held by another client instance, exit the duplicate. If it belongs to an app you need to keep, change the local listening port and update the system proxy and any in-app proxy settings to match. Changing only one setting will turn a startup issue into a local connection failure. If there’s no result, check whether the error refers to a different listening port rather than assuming every conflict uses the same one.

Use the object and field named in the logs to locate configuration errors. Extra commas, incorrect value types, and unclosed quotes can make JSON parsing fail. Even if the JSON parser accepts a file, it may still violate the core’s field requirements. Custom snippets must be compatible with the core in use; Xray and V2Fly don’t necessarily support the same fields. A client-generated runtime configuration may be overwritten on restart, so make changes in the client settings or custom configuration input, not just in a temporary output file.

Use a minimal configuration to check for user data issues

Before recovery, back up subscription groups, routing rules, custom DNS settings, and any user settings you need. Protect any subscription credentials they contain. Quit the app, then use a separate configuration directory or rename the original one as supported by the client, and test with a minimal configuration. Don’t move the database while the app is running. If a clean configuration starts successfully, restore settings one at a time: add one server and test it, then restore routing and advanced options. Restoring all the old data at once may bring the issue back with it.

If the app still crashes with a minimal configuration, check the operating system’s app error logs, permission prompts, and runtime details before reinstalling. When reporting the issue, include the steps to reproduce it and the error text. Remove identity fields, subscription URLs, and sensitive parts of personal directory paths. For more configuration error examples, see Diagnosing core startup failure logs. Recovery is complete only when the core keeps running, the local entry point accepts connections, and settings remain correct after restarting the app.

08 / VPN permission → App coverage → Background operation → Network changes

Android troubleshooting: Connection and background drops

Use v2rayNG on Android by default. Consider v2flyNG only when you specifically need the V2Fly core. The two clients may support different configuration features and fields, so don’t overwrite one with the same complex configuration to troubleshoot. First make sure the package matches your device architecture. Most newer devices use arm64, but check your device’s system details. If you’re unsure, see the universal package notes on the download page. If installation fails, check the system’s error message; don’t modify the package or bypass system signature checks.

A successful VPN permission prompt doesn’t confirm a remote connection

On the first connection, accept the system VPN permission prompt and check whether the system shows the connection. If another VPN app is running, disconnect it before testing v2rayNG. Android generally allows only one regular VPN service at a time in the same user or profile. Apps repeatedly taking over the connection can cause seemingly random disconnects. The key icon indicates that the local VPN service is active; it doesn’t confirm server authentication or prove that every configuration in the subscription works.

In v2rayNG, select the configuration to test, connect, open the app log, and make one real web request. If the error says the server couldn’t be resolved, follow the DNS section. If the handshake fails, check transport and security settings as described in the server timeout section. To compare networks, test the same configuration over Wi-Fi and mobile data; don’t change servers at the same time. Mobile data limits, roaming permissions, and system network controls can also affect results. Check each one in system settings.

Check per-app proxy settings and Private DNS

If only one app can’t connect, check per-app proxy settings and determine whether the mode is “proxy selected apps only” or “bypass selected apps.” Selecting the same apps has the opposite effect in each mode. Check whether the target app is in a work profile, cloned-app environment, or another user space that may not be covered by the current VPN. After changing the app list, rebuild the connection if the client requires it, then fully quit and reopen the target app so it doesn’t reuse an old connection.

The system’s “Private DNS” name and menu location vary by device. It may interact with the client’s built-in DNS and the browser’s secure DNS. If the issue occurs only on one type of network, record the original settings, temporarily switch to the system’s automatic mode for comparison, then check the client’s domain strategy and whether its resolvers are reachable. Don’t change all three settings at once; even if access returns, you won’t know which one caused the issue. If a website works but one app doesn’t, check that app’s proxy and network restrictions too.

For lock-screen disconnects, check background restrictions first

If the client works in the foreground but disconnects after the screen has been locked for a while, check battery optimization, background activity permissions, auto-start restrictions, and system data saver mode. Allow the client to run in the background and make sure the system permits it to use mobile data in the background. Settings menus vary by device manufacturer; follow the actual menus on your device instead of looking for an exact label. Keeping the app in the recent apps list doesn’t replace all background permissions. Compare logs and connection status before and after locking the screen to confirm whether the service was stopped.

If your system supports always-on VPN, consider enabling it after the basic connection is stable. “Block connections without VPN” changes what happens to network traffic when the connection drops; the system may block all regular internet access while the client is stopped. Note this setting during troubleshooting so a system-level block isn’t mistaken for a server issue. To temporarily restore direct access, first understand and adjust the relevant policy instead of just turning off the client’s connection. For devices managed by an organization, follow its device policies.

A brief delay or reconnect after switching networks may be caused by stale connections, an address change, or system network recovery. If the connection always fails after a switch, check whether the VPN reconnects automatically, whether the server domain is resolved again, and whether the new network can reach the remote port. Finish by testing a real request in an app you use; don’t rely only on the in-app latency test. For initial import and connection steps, see the setup guide. To change the package type, return to Android downloads and back up your current settings first.