V2Ray FAQ

V2Ray is part of the Project V proxy ecosystem. The core handles protocols, inbound listeners and routing; the client provides a graphical interface for saving servers, updating subscriptions and launching the core. v2rayN is a desktop client, while v2rayNG and v2flyNG are for Android. When troubleshooting, first determine whether the problem is with the interface or the core connection: if the subscription list is empty, check the import; if servers are listed but connections fail, check the core logs. Reinstalling the client should not be the first step for every problem.

For desktop systems, start with v2rayN. On Android, v2rayNG with the Xray core is usually the go-to option; consider v2flyNG if you need V2Fly core behavior or already have a compatible configuration. REALITY and XTLS Vision are Xray features, so don't assume support based on a similar client name alone. Check the server's required protocol, security layer and transport, then verify that the client's core supports them. The two Android clients store settings separately, so switching apps usually means importing the subscription again.

A client is a connection tool; its installer does not include a ready-to-use remote server. To connect, you need legitimate server details: an address, port and authentication credentials, plus protocol and transport settings that match the server. A subscription is an address for distributing these configurations in bulk, not a client account. After getting a subscription, import it and update the server list, then select an active server. Switching system proxy or TUN settings repeatedly won't supply missing server details or establish a connection when no servers are configured.

VMess, VLESS and Trojan are proxy protocols. REALITY is a secure transport mechanism provided by Xray, so these are not four mutually exclusive protocol options. A server configuration may also include a transport such as TCP, WebSocket or gRPC, along with fields like TLS and SNI. After importing, check the complete configuration against the server details, especially the port, path, service name and security parameters. Don't swap protocols at random while troubleshooting; mismatched client and server settings commonly cause handshake failures.

Most newer Android phones can start with arm64, but a device's age alone isn't enough to determine compatibility. Check the app architecture supported by your device in system information or the manufacturer's specifications. If you can't confirm the architecture, the universal package supports a wider range of devices, though it's usually larger. If installation reports incompatibility, check the Android version and app architecture. If you see a signature conflict, back up your settings and verify the source of the existing app; don't uninstall it blindly and risk losing subscriptions and routing settings.

First identify what you have: a subscription URL, a single share link or a full JSON configuration. Each uses a different import option. Enter a subscription URL in the subscription group, save it and run an update; import a share link from the clipboard; use the custom configuration option for a full config. Check for spaces, line breaks or extra text added by a chat app. If the list is still empty, check the update message: for authentication errors, verify that the subscription is still valid; for format errors, check whether the response is actually a login page. Don't submit subscription URLs to unfamiliar online parsers.

Not necessarily. A full JSON file describes a core configuration and may include inbounds, routing and multiple outbounds. A typical subscription contains a client-readable list of servers or Base64-encoded share links. A URL that downloads JSON isn't necessarily in a format supported by the subscription import option. Check the provider's instructions, then use custom configuration or the import option for the appropriate format. Custom configs may also define listening ports and routing; check for local port conflicts first and save your existing configuration so you can restore it.

First confirm the server works in regular proxy mode, then troubleshoot TUN separately to avoid dealing with two problems at once. Creating a virtual network interface and setting routes on desktop systems usually requires administrator or other appropriate system permissions. Follow the client's authorization prompt and check that the virtual interface component installed correctly. Android uses the system VPN permission prompt; approve the connection request, and check whether another VPN service on the device is conflicting. If logs report a permission or interface creation failure, close conflicting services and try again. Don't work around the issue by permanently disabling system security protections.

Keep the existing servers for now. Subscription updates contact the configuration distribution address, while server connections contact the proxy server; either path can work while the other fails. Check whether the subscription has expired or its URL has changed, then try direct updates and updates through the proxy using the client's options. Updating through the proxy requires an active, working server. For timeouts, check your current network; for authentication errors, verify your subscription access. Repeatedly clearing the list can erase usable configurations. Back up first and note the exact error instead of retrying rapidly.

System proxy directs apps that follow system settings to a local proxy port. Global routing generally sends traffic that reaches the core through the proxy outbound, but doesn't guarantee that every app's traffic reaches the core. TUN uses a virtual network interface to capture eligible traffic. These work at different layers and can be combined, but they aren't interchangeable. If a browser works but an app doesn't, first check whether the app follows the system proxy; then consider its in-app proxy settings or TUN. There's no need to switch every routing rule to global proxy mode.

Use TCPing first to see whether the server port accepts a TCP connection, then run a real-connection test to check the proxy handshake and access to the target, and finally verify the exit IP in the app you actually use. A successful TCPing only shows that the port is reachable; it doesn't confirm authentication, TLS or routing. Real-connection tests also depend on the test site and your current network. Use a trusted IP lookup page and confirm the request is routed through the proxy as expected. A single latency reading isn't throughput. When choosing a server, check sustained stability rather than sorting only by the lowest number.

Note the client name, operating system, core, time of the issue, proxy mode and full error message, then reproduce the problem with the fewest steps possible. Keep a short section of logs from just before and after the issue to help distinguish parsing errors, connection timeouts and authentication failures. Before sharing screenshots or configurations, hide subscription URLs, user identifiers, passwords and QR codes that could reveal access credentials. If you need to show the configuration structure, replace sensitive values with examples while retaining field names and error context. Raise the log level only temporarily, then restore the original setting.

Turn off the proxy first and confirm that your local network can access the internet, then check that the server address and port are complete. Compare TCPing with the real-connection test: if the port itself times out, investigate the network path, server status and firewall; if the port is reachable but the real-connection test fails, check the protocol, authentication, security layer and transport settings. You can compare results on another trusted network, but change one variable at a time. If all servers fail, check the local network or shared client settings first. If only one fails, focus on that server's configuration and status.

“Connected” may only mean that the core started or a virtual interface was created; it doesn't prove that the target site is reachable. Confirm that an active server is selected, then check that the local inbound listener is running, the browser is using the correct proxy port, and routing sends requests to the intended outbound. If the logs show a DNS resolution failure, check that the DNS server is reachable and avoid a loop where DNS requests depend on a proxy connection that isn't established yet. If only certain sites fail, check their routing rules and the target service status. Don't change the server, DNS and routing all at once.

Check the operating system's proxy settings first and confirm they point to the local address and port the client is actually listening on, not a stale port. Check whether browser extensions, in-app proxy settings or an automatic configuration script are overriding system settings. Some apps don't use the system proxy and need to be configured separately. If access still fails after quitting the client, clear any leftover system proxy settings and test the direct connection. On restart, use only one proxy tool and restore settings one at a time. Don't enter a local listening address as the remote server address; they serve different purposes.

Skipping certificate verification isn't recommended as a long-term fix. First sync your system date, time and time zone. Then check that SNI matches the server's requirements and that the certificate covers the domain and hasn't expired. The server address and SNI can differ, but both must match the server configuration; don't change them at random. With REALITY, also check the public key, short ID and fingerprint. If you've recently changed server settings, reimport details from a trusted source. If the problem persists, keep the original error and ask the configuration provider to check the server status.