V2Ray Troubleshooting Guide

01 / Check the scope first

No internet access: start with the local connection

“Connected” usually means the client has started handling traffic; it doesn’t mean the destination site is reachable. If a page won’t load, note when it happened, which node was in use, the proxy mode, and which apps were affected. Then check whether all connections are down or just one site. Keep these conditions consistent so your tests are comparable. If you change both the node and the network, a temporary fix won’t tell you which change helped.

Separate basic network access from the proxy path

In the client, clear the system proxy and temporarily turn off TUN mode. Then try a site that normally works without a proxy. If it still fails, check whether the Wi-Fi network requires a sign-in page, the cable is connected, the system date is correct, and other devices can use the same network. Don’t change subscriptions or routing yet: the underlying connection is already failing before traffic reaches the proxy. Restore network access first, then restart the client.

Once the basic network is working, open v2rayN, select the configuration you want to test, set it as the active server, and check the log at the bottom of the window or in the log view. Look for startup errors such as a failed configuration parse, a busy listening address, or an exited core—not just the most prominent-looking error. An open interface doesn’t mean the core is running. If it hasn’t started listening, the browser can send requests to the local port but they won’t go any further.

Check the local listening port under “Settings → Parameter Settings.” Some versions put these options under “Core Basic Settings”; names vary by interface. Note the actual value rather than copying a tutorial example. The 10808 used here is only an example. If your client uses a different port, update the test command to match. The system proxy, browser’s manual proxy, and client listener must all use the correct port.

Narrow it down with an explicit proxy test

These Windows commands first check whether a program is listening on the loopback address, then send a request explicitly through a SOCKS proxy. Use the second command only if that port actually provides SOCKS; for a mixed port, confirm SOCKS is supported. The test uses an example domain. For a real retest, choose a known-reachable HTTPS address. Don’t assume the client is broken just because the example site happens to be down.

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/

If the port check fails, revisit core startup and port conflicts. If the port is listening but the request fails, check the core log at the same time and investigate the node connection and DNS resolution. If the explicit proxy request works but the browser doesn’t, at least that proxy path is functional. Next, check browser extensions, system proxy settings, and the app’s own proxy settings instead of reinstalling the client straight away.

Tell a global outage from an app-specific issue

If only one site fails, try another site of the same kind and check which outbound route the logs show. If other sites work, the issue may involve the destination, a routing rule, a certificate, or the account. An HTTP error page is also different from a connection timeout: a clear response status often means the request reached a service. Not every page error means the node is offline.

If only one app fails, check whether it reads the system proxy settings. Some programs use their own network settings, and some traffic uses UDP, so a working browser doesn’t prove every app should work. First check the app’s proxy protocol and port. If you need to route more traffic, learn how TUN mode affects permissions and routing before enabling it. Don’t run several traffic-capture tools at once and hope for the best; it makes the traffic path harder to trace.

02 / Check how the connection is established

Node timeouts: distinguish ports from handshakes

A timeout means a step didn’t finish before the deadline; it doesn’t prove the node configuration is wrong. A client latency test, TCP connection, TLS handshake, and actual web request may use different destinations and methods, so their results aren’t interchangeable. Save the original error and its timestamp, then check in order: local listener → server address resolution → server port → protocol handshake → destination access.

Confirm which configuration the client is actually using

In v2rayN, check that the active server is the entry you just tested. Watch for nodes with the same name, different subscription groups, or old entries that reappeared after an update. A node name is only a label; it doesn’t identify the actual address or protocol. Open the edit window and compare the server address, port, user ID, transport, and TLS settings with the original information from your provider. Don’t fill in parameters based on guesswork.

For TLS configurations, the server address and the server name used during the handshake may differ; the latter is usually the SNI or serverName. With WebSocket, also check the path and Host; with gRPC, verify the service name. Each field has a specific purpose, so don't replace it with a website domain at random. If the subscription imported correctly, keep the original values and first check whether you selected a different entry or an outdated configuration.

The system clock can also affect the handshake. If the log reports that a certificate is not yet valid, has expired, or doesn’t match the name, check the device date, time zone, and automatic time sync first, then verify the server name. Disabling certificate verification is not a routine fix; it can hide a misconfigured address or interference from an intermediary. If the device clock is correct and the certificate error persists, ask the service operator to check the certificate and server configuration.

