V2Ray FAQ

V2Ray is proxy software in the Project V ecosystem. V2Fly continues development of the related core, while Xray is a fork whose features and configuration have evolved independently. v2rayN is a desktop GUI client for managing subscriptions, nodes and proxy modes; the selected core handles the actual connection. A protocol option in the client does not necessarily mean the active core supports that configuration. When troubleshooting, note the client version, core name and startup logs. For REALITY or Vision configurations, check the selected core’s support in particular.

For Windows, macOS and Linux, start with the v2rayN package for your platform. On Android, v2rayNG with the Xray core is the usual choice; consider v2flyNG if you need an existing V2Fly configuration. Choose based on your operating system, processor architecture and the features your nodes require—not on similar-sounding names. Menu locations, routing options and subscription parsing can vary between clients, so review your settings when switching. Import and test a connection in one client before moving to other devices to keep troubleshooting manageable.

VMess, VLESS and Trojan are proxy protocols, as is Shadowsocks. REALITY is a transport security configuration often used with VLESS; it is not a protocol name you can swap in at will. VLESS does not encrypt content by itself, so transport security must be configured separately. Client settings may also include TCP, WebSocket, TLS and flow, each describing a different part of the connection. When importing or entering settings manually, match the complete parameter set provided by the server. Changing only the protocol dropdown—or assuming compatibility from similar names—is not enough.

A subscription URL retrieves a group of nodes, and the client requests its contents again when updating. A share link usually describes one node, such as a vmess:// or vless:// link. A native JSON configuration can include complete settings for inbounds, outbounds, routing and DNS. These formats do not all belong in the same import field. Use a subscription group for a node list you need to refresh, clipboard import for a single node link, and the client’s configuration import feature for a full configuration. Subscription URLs may contain access credentials; hide the entire URL in screenshots, logs and support requests.

Most newer Android phones can use the arm64 package, which is usually smaller. The universal package supports multiple processor architectures and is a better fit when you are unsure of your device’s architecture or need compatibility with older devices. A device’s purchase year is only a rough guide: some phones have 64-bit-capable chips but still run a 32-bit system. Check the app ABI supported by your system. If arm64 is incompatible, try the universal build after confirming your system requirements. For upgrades, use packages from the same signing source. Installation failures can also result from a signature conflict, Android version or insufficient storage—not just architecture.

Make sure you copied the full subscription URL, not a service homepage, QR code image URL or single-node share link. Remove any leading or trailing spaces, and check that a chat app did not truncate the parameters. Then verify that the URL is still valid, your account has access and the response uses a format supported by the client. Opening the URL in a browser does not prove it returns a node list: a login page, error page or redirect may load successfully too. Use the import option recommended for your client by the provider. Don’t keep changing protocol types; import a share link from the clipboard instead.

The system proxy only affects apps that follow the operating system’s proxy settings; it does not capture all traffic automatically. First, select a node and confirm the core is running. Then check that the client’s local listening port matches the port recorded in the system proxy settings. Browser extensions, enterprise policies or browser-specific proxy settings can override the system setting; fully quit and reopen the browser after making changes. If only one app is affected, check its own proxy options. If no apps work, check whether the local port is already in use or blocked by security software. Consider TUN only if you need to capture traffic from more apps, and avoid running multiple proxy tools at once.

TUN mode creates a virtual network interface and may change routing and DNS, so it needs more permissions than the standard system proxy. On Windows, follow the client’s instructions to run it as an administrator and check that the virtual adapter component loaded successfully. On macOS and Linux, grant permissions according to the instructions for your version; don’t apply steps meant for another operating system. Close other VPN or TUN apps before trying again. If it still fails, check the logs for the specific permission or device error and confirm that system policies allow interface creation. Don’t leave the firewall disabled to dismiss a warning. For ordinary browser use, switch back to the system proxy to test.

