V2Ray Troubleshooting Guide

No Internet Access: Find Where the Connection Breaks

Compare Direct and Proxied Connections

“No internet access” is not specific enough to pinpoint the problem. First determine whether all apps fail, only the browser fails, or just one website is affected. Quit the proxy client, restore the system's original proxy settings, and try a website that normally works without a proxy. If it still fails, check your network connection, Wi-Fi, gateway, and any required captive portal login. Changing nodes repeatedly won't help if the underlying network is down.

Once direct access works, start the client and select a node you're authorized to use. Use v2rayN on desktop and v2rayNG on Android; consider v2flyNG if you specifically need a V2Fly configuration. Don't run multiple tools that route system traffic at the same time. Turn off TUN and complex routing first. Test the basic proxy path in a browser known to support the system proxy to narrow down the cause.

Check Each Stage of the Request Path

A request typically passes through the app's proxy settings, a local listening port, routing rules, the node connection, and the destination service. An open client window only means the management app is running; selecting a node doesn't prove the core has started. Check the client logs for a successful startup and the listening address and port, then look for a matching request when you visit a site. If no request appears, first check whether the app is sending traffic to the client at all.

If the logs report that a local port could not be bound, check whether another client instance or program is using it. If you change the listening port, update the app's proxy port to match. Don't enter the local inbound port as the remote node port. The inbound port receives requests from apps on your device; the remote port connects to the server. They serve different purposes, even if their numbers happen to match.

Narrow down the cause with one-variable tests

Keep the same node and temporarily set the client to route traffic explicitly through the proxy. Then visit the same destination. If it works, the routing rules are the likely cause. If it still fails, try a known-working node without changing anything else. Record each change and its result so you don't end up wondering which of several changes fixed the issue. Restore the original mode when testing is complete; don't leave full-tunnel proxying enabled as a temporary workaround.

If only one site fails, check its service status and compare it with other sites that work. The main page may load while images or sign-in fail because related domains use a different route, or the destination service may reject the current exit IP. Check the failed request's domain and route before deciding the entire node is down.

A fix is reliable when you can reproduce it: access fails with the client off and works after starting it with the expected settings, with the logs showing the correct destination and outbound route. Save this minimal working configuration, then enable routing rules, TUN, or app-specific settings one at a time. For connection checks, see the first connection and real-world speed test guide.

Node Timeouts: Check the Port, Handshake, and Protocol

Find Where the Timeout Occurs

A node timeout can occur during DNS lookup, transport connection, TLS handshake, or protocol authentication. Find the first relevant error in the logs rather than relying on a generic connection failure at the end. Record the target host, port, error type, and time. Comparing the same node across different networks is often more useful than a single speed test. Keep the node settings and client mode consistent during testing.

TCPing shows whether a port can be reached; it doesn't verify the full proxy protocol, authentication, or access to a destination website. A reachable port with failed requests may point to a mismatched user ID, incorrect transport path, or inconsistent TLS settings. Conversely, a failed test doesn't necessarily mean all real traffic will fail. Use port checks alongside real connection tests in the client; they measure different things.

Verify the Remote Address and Transport Settings

First check that the node address has no extra spaces and that its port is valid and matches the server details. Then verify the protocol, user ID, password, transport type, and any additional fields. WebSocket paths and Host values, as well as gRPC service names, must match exactly. Even a small difference in a slash or letter case can send a request to the wrong service. Don't guess missing fields based on how other nodes are configured.

If the address is a domain name, confirm that it currently resolves. Temporarily testing an address confirmed by the provider can help with diagnosis, but don't casually change settings that rely on domain validation. The connection address, TLS serverName, and HTTP Host have different roles: where to connect, which service identity to verify, and which application-layer hostname to send. They don't have to be the same.

Troubleshoot TLS and REALITY Errors