Test port reachability separately from protocol support

On Windows, use the command below to check a remote TCP port. The address and port are examples; replace them with the values in your configuration. Don’t share a full link that contains account identifiers. A successful result only confirms that a TCP connection can be established—it doesn’t verify authentication, TLS, transport, or proxy egress. A failure may come from a firewall, network path, or a server that isn’t listening, rather than the client interface.

Test-NetConnection -ComputerName example.com -Port 443

If the TCP port can’t be reached, retry on a different known-working network from the same device, then compare with another configuration. Don’t run repeated tests in quick succession; waiting for a timeout takes time. If only one network fails, keep that difference as a clue. If several networks can’t reach the same server port, ask the service operator to check the listener, inbound rules, certificate renewal, and service status.

Use the results to decide where to fix the problem

If the port is reachable but the handshake fails, check the protocol and transport parameters, and confirm that the core supports this configuration. V2Fly and Xray don’t support every field identically. An entry importing successfully doesn’t guarantee the current core can run it. If startup logs explicitly report an unknown field or unsupported feature, choose client settings that match the configuration rather than deleting fields until the errors disappear.

If actual requests fail but the node test passes, check the server’s ability to reach destinations and the client’s routing. A passing node test only confirms that the path covered by that test works. After a fix, retry the original request and check whether the corresponding log shows the expected outbound. For a more detailed walkthrough, see the node timeout troubleshooting checklist. Note the last confirmed working stage so you don’t have to start guessing from scratch.

03 / Separate fetching from parsing

Subscription failures: check the update path first

A subscription update involves at least three steps: fetching the URL, recognizing the response format, and adding entries to the node list. An “update failed” message can refer to any of these steps and doesn’t necessarily mean saved nodes can’t connect. Keep the existing groups; don’t delete all your nodes as a first step. Note whether you used “Update subscription (without proxy)” or an update through the proxy, and save the last subscription-related error in the log.

Check the full URL, but don’t share access credentials

Open the relevant group under “Subscription Group Settings” and check for extra spaces, line breaks, non-ASCII punctuation, or truncated query parameters. Subscription URLs often contain account identifiers, so copy the complete text from a trusted source rather than part of what a browser displays. The example https://example.com/sub used here is not a working subscription and should not be entered in the client expecting it to produce nodes.

If the original URL appeared in a chat, screenshot, or public document, reset its access credentials through the provider before using a new URL. For troubleshooting, note whether the domain resolves, the response status, and a summary of the error; you don’t need to share the full link. Hide query parameters, user IDs, and the full subscription response even when asking for help privately. Node lists may contain other connection details, so hiding the node names alone isn’t enough.

Check whether the account is active and whether the subscription endpoint has changed. An empty list may mean the current group has no available entries, or that the provider hasn’t assigned configurations to the account. That’s different from a client parsing failure. Check the response and entry count in the update log, then ask the provider to verify the account. Don’t guess URL paths or edit access parameters to look for another endpoint.

Test updates both with and without the proxy

If the current node is down and subscription updates depend on it, you can get stuck in a loop: you need a new node to update, but you need an update to get a new node. If the subscription domain is accessible directly on your current network, try “Update subscription (without proxy)” first. If direct access doesn’t work but you have another known-working configuration, try updating through the proxy. Record the results of both attempts rather than just writing “subscription won’t open.”

Opening a subscription URL in a browser can help reveal a sign-in page or website message, but it doesn’t prove the client can update successfully. The browser may use a different proxy, cache, or login session, and the client may receive a different response. If the page asks you to sign in, complete a web check, or authenticate to the network, the response may look successful while containing HTML instead of subscription data the client can parse.

Handle format incompatibilities and changes after updates

Some subscription endpoints return different formats for different clients. A file downloading in a browser doesn’t mean it’s compatible with v2rayN, v2rayNG, or v2flyNG. If the log shows the content was fetched but no nodes were recognized, choose a format for your client in the provider’s subscription options. Don’t change an arbitrary configuration file’s extension or send a full subscription to an unknown converter service; you could expose your connection details.

If the node count changes after an update, first check the filters, selected subscription group, and list sorting to see whether entries are actually missing. Entries with the same name may have different addresses after an update; replacing an old entry isn’t necessarily an error. Keep manually added configurations in a separate group. Before updating, save any local backup you need, but don’t put it in a public shared folder or a folder that automatically uploads screenshots.

