V2Ray FAQs and Troubleshooting

The V2Ray core handles protocol processing, routing decisions, and connection forwarding. A graphical client manages subscriptions, accepts settings, switches the system proxy, and displays logs. v2rayN is a desktop graphical client, while v2rayNG and v2flyNG are for Android. In most cases, you only need to install the graphical client; it bundles the required core according to its distribution method, so the core and user interface do not need to be configured separately.

For Windows, macOS, and Linux desktops, v2rayN is usually the best choice, with complete controls for subscriptions, routing, the system proxy, and TUN. On Android, v2rayNG, which uses the Xray core, is the usual starting point. If your subscription parameters work better with the v2fly core, or you need to compare compatibility between cores, try v2flyNG instead. Do not enable VPN or system-proxy takeover in both clients on the same device.

A subscription link provides a set of nodes centrally managed by the service. When the client refreshes the subscription, it synchronizes added, removed, and changed node parameters. A single-node configuration contains connection details imported once and does not automatically follow later server-side changes. For long-term use, save the subscription in its own group and set a sensible refresh interval. To test one configuration temporarily, import it as a standalone node so the existing subscription group is not overwritten.

System proxy mode changes the operating system's proxy settings. Browsers and applications that follow the system proxy connect through the client, but some games, command-line tools, and applications that manage networking themselves may ignore those settings. TUN mode takes over traffic at a lower level through a virtual network interface, giving it broader coverage but requiring additional permissions. Start with system proxy mode to verify the configuration, and enable TUN only when an application cannot be handled by the proxy.

Most mainstream Android phones and tablets released after 2015 use 64-bit ARM processors, so you can start with the arm64 version, which is usually smaller. If you cannot confirm the architecture, the device is older, or arm64 reports an incompatibility during installation, use the universal version instead. The two packages offer essentially the same features; the difference is the range of processor architectures they include. There is no need to install both.

View Android client packages

First, make sure the copied content is the complete subscription URL, with no extra spaces, line breaks, or punctuation added by a messaging app. In v2rayN, open the subscription group settings, add the URL, save it, and then update the subscription. In v2rayNG, add and update it from the subscription group section. If the client reports an invalid format, ask the subscription provider whether the URL is still valid and whether its response uses a format supported by the client.

Read the subscription import steps

First, verify in a browser that the subscription URL can be reached. Then check whether it has expired or been regenerated. Review the client's update log to distinguish DNS resolution failures, connection timeouts, and invalid response content. If the subscription URL itself must be accessed through a proxy, connect to a working node first and then enable the option to update subscriptions through the proxy. If it still fails, create a temporary group for testing so old caches and group rules do not interfere.

Creating a virtual network interface on desktop systems usually requires administrator privileges. Fully exit the client, relaunch it using the system's administrator method, and enable TUN again. The first time TUN is enabled on Android, a VPN connection permission prompt appears; approve it if appropriate. If another VPN app is already running on the device, disconnect it first, because the system normally allows only one app to occupy the VPN interface at a time.

When first verifying a node, briefly use global mode to reduce interference from routing rules. Once the connection works, switch to rule mode for everyday use so the client can choose direct or proxied access based on domains, IPs, and rule sets. Direct mode does not send ordinary requests through the proxy outbound and is mainly useful for temporarily disabling the proxy or troubleshooting the local network. After changing modes, revisit a test page instead of relying only on the client's connection status.

A latency test reflects only the response between the client and node at that moment. It is not the same as download speed and cannot, by itself, prove that every protocol handshake succeeded. Combine it with a real connection test, actual website access, and runtime logs. If a node has low latency but cannot open websites, its transport settings, TLS domain, user information, or routing may be mismatched. Testing several nodes in sequence is more useful for narrowing the problem than repeatedly testing one node.

For ordinary use, update every few hours to once a day, depending on how often the subscription provider changes its nodes. Intervals that are too short create repeated requests and may produce frequent failure entries on unstable networks. If the active node is removed after an update, the client may require you to select another available node. Before an important connection, update manually once, then confirm that the current group, active node, and routing mode have not changed unexpectedly.

Keep LAN addresses on direct routing in the routing settings so router admin pages, printers, and network storage are not sent through the proxy. Common private address ranges and local domains should also prefer direct access. When adding custom rules, place more specific rules before general ones and explicitly select the appropriate outbound. After making changes, test local devices, ordinary websites, and destinations that require the proxy separately to ensure an earlier rule has not intercepted them.

View the routing configuration reference

First, switch to another node in the same subscription. If every node times out, check the local network, system time, DNS, and whether the subscription is up to date. If only one node times out, its address, port, or service status is more likely to have changed. Also verify that the protocol, transport, TLS, or REALITY parameters are complete. A connection timeout in the log means a connection was not established within the allowed time; determine whether the delay occurred during DNS resolution, the TCP connection, or the protocol handshake.

Connected only means that the client process and local proxy endpoint are running; it does not guarantee that the destination node is usable. First confirm that the system proxy or TUN is actually enabled, then visit different sites in a browser and retest with another node. Next, check whether routing was mistakenly set to direct mode, whether DNS requests are failing, and whether another program is using the local port. If access also fails with the proxy disabled, restore basic network connectivity before changing more client settings.

First check whether the browser has its own proxy settings or extension rules, which may override the system proxy. Fully close and reopen the browser so the new process reads the system settings again. Command-line terminals and some development tools usually do not follow the system proxy automatically; configure HTTP, HTTPS, or SOCKS proxy environment settings according to the tool's documentation. Also verify the client's local listening ports and avoid entering the HTTP port where the SOCKS port is required.

rejected means that a connection was refused by one stage of processing, commonly because of a blocked route, an unreachable destination, or incompatible protocol conditions. timeout means that resolution, connection, or handshake did not finish within the limit. invalid user usually means that the user identifier or authentication details do not match the server. During troubleshooting, record the error time and destination first, then check the local inbound, routing rules, and remote outbound in that order. Change only one parameter at a time.