V2Ray FAQ: Setup & Troubleshooting

V2Ray is a core project in the Project V proxy ecosystem. V2Fly continues development of a related core, while Xray is a separate core fork. The core handles connections, protocols, DNS, and routing; v2rayN is a graphical client for managing configurations. On desktop, you can use v2rayN. On Android, you can use v2rayNG with the Xray core or v2flyNG with the V2Fly core. Successfully adding a node in the interface only means the configuration was accepted—it does not confirm that the server is reachable. When troubleshooting, first check whether the client started the core, then review the connection logs. Before switching cores, make sure the node's protocol and transport settings are supported; the core name alone says nothing about connection quality.

The client manages local settings and forwards traffic; the installer itself does not include a remote service. A node contains the server address, port, protocol, credentials, and transport settings. A subscription is a link the client uses to periodically retrieve a set of nodes. Get configuration from a service you are authorized to use or from your own server, then import it into the client. Being able to retrieve a subscription does not mean its nodes can connect; check the service's validity, server status, and your current network as well. Do not mistake the local SOCKS address 127.0.0.1 for a remote node, or post subscription links in public screenshots or forums. Links may contain account access tokens and should be treated as sensitive information.

The server configuration determines the protocol; it is not something you can choose freely in the client. When importing a shared link, keep the protocol, port, transport, and security settings provided by the service. A VLESS node may also require a specific flow, REALITY public key, or server name. Trojan is commonly used with TLS, while VMess and Shadowsocks have their own authentication and encryption settings. Simply changing the protocol in a dropdown will usually break the connection, and a protocol name alone does not guarantee better speeds. For your first setup, use a complete link or QR code, then learn what each field does once connected. If you need to migrate protocols, update both the server and client, and confirm that the core supports the chosen combination.

These settings apply at different stages. A system proxy provides applications with a local proxy address; only applications that respect system proxy settings will use it. TUN routes traffic through a virtual network interface and can cover more applications that ignore the system proxy. Global mode describes the routing policy inside the core, usually sending matching traffic through the proxy. It does not automatically capture traffic from every application. Split routing uses rules such as domains or IP addresses to choose whether traffic goes direct, through the proxy, or is blocked. To check whether an app is using the proxy, first confirm that its traffic reaches the client, then check which rule matched. When troubleshooting, test one traffic-entry method at a time so changes to the system proxy, TUN, and routing do not obscure the cause.

The arm64 package is for devices with a 64-bit ARM processor and a system that supports the app; it is usually smaller. The universal package includes multiple supported architectures and is a good choice if you are unsure which one your device uses. Most recent phones can use arm64, but a device's age or processor marketing alone is not conclusive—some devices still run a 32-bit system. If Android says the app can't be installed, first check the OS version, available storage, the existing app's signing key, and installation permissions; then consider an architecture mismatch. Back up subscription groups and custom rules before upgrading so you don't lose settings while resolving an installation conflict. Choose packages for v2rayNG and v2flyNG separately; they are different apps, not interchangeable versions to install over one another.

First, distinguish a subscription URL from a link for a single node. Enter a subscription URL in the address field for a subscription group; import a single-node link through the clipboard or share-link option. In v2rayN, save the group and then run the subscription update. In v2rayNG, add the subscription and update it too—saving the name alone is not enough. Check that the copied URL is complete, remove leading or trailing spaces and line breaks, and make sure you haven't included a website login URL or explanatory text. If the logs report a parsing error, the response may be a login page, an error page, or a configuration format the client doesn't support. Ask the service provider to confirm the format. Renaming the group or repeatedly reinstalling the app won't fix a format issue; first test importing a known-compatible node link.

A subscription update contacts the subscription service, which may be different from the server used by a node connection, so the two can behave differently. Check whether the link has expired, the account is active, and the logs show an HTTP status or timeout. If the subscription URL is only reachable through a proxy, first enable a known-working node, then use the client's option to update through the proxy. If the URL must be accessed directly, choose a direct update. Option names and locations vary by client version. Also check the system clock, DNS resolution, and whether a network sign-in page is interfering. If an update fails, keep the existing group rather than clearing all nodes. If the response stays empty or its format changes, ask the provider to confirm the subscription format.

TUN creates a virtual network interface and changes routes, so it needs more privileges than a regular local proxy. On Windows, follow the client's instructions to run it as an administrator or configure the required service. On Linux, check the permission setup for your version, access to the virtual network device, and service status. On macOS, grant the requested permissions in the system prompts. On Android, approve the system VPN request; typically, only one VPN service can run at a time. Close other tools using a similar interface, then check the client logs for the specific error. Don't assume every permission issue means a node is unavailable, and don't change system file permissions without a clear reason. If you can't grant access yet, test the node with the system proxy first and configure TUN after the regular connection works.