04 / Keep test conditions consistent

Slow speeds: separate latency from throughput

Slow page loads, low download speeds, and video buffering aren’t the same performance problem. A web page involves DNS, connection setup, handshakes, and multiple resource requests. Downloads depend more on sustained throughput, while real-time apps are also affected by jitter and packet loss. First specify what feels slow, then choose a comparison test that measures it. A single latency number in the node list can’t tell you which node will be fastest for every task.

Set up a repeatable performance comparison

Keep the device, network, destination, and time of day consistent. Pause background sync, system updates, and other downloads. Check whether direct internet speed is also down, then compare nodes using the same request. Changing the test site and node at once mixes in differences in destination load. One speed change is only a clue; retest under the same conditions before treating it as a pattern.

When using v2rayN’s test features, distinguish a TCP connection test from a real request test. The former mainly measures how quickly a connection is established; the latter involves more of the network path. A blank or timed-out result may also mean the test destination is unreachable, not that every destination has failed. Note the test type and destination, then compare with an actual browser request. Don’t keep changing test settings just to get a better-looking number and lose a fair comparison.

A strong Wi-Fi signal doesn’t guarantee a stable connection. Retest near the router on the same computer, or compare with a wired connection if available. On mobile data, check signal changes, hotspot sharing, and data-plan speed limits. If several devices at home are transferring large amounts of data, congestion at the internet connection can slow every node. Changing clients usually won’t help; first rule out local network contention, then see whether the proxy path is still unusually slow.

Find out when the slowdown occurs

If the first page load is slow but refreshes are much faster, check DNS, connection reuse, and the handshake first. If the download starts fast and gradually slows, look at server bandwidth, destination rate limits, and network congestion. If only one site is slow, compare with a similar destination and check which routing rule matched. Confirm the request isn’t being sent through an unsuitable outbound. Don’t change all traffic to the same routing mode because of one slow site.

Logs can show whether connections are repeatedly re-established or DNS lookups keep failing, but avoid leaving highly verbose logging enabled for long. Heavy disk writes add overhead and retain more browsing records. Capture only a short window around the issue, then restore the usual log level. If sharing logs, include only relevant errors and remove subscription URLs, user IDs, and destinations you don’t need to disclose.

For apps that use UDP, confirm that the protocol combination, client configuration, and server all support the required traffic. A working browser doesn’t prove real-time app traffic takes the same path. Some networks handle UDP differently, so use the app’s own connection status as a reference. Before switching to TUN mode, understand what traffic it captures; it isn’t a bandwidth boost. It changes the traffic entry point, not the capacity of the outbound connection.

Don’t hide performance problems behind risky settings

If large pages partly hang or some connections work while others wait, path MTU may be worth checking later, but don’t start by setting an arbitrarily small value. Rule out DNS issues, protocol incompatibility, and destination problems first. Once you’ve confirmed the issue is tied to a particular network or tunnel mode, make gradual changes following the client’s documentation and record the original value. After each change, retest both working sites and the original destination to make sure you haven’t broken other connections.

Transport, multiplexing, and concurrency settings aren’t better just because their values are higher. More concurrency can increase contention when server resources are limited or the connection is unstable. Incompatible multiplexing settings can also cause problems. Start with the combination provided by your service operator, and test one setting at a time only when you have a clear comparison. If switching to another working node fixes the issue without changing local settings, recording the differences between nodes is more useful than piling on parameters.

05 / Find out which resolver handles the domain

DNS issues: trace the resolution path

DNS translates domain names into addresses needed to connect. In a proxy setup, the operating system, browser, client, and remote server may all be involved in resolution. If you see “server not found” or a domain-related timeout, don’t immediately replace every DNS server with the same public resolver. First determine whether the failed name belongs to the node server or the website you’re visiting, then find out which layer made the query and whether it had a working network path.

Separate the node’s domain from the destination domain

If the client reports that it can’t resolve the server address before connecting to a node, the problem is before the proxy entry point. Sending all DNS queries through a proxy that hasn’t connected yet can create a dependency loop. Use a system tool to look up the node domain and check whether the current network’s resolver is reachable. If needed, follow your provider’s advice on a suitable resolution path. Don’t replace the node’s domain with an arbitrary IP address; certificates and routing may depend on the domain.