A warning that a certificate is not yet valid or has expired may be caused by an incorrect device clock—or by an actual server certificate problem. Sync the system date, time zone, and time first, then check that the SNI matches the server requirements. Don't treat disabling certificate verification as a routine fix. It can hide an incorrect domain, a missing certificate chain, or a connection to the wrong host. Even if access starts working, that doesn't prove the configuration is correct.

For REALITY connections, also verify the server public key, shortId, serverName, fingerprint, and any flow required by the provider. Supported fields depend on the selected core and client implementation; a term in the node name doesn't guarantee compatibility. If you see an unknown-field or unsupported-protocol error, check the core type and configuration source first. See Xray vs. V2Fly core differences.

Compare Networks and Check the Server

Test the same device on a trusted Wi-Fi network and a mobile network. If it fails on only one, check network authentication, access policies, IP address family, and carrier routing. If it fails on every network while other nodes work, focus on that node. Pause other downloads during testing so local congestion doesn't slow the handshake. Don't keep increasing the timeout; it can mask an unreachable destination.

If you administer the server, check that the service listens on the correct address, that host firewall and upstream security rules allow the port, and that the server logs show activity at the same time. Without server access, send the provider the redacted time, failure stage, and network used. Never share a complete node link publicly. If timeouts happen only occasionally during reconnection and the connection then remains stable, check wake-from-sleep and network switching before reinstalling the client.

After making changes, try a few short requests to the same destination and confirm that the handshake works consistently, then restore normal routing. For certificate issues, see TLS certificate and SNI troubleshooting. If the port is reachable but authentication still fails, recheck the parameters instead of repeatedly changing system proxy settings.

Subscription Errors: Check Retrieval, Format, and Parsing

Break an Update into Three Stages

A subscription update has three stages: fetching the URL, identifying the content format, and adding nodes to the client. When an update fails, determine whether the error is a network problem, an unexpected HTTP status, or a parsing error. Existing nodes may still work even when the subscription URL can't be fetched; a successful update doesn't mean every new node will connect. Test these two paths separately rather than treating one result as proof of the other.

Check the complete URL in the client's subscription group. Look for missing query parameters, line breaks, or explanatory text accidentally copied along with it. The access credentials in a URL are sensitive; don't include them in public screenshots or online conversion tools. Don't alter the URL encoding for readability—percent-encoded characters and separators may be significant to the server. Save a copy of the original, then paste the complete URL provided by the service.

Check Which Route the Update Request Uses

Some clients let subscription updates use a direct connection or the current proxy. If the subscription service isn't reachable directly, try updating through a working node. But if the current node is already down, relying on it to fetch a subscription can create a loop. Check the update settings instead of just switching the browser proxy. If no node works, use a working network to retrieve a valid configuration from the provider; avoid untrusted conversion services.

A timeout usually points to the connection path or DNS. A refused connection may mean the server port is closed, while an authentication-related status calls for checking subscription access. If requests are rate-limited, wait as directed by the provider instead of clicking Update repeatedly. For a server error, note the time and status and try again later. Deleting and recreating the group won't fix a remote service problem and may remove nodes that still work.

Check the Returned Content, Not Just the File Extension

A subscription may contain a set of encoded share links or another structure supported by the client. A native JSON configuration, a single share link, and a subscription URL are different kinds of input and belong in different import options. A login page, expiry notice, or error page returned by the server is not node data, even if the HTTP status looks normal. If parsing fails, check the content type; the URL's extension alone isn't enough to identify the format.

The client must support the protocol and transport parameters in each share link. Some importers recognize basic node details but ignore extra parameters, resulting in a node that imports successfully but can't connect. Compare the imported node's edit screen with the original parameters, especially TLS, security, transport type, and protocol-specific fields. For format differences and conversion limits, see subscription formats and share link conversion.

Check the List After an Update

Clear search and filters from the node list, then select the subscription group you just updated. Some clients retain the old active server or list selection, hiding new nodes that are actually there. If the server returned an empty list, check subscription access, plan status, and the provider's node filters instead of importing repeatedly. Creating multiple groups for the same URL won't make it more reliable and makes node sources harder to track.