For everyday browsing, start with split routing: send destinations that need a proxy through the proxy, and connect to the rest directly according to the rules. Bypass mainland China is usually a preset that routes domains and IP addresses classified as belonging to mainland China directly, but the exact behavior depends on the client's rule set. Global mode is useful for temporarily testing the proxy exit or for tests that need a single exit; it does not mean every app will automatically send traffic through the client. After switching modes, reconnect to the same destination and, if needed, close and reopen the page or app so an existing long-lived connection doesn't keep using its old route. If global mode works but split routing doesn't, check rule order, classification data, and DNS before switching nodes. Restore your usual policy after testing to avoid routing more traffic through the proxy than necessary.

Many command-line tools don't automatically use the desktop system proxy. Set a proxy address in the tool itself or configure the appropriate environment variables for the process. First, check the client's actual listening address, port, and protocol. If its SOCKS port is 10808, test the listener with `curl -x socks5h://127.0.0.1:10808 -I https://www.example.com`; change the port in the command if yours is different. `socks5h` sends the destination hostname to the proxy for resolution, unlike local DNS resolution. In a container or virtual machine, 127.0.0.1 points to that environment itself, not necessarily the host. Test the connection on the host first, then check network access from the isolated environment. Don't expose the proxy listener to every network just for convenience.

On other devices, enter the LAN IP address of the machine running the client and the corresponding proxy port. Don't use 127.0.0.1, which always points to the device you're currently using. After enabling LAN access in v2rayN, check the core's listening address, the system firewall, and connectivity between devices. Guest Wi-Fi or wireless client isolation may block access. HTTP and SOCKS ports are not interchangeable. Only share the proxy on a trusted network, and restrict firewall access to the devices or subnet that need it; don't expose the listener to the public internet. If a connection fails, first check whether the port is reachable from another device on the same LAN, then check the node status. Turn off sharing and restore the previous listening settings when you no longer need it.

You can update the node list on each device from the same subscription URL, or share individual node links or QR codes. Subscriptions usually distribute nodes only; they don't sync system proxy settings, TUN permissions, local ports, or all routing rules. The same node list therefore doesn't guarantee the same traffic route. Start by using the same subscription source and update schedule, then check the active node, routing mode, DNS, and custom rules on each device. Desktop and Android clients differ in their interfaces and supported features, so don't swap complete configuration files without checking format compatibility. QR codes and backup files may contain credentials; don't save them in a public photo album or group chat. Test the connection again after switching devices instead of assuming the settings match because the node names do.

Not necessarily. A TCP connection test, a real request, and an app access check test different things. The test destination itself may also be unreachable and cause a timeout. First check that the core started correctly, then verify the node address, port, system time, and transport settings. An incorrect TLS server name, REALITY public key, or flow can cause the handshake to fail. Compare the result with a known-working node using the same test destination, then try another working network to distinguish a server issue from a local network issue. A single test result doesn't guarantee ongoing availability, and increasing the timeout alone can hide a configuration error. If several nodes fail at once, check the local network and client logs first. If only one node fails, contact the provider.

“Connected” may only mean the core or VPN interface has started; it doesn't mean every request will succeed. First, confirm that the device can access the network and complete any required sign-in. Then check the system clock, active node, and client logs. Next, verify the local listening port and the app's proxy settings. Make a request with the proxy explicitly specified to check whether traffic can pass through that listener. If it works but the browser doesn't, check the browser's proxy extensions and system settings. If requests reach the core but still fail, temporarily compare global and split routing to pinpoint a routing or DNS issue. With TUN, also check the virtual interface and routes. Change one setting at a time and record the result. Switching nodes, changing DNS, and resetting all rules at once makes it hard to identify what fixed the problem.

First, make sure the proxy address configured in the client matches the system network settings and that the port is actually listening. Linux desktop environments vary in their system proxy support, and some apps use only their own settings or environment variables. Browser extensions can also override the system proxy. Test the listener with a tool that supports an explicit proxy. If it connects, focus on how the app accesses the proxy rather than reinstalling the core. Also distinguish traffic that never reaches the client from traffic that reaches it but is routed directly; request logs can help. Consider TUN only if you need to capture apps that ignore the system proxy. If the network stops working after you exit the client, restore the system proxy settings. Apps will also fail if the listener has stopped but the system still points to its port.

Record the failing domain and the log error first, then distinguish DNS resolution failures from connection timeouts and certificate errors. Compare global and split routing. If only split routing fails, check whether an earlier custom rule sends the destination through the wrong route and whether the geosite and geoip data match the rules. DNS settings should work with the traffic route. Check resolution for both the node server address and the destination; browser Secure DNS may also use a separate resolver. After changing a setting, reconnect and, if needed, clear the app cache before testing the same domain again. Don't routinely replace a TLS-enabled domain with its IP address; this can affect the server name and certificate validation. If logs mention IPv6, check IPv6 connectivity too. Avoid changing several DNS settings at once without evidence.