If the node is connected but only some destination domains fail, check the DNS errors and outbound selection in the client log. With domain-based routing rules, whether the domain is preserved and when it’s resolved can affect rule matching. A browser’s secure DNS setting may also return a different result from the system resolver. Note the current settings, then change just one thing for comparison; don’t change DNS in the browser, operating system, and client all at once.

The commands below are for Windows and common desktop environments. They show the system’s current resolution path, which may differ from the client’s built-in resolver. Even if a lookup succeeds, verify it with an actual HTTPS request. Opening the resulting IP address isn’t an equivalent test: many sites rely on the domain for certificate validation, virtual hosting, and content delivery.

# Windows PowerShell
Resolve-DnsName example.com

# Systems with nslookup
nslookup example.com

Use a proxy test to identify which side resolves the domain

In a SOCKS test, socks5h sends the destination domain to be resolved by the proxy, while some tools using socks5 resolve it locally first. Different results make the resolution path worth investigating, but that alone doesn’t pinpoint the fault. Check the client’s DNS settings, routing policy, and logs as well to find out where remote resolution requests go and whether they’re mistakenly routed back to the local device.

With encrypted DNS, the resolver itself must also be reachable. If the resolver address is a domain, it may need a bootstrap lookup. If connecting to it depends on the same path that’s already failing, startup can wait indefinitely. Don’t copy a full configuration from an unknown source. First establish which domains it serves, which outbound it uses, and what happens on failure. Then use the format supported by your current core; fields aren’t interchangeable between cores.

Differences in IPv4 and IPv6 reachability can also cause sites to load inconsistently. A domain may return both types of address, while the current network has a working route for only one. Compare which address family the logs actually tried, then test a temporary policy supported by the client. Don’t permanently disable IPv6 across the device based on one failed request; confirm the change addresses the issue and note how to restore the original setting.

Check DNS and routing rules together

Start routing troubleshooting with simple rules. The snippet below uses Xray-style routing; it isn’t a complete, ready-to-run configuration. proxy and direct must match existing outbound tags. It illustrates the difference between domain and IP rules and shouldn’t replace the entire configuration generated by the client. GUI clients usually regenerate their runtime configuration, so make persistent changes through a supported option such as “Routing Settings.”

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

Rules are generally matched in order, so an overly broad rule near the top may prevent more specific rules from matching. Don’t send local network addresses through a remote proxy without a reason; this can break local admin pages and internal services. After fixing DNS, check whether the same destination uses the expected outbound. A successful lookup doesn’t prove routing and connection are working; keep an actual request log to verify the result.

Clear the cache only as a last step. Windows ipconfig /flushdns clears the system DNS cache, but not separate browser, client, or remote caches. Fix the cause first, then close and reopen the relevant apps and test again. If clearing the cache only helps briefly, keep investigating the resolution policy and network changes rather than making repeated cache clearing part of your routine.

06 / Check how app traffic enters

System proxy not working: check what it covers

The system proxy is a set of proxy settings provided by the operating system, not a way to force all network traffic through a proxy. After selecting “Set system proxy automatically” in v2rayN, usually only apps that read those settings will use it. Apps with their own proxy settings, browser extensions, command-line environment variables, and TUN mode can create other entry points. First find out which settings the affected app actually uses, then check that location.

Check the system address and local listener

On Windows, select “Set system proxy automatically” in v2rayN’s “System Proxy” menu, then check the active address and port under “Settings → Network & Internet → Proxy.” Depending on how the client works, the relevant setting may be a manual proxy or a setup script. Don’t rely only on the tray icon color; if another program changed the system settings, the client interface may not immediately reflect everything.

If the address is a loopback address, it must match the port the client is actually listening on. 127.0.0.1 refers to the current device, so local apps can connect to the client on that device; it won’t let a phone use the computer’s proxy. If you changed the port, the system or browser may still have the old value. First confirm the new port with an explicit proxy request, then apply the system proxy settings again instead of repeatedly toggling modes for a port with no listener.

On macOS, select the current network service under “System Settings → Network,” then check its settings under “Details → Proxies.” Names may vary slightly between system versions. Wi-Fi and Ethernet may be separate services, so check the one currently in use after changing networks. Linux desktop environments differ in where system proxy settings live and how apps read them. Some apps only use their own settings, so steps for one desktop may not apply to another.

Check for conflicting proxy settings