Keep a working old node or back up the configuration before cleaning up subscriptions. Automatic updates may overwrite manual changes to subscription nodes. For lasting changes, use a separate configuration or group policy supported by the client rather than relying on temporary edits. After recovery, test a new node's connection and confirm the next update can still retrieve content. For common import questions, see the FAQ.

Slow Speeds: Separate Latency, Throughput, and App Delays

Pinpoint What Is Slow

A long wait before a page appears, a consistently slow download, and occasional video buffering are different symptoms. Page startup may involve DNS, connection setup, or the handshake; downloads depend more on bandwidth, packet loss, and destination server load. Record when it happens, which network and node you use, and what type of destination is affected. A single short-connection latency reading doesn't predict download speed, and browser wait time isn't necessarily all proxy latency.

Choose the same trusted destination and compare direct and proxied access at around the same time. Pick a test that reflects your actual use; don't compare a cached static page with a large file download. Pause background sync, system updates, and heavy traffic on other devices, then compare results. Weak Wi-Fi or a saturated local upload can queue requests and slow responses even when the node itself is working normally.

Run Repeatable Node Comparisons

Keep the network and destination the same while switching nodes; then keep the node the same and switch networks. This helps distinguish a node route issue from a local access problem. A real connection test is closer to a complete request, but results still depend on the test destination, server load, and timing. Don't run high-concurrency tests on every node; they can use up bandwidth, trigger server-side limits, and make results hard to compare.

A node's geographic label doesn't tell you the actual end-to-end route. A nearby location doesn't guarantee less congestion, and lower latency doesn't guarantee higher throughput. If only one service is slow, the route from the exit to that service, content delivery choices, or rate limits may be involved. Comparing another exit is more useful than repeatedly changing the local listening port, but first check whether the service itself is having problems.

Check for Overlapping Traffic Capture and Incorrect Routing

Check whether the system proxy, TUN, browser proxy extensions, and other network tools are active at the same time. Overlapping traffic capture can send connections on a detour or route the client's own outbound traffic back through its inbound. Temporarily test with just one path enabled. If disabling one layer fixes the issue, review that layer's exclusions and routing rather than relying on unexplained performance toggles.

Incorrect routing can also make some content seem slow. For example, sending the main page directly while proxying its resource domains can add extra connections. Sending a site that should use the proxy over an unsuitable direct route can cause repeated timeouts. Use the logs to check the actual outbound route, then adjust the specific rule. Rules are generally evaluated in order, so a broad rule near the top can override more specific ones. See V2Ray routing and split tunneling in practice.

Protocol Settings and Device Resource Limits

Multiplexing, concurrent connections, and other advanced options aren't universal speed boosters. Their effects vary by network, destination, and server settings; mismatched options can reset connections. Restore the provider's basic settings first, confirm they work reliably, then test one option at a time. Don't disable authentication or security to shorten a test—those changes don't address throughput.

Check device resources too. Low power mode, sustained high temperatures, a busy CPU, low disk space, or continuously writing verbose logs can all affect client responsiveness. If the interface lags but downloads are already at normal speeds, the management UI or local device may be the issue rather than remote bandwidth. Turn off unnecessary live updates and long-running debug logs, then repeat the same test.

If large downloads stall only in TUN mode while small requests work, path MTU or encapsulation may be involved, but rule out DNS and routing first. Test on a small scale only if the client provides the relevant setting and you know how to undo it; don't copy network parameters at random. Consider the issue resolved when real tasks complete consistently without repeated connection resets. Record test conditions so a one-off peak doesn't become your long-term performance benchmark.

DNS Issues: Check the Resolver and Request Path

Distinguish the Node Domain from the Destination Domain

DNS can involve two different domains: the client first has to resolve the node server, and a proxied request may also need to resolve the destination website. If the node's domain can't be resolved, the connection fails before reaching the remote protocol. If the destination domain has a resolution problem, the node may connect while some websites remain inaccessible. Check the logs to identify which domain failed before replacing all DNS settings.