These settings work at different layers. The system proxy and TUN determine how traffic enters the client; rule-based and global routing determine which outbound handles traffic after it enters. If you only use a proxy-aware browser, start with the system proxy and rule-based routing. Consider TUN for apps that ignore system proxy settings. Global routing usually sends all captured traffic through the proxy outbound, but it cannot make uncaptured apps use the client. Change one setting at a time, keep the original configuration and test before changing anything else. This helps distinguish traffic-capture problems from node failures.

Select a node in the list as the one to use, then start the core and set the required proxy mode. Treat the list’s test results as a guide: tests may measure a TCP connection, handshake or response from a specific URL, not actual webpage download speed. To verify, visit a page that should use the proxy and check the logs for a connection and the outbound used. Then visit a page that should connect directly and confirm routing behaves as expected. Compare nodes without changing the mode or rules. A failed test alone is not a reason to delete the entire subscription.

Android’s VpnService creates a local interface for capturing traffic and requires system approval the first time it runs. If the connection drops when the screen turns off, check whether battery optimization, background activity or auto-start restrictions are affecting the app. Allow the necessary background activity in your device’s settings. In per-app proxy settings, include mode captures only selected apps, while exclude mode skips selected apps. Confirm which mode is active before configuring it, then restart the connection. Don’t accidentally exclude the browser you’re using to test. Background disconnects and node timeouts are different problems; use the disconnect time and logs to tell them apart instead of immediately changing subscriptions.

Keep subscriptions from different sources in separate groups and give each group a clear name so you can identify which one failed to update. Set the automatic update interval based on the provider’s limits and how often nodes change; there’s usually no need to update every few minutes. Frequent requests may trigger rate limits and increase background activity on mobile devices. After importing a subscription, update it manually and confirm it works before enabling automatic updates. A temporary network outage does not mean all existing nodes are invalid. Before removing duplicates or changing a subscription URL, note the active node and essential settings so you don’t lose a working setup.

Subscription updates and node connections use separate network paths. Working nodes do not prove that the subscription URL is reachable. Identify whether the error is an invalid URL, request timeout, certificate error or parsing failure, then check whether updates need to go through the current proxy. Menu names vary between versions, so verify the actual path used for update requests. For certificate errors, check the system date, time and time zone; don’t disable certificate verification. If the response is a login or error page, ask the provider to confirm the URL is still valid. Avoid repeated rapid retries, and keep working nodes available while you troubleshoot the subscription.

First confirm that your normal internet connection works and that the core starts successfully. Resolve local issues such as a busy listening port or configuration parsing errors before testing nodes. If the core is running, check that the node address, port, protocol, transport and security parameters match the provider’s settings. Keep the proxy mode and routing unchanged, then compare with a known-working node. If only one node fails, its configuration or service is more likely at fault. If all nodes fail, check the system clock, DNS, network conditions and security software logs. A test timeout alone is not enough to pinpoint the cause; compare actual access results with connection logs.

“Connected” usually means only that the local service or virtual interface has started—not that the remote handshake or destination request succeeded. First, open a normally accessible page to confirm basic connectivity. Then check whether browser traffic reaches the client: if the logs show no new connections, look at the system proxy, per-app settings or TUN capture. For handshake errors, verify SNI, certificates and protocol parameters. For domain resolution errors, check the DNS path. Finally, make sure routing isn’t sending traffic to the wrong outbound. Change and test one setting at a time; changing the node, DNS and rules together makes the cause hard to identify.

First determine whether all access is affected or only some domains. With TUN, DNS requests may be captured, while remote DNS may depend on the proxy outbound. Check for a circular dependency that prevents startup, and confirm the selected core supports the current DNS configuration. To restore your connection, turn off TUN and the system proxy normally in the client, then exit the app. Check whether the system still has a local proxy enabled or invalid DNS settings. If needed, restore the network adapter’s original automatic settings and reconnect. Don’t replace all your settings with a public DNS address copied from elsewhere; note the original configuration so you can revert.