If the browser behaves differently from other apps, temporarily disable browser proxy extensions and check for startup arguments or managed policies. Command-line tools may read environment variables such as HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY. A running process may retain old values after you change them, so reopen the terminal or app. Switching the system proxy doesn’t necessarily update these variables.

Don’t run multiple tools that change the system proxy or default route at the same time. They may overwrite one another’s address or send traffic that should go direct through another proxy, creating a loop. Exit other traffic-capture tools first, then test the affected app with one client and one clearly defined entry point. If you need to combine tools, map each listening address and traffic path instead of relying on defaults to connect them automatically.

“Don’t change the system proxy” doesn’t mean “clear the system proxy.” The first option usually leaves the current system settings in place; the second actively removes the proxy entry configured by the client. Closing the window, exiting from the tray, and clearing the proxy aren’t interchangeable. If internet access fails after you exit the client, check whether the system still points to a local port. Restore the normal settings and retest instead of restarting a broken node to keep the basic connection working.

Troubleshoot LAN sharing separately from TUN

To use the computer’s proxy from a phone, enable “Allow connections from the LAN” in the computer’s “Parameter Settings,” check the listening port and the computer’s local network address, then add an inbound firewall rule if needed. Limit the rule to trusted networks and the required port; don’t disable the firewall entirely for troubleshooting. The phone and computer must be able to communicate over the LAN. Guest network isolation or hotspot restrictions can block them.

For TUN issues, check whether the virtual interface, permissions, and routes were created successfully. If the node server itself becomes unreachable after enabling TUN, check for a loop where the outbound connection is captured again. Turn TUN off first and confirm the node works through an explicit local proxy, then enable TUN separately and compare. For more on sharing, see how to allow LAN connections. Retest both the target app and access to local network services.

07 / Separate the interface from the core process

Client crashes: save evidence before fixing

A client that won’t open, a window that closes immediately, and an exited node core are different problems. The first two mainly affect the graphical interface; the last may leave the interface open while all requests fail. Note the operating system, CPU architecture, package type, and whether the problem occurred during startup, import, or connection. Don’t delete the entire user directory right away. It may contain subscription groups, routing rules, and logs that you need to identify the cause.

Check the package and system requirements

Check the platform and architecture on the client downloads page. The v2rayN desktop and classic WPF editions for Windows use different interface implementations; check the selected package’s runtime and system requirements. On macOS, distinguish Apple Silicon from Intel. On Linux, check both the CPU architecture and distribution package format. A successful download doesn’t mean the package suits your device; the wrong architecture can cause an immediate startup exit.

If Windows clearly reports a missing runtime, install the component and architecture specified in the error. Don’t download loose DLLs from unknown sources. Fully extract a portable package before running it; don’t drag only the main program out of the archive. Path permissions, temporary-file cleanup, or security software quarantining files can also prevent a complete startup. Check the specific system message rather than blaming every failure on the OS version.

If macOS says the developer can’t be verified, first confirm the file source and package type, then follow the relevant prompt under “System Settings → Privacy & Security.” Don’t disable system security entirely just to open one app. A damaged file, missing component, or architecture mismatch isn’t necessarily a permissions issue. See macOS first launch and permissions to distinguish a security prompt from an actual program error.

Read the logs instead of restarting repeatedly

If the interface opens, check whether the client and core logs are both available. If a configuration error appears immediately after import, find the first parse failure or unsupported field; many later connection failures may just be consequences. If every connection attempt reports a port conflict, check whether another instance is already running instead of repeatedly changing ports and leaving the system proxy and listener out of sync.

On Windows, use the command below to find the process ID listening on the example port. Look up the process in Task Manager before taking action; don’t end a system process just because you don’t recognize the number. If it’s another instance of the client, exit the extra instance from the tray, then start one clean instance. If another service needs the port, choose an unused port for the client and update any app settings that refer to it.

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

If a Linux desktop app exits as soon as it starts, launch the installed program from a terminal and check for errors related to missing dependencies, the display environment, or permissions. Resolve any package installer errors before testing the app. Copying a single executable may not provide all its dependencies. If the program runs with normal permissions, don’t run it as an administrator long-term for convenience. Handle permissions separately only for network features that actually require them.

Use a minimal configuration to narrow down the cause