Also determine which resolver handles the lookup. An app may use the system resolver or its own encrypted DNS; the proxy core can have separate DNS settings too. With SOCKS, the app may resolve the domain locally or pass it to the proxy for resolution. A successful system lookup proves only that particular query path works—it doesn't prove the browser or core uses the same path.

Check the System Resolver's Results

In a Windows, macOS, or Linux terminal, the command below checks how the system's default resolver responds for an example domain. If the tool isn't available, use the network diagnostics provided by your operating system; there's no need to install unfamiliar software. A successful command only means it returned a result. Check whether the response contains an IPv4 address, an IPv6 address, a clear non-existent-domain result, or a timeout.

nslookup example.com

When investigating an actual problem, query the destination domain shown in the logs; the example domain is only there to demonstrate the syntax. Compare the result with the proxy client logs. If the system lookup works but the core's lookup fails, check the core DNS address and outbound route. If the system query times out too, check the local network, router, or selected resolver. Don't mistake a certificate error for a DNS failure; they occur at different stages.

Identify Resolution Loops and Address-Family Issues

A startup loop can occur if reaching a DNS service requires the proxy while the proxy node's domain also depends on that DNS service. Keep an accessible bootstrap resolution path for the node domain, and ensure DNS requests aren't incorrectly routed back into the client. With encrypted DNS, distinguish resolving the service's own domain from sending subsequent requests; entering one address doesn't resolve every dependency.

The following snippet shows the basic structure of built-in V2Ray DNS and an IPv4-only lookup for diagnosis; it isn't a complete proxy configuration. It depends on the current network being able to reach the listed resolvers. Check DNS fields and routing support for each core. In a graphical client, change the corresponding settings where possible rather than editing a runtime file that the client may regenerate.

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIPv4"
  }
}

Temporarily restrict the address family only when the IPv6 path is clearly suspect. If that resolves the issue, investigate IPv6 reachability, routing, and client settings instead of treating IPv6 as something to disable on every device. When a domain returns multiple addresses, apps may choose different ones, so results can vary even on the same device.

Check Caches and Browser-Specific Settings

After changing DNS, an old cache may keep sending tests to the previous address. Close and reopen the test app, clear the resolver cache using your operating system's supported method, and try again. Browser Secure DNS, app-level caches, and the system cache don't always clear together. Note which layer you cleared so repeated refreshes aren't mistaken for tests using the new result.

Finally, match the destination domain, lookup method, returned address family, and actual outbound route. If only one domain fails, check for a hosts override or a dedicated routing rule. If all domains fail but established connections still transfer data, DNS is more likely to be the problem. After recovery, re-enable any necessary browser settings and confirm that the node starts and the first request works independently, without relying on a cached result.

System Proxy Not Working: Check the App and Local Inbound

Know What the System Proxy Covers

A system proxy usually provides a proxy address to apps that support the setting; it doesn't automatically reroute every connection on the device. If the browser works but an app connects directly, that app may not read the system proxy. Command-line tools, background services, some games, and apps with their own networking stack may require separate proxy settings. Check which proxy options the app supports before choosing the system proxy, an in-app proxy, or TUN.

In v2rayN, system proxy status and routing mode are different things. The system proxy directs apps to a local port; the routing mode determines which outbound route the core uses for incoming requests. Selecting a routing mode doesn't configure proxy settings for every app, and enabling the system proxy doesn't guarantee that a request uses the proxy outbound. Check both layers instead of relying on one label in the tray menu.

Check the Listening Address, Port, and Protocol

First check the actual listening address and port in the client settings and startup logs. A loopback address is usually appropriate for local use only. The app's HTTP proxy port must point to an inbound that supports HTTP; a SOCKS entry requires SOCKS support. Whether a mixed port works depends on the client and core settings—don't assume it's available based on port numbers in another guide.

The snippet below illustrates two separate inbounds. It isn't a node configuration and includes no remote outbound; the ports are examples, so use the values set on your device. Apps should use the corresponding port for their proxy protocol. If the client already generates its own listening configuration, don't append this snippet directly; duplicate bindings can prevent the core from starting.

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

Check Whether Platform Settings Were Overridden

On Windows, check the current user's proxy settings and distinguish a manual proxy from an automatic configuration script. Some apps use different networking settings, so a working browser doesn't mean background services use the same proxy. If the client has quit but the system still points to its now-unused local port, direct access may work while apps that retain the setting report connection failures.

On macOS, proxy settings are tied to the current network service. After switching Wi-Fi, using a wired connection, or adding a network service, check the service actually in use rather than a previously edited one. Linux desktop proxy settings may not cover terminals and system services either. If an app reads environment variables, check whether an older process retained the values it started with. Restarting the test app after a change is more reliable.

Rule Out Proxy Extensions and Bypass Rules

Browser proxy extensions, automatic configuration scripts, in-app proxies, and system settings can override each other. Temporarily disable extra proxy sources and test with just one entry point. If no core log appears, check the app's bypass list—the destination may be explicitly set to connect directly. If a request appears but uses the wrong outbound, investigate the routing rules instead of repeatedly toggling the system proxy.

TUN can capture more types of traffic, but it requires system permissions, a virtual network interface, and correct routing. Don't use it as a blind workaround when the system proxy fails for an unknown reason. Verify the regular inbound path first, then enable TUN separately. Recovery means the target app generates the expected request logs, uses the correct outbound, and system network settings are restored as expected when the client exits. For other modes, see the connection steps in the user guide.

Client Crashes: Separate the UI, Core, and Configuration

Identify Which Process Exited

A vanished window, an unresponsive interface, and a stopped core are different issues. If the window closes but the tray icon remains, the app may just be minimized to the tray. If the management UI works but all connections stop, the core may have failed to start. If the entire program exits, check system error reports and client logs. Note what you were doing—starting the app, switching nodes, updating a subscription, or resuming from sleep—to narrow down the trigger.

Don't delete the configuration directory as your first step. Quit the app, confirm its processes have ended, and back up its configuration, subscription groups, and essential user settings. Logs can be kept, but redact them before sharing. If the app won't open, use your operating system's file manager and diagnostic tools to check recently changed files and application error reports. Don't download so-called repair scripts from unknown sources.

Check the Operating System, Architecture, and Install Method

Before reinstalling, make sure the installer matches your operating system and processor architecture. The desktop and classic WPF editions of v2rayN use different UI implementations; check the requirements for the specific installer. Missing runtimes, an outdated operating system, or an architecture mismatch can cause the app to exit before the main window appears. See client installers for download options by platform. Don't guess compatibility based on part of a filename.

Check that the installation directory is writable, the user directory has enough free space, and the app isn't in a restricted network location or temporary folder. If the app can't write its configuration, settings may disappear, updates may fail, or it may keep exiting. Move it to a suitable local location for its installation method and test again. Don't run it with elevated privileges all the time just to hide a permissions problem.

Find the First Startup Error

Core logs often give specific errors for occupied ports, invalid configuration syntax, unreadable resource files, or unsupported fields. Fix the first meaningful error; later connection failures may just be consequences. Check whether two clients are running or an old process still holds the listening port. Closing duplicate instances and restarting is easier to verify than changing a whole set of network settings at random.

If a manual configuration edit caused the problem, first undo the most recent change. JSON commas, quotation marks, arrays, and object braces must follow the syntax. Valid syntax doesn't guarantee the current core supports every field. Graphical clients often regenerate runtime files, so direct edits to generated files may be overwritten on the next start. Use a configuration entry point explicitly supported by the client for lasting customizations.

Reproduce the Issue with an Isolated Configuration

If you have a backup and know where the client stores its data, start the app with a separate test data directory or rename the original data directory to use fresh settings. Don't run the test instance and original instance at the same time. If a clean setup works, restore one subscription, one node, and only the necessary settings at a time. If the issue returns after restoring an item, you've narrowed it down to that data or feature.