If you suspect a damaged user configuration, exit the program and back up the configuration directory using a method supported by the client. Keep the original files untouched. If you need a fresh environment, use a separate user data directory or follow the documented reset procedure; installing to a different folder doesn’t necessarily create an independent configuration. First confirm the interface opens in a clean environment, then add just one known-working configuration. Leave routing, subscriptions, and custom settings out for now.

If the minimal setup works, restore subscriptions, routing, and special network features one at a time, testing after each change. If the crash returns after a particular step, you’ve narrowed it down without discarding all your settings. If two interface editions behave differently, see desktop vs. WPF edition differences and choose the one suited to your system. Switching interfaces isn’t a general fix for node or DNS problems.

08 / Android network and background restrictions

Mobile troubleshooting: permissions and network changes

On Android, v2rayNG is the recommended choice; consider v2flyNG if you need a V2Fly-compatible core. Their interfaces are similar, but their core support and some settings aren’t identical. If a phone connects but can’t access the internet, disconnects when locked, or stops working after a network change, check VPN permission, app routing, and background activity first, then investigate the node and DNS. Don’t mistake mobile OS restrictions for a server problem.

Confirm the VPN service actually started

The first time you connect, Android asks for permission to set up a VPN connection. The client can create the local virtual network interface only after you approve it. A VPN icon in the status bar only means the service is running; it doesn’t confirm that the remote node connected. Check the app log immediately after startup for configuration parsing errors, denied permissions, or a service that stops right away, then test access to a known destination.

Usually, only one app can control the VPN service at a time in the same user environment. Another network tool, work profile policy, or system service may already be using the entry point, causing the new connection to replace the old one or fail to start. Stop other traffic-capture apps and start one client. On a managed device, check whether policy restricts VPN configuration. Don’t try to bypass the device’s authorization requirements by repeatedly installing different clients.

If “Always-on VPN” or “Block connections without VPN” is enabled, Android may block other network access whenever the client isn’t running or can’t connect. Note these options before troubleshooting. If needed, temporarily turn them off to test basic network access, then restore them if required. Stopping the connection in the app may not be enough if the system still requires traffic to use a stopped service.

Check per-app proxy settings and background activity

If only some apps have problems, check whether per-app proxying or an exclusion list is enabled. Confirm whether the current mode means “proxy selected apps only” or “bypass selected apps”; the same app list means the opposite in each mode. Reconnect after making changes and fully close and reopen the target app so it doesn’t keep using an old connection. If work and personal profiles are separate, confirm which profile contains the app you’re testing.

If the connection drops when the screen locks and recovers when it wakes, check system battery optimization, background data, and the manufacturer’s auto-start controls. Review the app’s battery policy and background data permission in system settings, granting what’s needed for a persistent connection without disabling power saving for the entire device. Check whether the VPN icon disappears, the app service restarts, or the log shows a new startup. This helps distinguish the process being stopped from a remote connection timeout.

A foreground service notification helps show whether the client is running, though some systems manage notification display separately. A missing notification doesn’t necessarily mean the core has stopped; check the system VPN status and logs. Conversely, a visible notification doesn’t guarantee the remote connection works. If the connection still drops under the same conditions after restoring background permissions, note the screen-lock duration, power state, and network type, then compare one setting at a time.

Retest DNS and the outbound path after changing networks

When switching from Wi-Fi to mobile data, existing connections may stop working, and DNS, IPv6, or the default route may change. Wait for the new network to come up, disconnect and reconnect the client, then test with a new request. If only one Wi-Fi network fails, check for a sign-in page or device isolation. If mobile data is the only problem, compare node port reachability and resolution results instead of resetting all app data.

To use a proxy shared from a computer, set the computer’s LAN address and its actual HTTP or mixed port in the phone’s Wi-Fi proxy settings. Don’t enter the phone’s own loopback address or use a SOCKS-only port as an HTTP port. This setting usually affects only apps that follow the Wi-Fi proxy. Before testing, confirm the computer is on, the client is listening, and LAN access and firewall rules are configured as described in the system proxy section.

If import succeeds but startup fails, check which core features the configuration requires. v2rayNG and v2flyNG must use configuration formats and feature combinations supported by each client; a node name won’t tell you whether it’s compatible. If you need to reinstall, choose a package by CPU architecture from the Android downloads page. Most newer devices use arm64. If you’re unsure, check the universal package guidance rather than guessing from file size.