If the app still crashes with an empty configuration, check operating system compatibility, runtimes, installation files, and security software event logs. If something was blocked, review the event details and confirm the source rather than disabling all protection. If the crash happens only when TUN is enabled, check permissions and the virtual interface. If ordinary proxy mode works, you don't need to erase and rebuild all node data.

For hangs after sleep or crashes after extended use, also check memory, handles, disk space, and network transitions. Reduce automatic speed tests, frequent refreshes, or scheduled updates to see if a particular task triggers the issue. After recovery, verify startup, import, connection, and normal exit before restoring automated tasks. When reporting the problem, include the client name, system architecture, reproduction steps, and redacted errors—not just “it won't open.” Don't upload the complete configuration database.

Android Troubleshooting: VPN Permission, Background Activity, and App Routing

Distinguish Local VPN Capture from the Remote Connection

v2rayNG and v2flyNG can capture app traffic through Android's VPN service. A VPN icon means the local traffic-capture service is active; it doesn't prove the remote node has completed its handshake. Check client logs and try a real request before identifying the failing layer. On first launch, the client needs system authorization. If you deny it or another service takes over, the client can't capture traffic as expected.

Normally, only one VPN service can be active for a user at a time. Another VPN, security tool, or app using the same interface may take over the connection. Stop other traffic-capture services, then restart the client you're testing. Always-on VPN and blocking connections outside the VPN can also leave the device offline when the client isn't running. Note the original settings before changing them and restore them after testing as needed.

Choose the Right Installer and Core

Choose an arm64 or universal package that matches the device architecture. Most newer phones use arm64, but purchase year alone isn't a reliable way to tell. Check system or device information, or use the universal package if available. Installation failures can also result from low storage, app-install permissions, or a signing mismatch with an existing app; not every installation error is a network problem.

On Android, v2rayNG with the Xray core is the usual choice; use v2flyNG if you need compatibility with V2Fly configurations. They aren't the same app with different interfaces: protocol features and supported fields depend on the core. Before using nodes with features such as REALITY, confirm that the client supports them. See Android client downloads. Back up essential settings before switching; don't assume app data can be transferred directly.

Fix Disconnects After Screen Lock and Background Termination

If the client works in the foreground but stops after the screen has been locked, check battery optimization, background activity, and background data restrictions first. Setting names vary by device. Find the client in system app settings, allow the background activity it needs, and use the device's option to exempt it from aggressive power saving. Don't disable battery restrictions for every app—make the smallest change needed for the client that must stay connected.

Also distinguish a killed process from an idle connection that has gone stale. If the client notification or VPN icon disappears, the process may have been stopped. If the connection still appears active but the first request needs to reconnect, the idle connection may have expired. Check logs before and after recovery to decide whether to adjust background policies or the node connection. If access returns as soon as the screen turns on, the system may simply have allowed network access again; that alone doesn't prove the server disconnected you.

Check Per-App Proxying and Network Changes

If only some apps can't connect, check the per-app proxy include or exclude mode. These modes mean opposite things: selecting apps may mean proxy only those apps or bypass them. After an app is installed or reinstalled, the list may also need updating. Start with one known test app, confirm its request appears in the logs, then restore the full list gradually.

When switching from Wi-Fi to mobile data, existing connections may fail because the device's address has changed. Stop and restart the connection, then see if it recovers. If every network switch causes a failure, check how the client handles network changes and review background restrictions. Also check data saver, mobile data permission, and the current access point. If only one Wi-Fi network fails, complete its captive portal login before blaming the node or DNS.

VPN traffic capture on a phone doesn't necessarily cover traffic from other devices using its hotspot. A working phone browser doesn't prove hotspot devices use the same route. Don't expose a local listening port or expand access to fix a hotspot issue. After recovery, test foreground access, access after screen lock, switching between Wi-Fi and mobile data, and direct access after disconnecting. If problems persist, use the relevant node, DNS, or subscription section on this page. To repeat the basic setup, return to the user guide and check the import and connection steps again.