V2Ray FAQ

For desktop, start with v2rayN, which supports Windows, macOS, and Linux. On Android, v2rayNG with the Xray core is the first option to consider; v2flyNG, which uses the V2Fly core, is an alternative. Choose based on your device's operating system and the protocols and transports your existing configuration requires—not on how similar the names look. The client interface manages subscriptions and settings, while the core handles the actual connection; they serve different roles. Before switching, export a backup and check whether the new client supports the original node's security and transport settings. Importing a node list successfully does not guarantee full configuration compatibility.

A client manages configuration and connections; the installer does not include a remote service. To connect, you need a valid server address, port, authentication details, and the required transport settings. A subscription lets you retrieve and update a list of nodes in one place. If you run your own server, you can import a single-node share link. If you use a subscription, get the full URL from your service provider and check its expiration and device limits. Subscription URLs may contain access credentials, so never post them in public forums or enter them into unfamiliar online conversion tools. If your server list is empty, add a valid configuration instead of repeatedly switching proxy modes.

A subscription URL fetches a list of nodes, which may change when refreshed. A node share link describes one connection and usually does not update automatically with its original subscription. A configuration backup saves the settings supported by the client and may include groups, routing, and local preferences. Use the subscription settings, clipboard import, and backup restore options for their respective purposes; a backup file is not a subscription URL. Before migrating, check what the backup tool includes rather than assuming another client can restore everything. Before sharing a node, confirm that forwarding is allowed and protect its authentication details.

Not necessarily. Some tests only check whether the server port is reachable; others send a request to a specific test address through the node. Neither checks every step involving the browser proxy, destination DNS lookup, and routing rules. Check the test name and logs, then use your browser to visit a known working destination and see whether a matching connection appears. If the port test succeeds but the page does not load, check protocol authentication, TLS settings, and routing for that destination. If the client test succeeds but the browser produces no log entries, check whether the browser is using the local proxy. A single latency result does not prove that a connection works in practice.

First determine whether adding the subscription URL failed or the update completed without returning any nodes. In v2rayN, add a group under the subscription group settings, enter and save the full URL, then update the subscription. In v2rayNG, open subscription settings from the side menu, add the URL, return to the list, and update it. Menu names may vary slightly by version. Include the complete URL scheme, and remove any leading or trailing spaces and line breaks. Import a single-node share link from the clipboard instead of entering it as a subscription URL. If the content cannot be parsed, check which client format the provider supports. A login page, error page, or website URL is not valid node subscription data.

Keep your existing nodes and groups so you do not lose working configurations while troubleshooting. Check whether the subscription has expired, its URL has changed, and the device date and time are correct; then read the specific error from the latest update. A timeout usually calls for checking the request path and current network. For a certificate error, verify the system clock and subscription domain—do not disable certificate verification. If the client offers direct and proxy-based updates, test each option when you have a working node available. If the update reports success but returns no nodes, check the provider's response and your plan status instead of refreshing repeatedly. Hide the full subscription URL before sharing logs for help.

Most mainstream Android phones released since 2015 will generally use arm64, but the right choice depends on the app architectures supported by your device. A 64-bit processor does not guarantee that the current operating system can install 64-bit apps. If you are unsure, choose universal; it supports multiple architectures but the download is usually larger. If installation fails, check the Android version requirement, available storage, whether the download completed, and whether the installed app has a conflicting signature. Do not uninstall the existing client just to test. Export your nodes and essential settings first, then decide whether to reinstall or try a different architecture.

TUN creates or uses a virtual network interface, and the required permissions depend on the operating system and client. On Windows, it typically needs administrator privileges or a configured service mode. On Linux, it requires the appropriate network management capabilities and device access. On macOS, follow the client prompts to grant access. Android clients generally use the system VPN permission to route traffic; confirm the system prompt the first time you connect. If permissions are insufficient, check the core and service logs and follow the instructions for your version. Avoid running unrelated programs with elevated privileges long-term. Before switching, close other tools that capture traffic. If problems occur, disable TUN, restore a regular network connection, and test TUN separately.

If you only need browsers and other apps that follow the system proxy to connect, start with the system proxy; its traffic path is easier to inspect. Consider TUN when you need to handle apps that ignore the system proxy. The system proxy updates the proxy settings provided by the OS and does not automatically route every program. TUN handles traffic at the virtual network interface and also involves routing and DNS. For your first test, turn off TUN, select automatic system proxy configuration in v2rayN, and confirm that the core is running and the browser works. Then test TUN and note whether DNS or routing changed as well. Changing several traffic paths at once makes the cause harder to identify.

Decide whether a specific destination should connect directly or through the proxy, then check the rule order and final outbound. V2Ray routing usually evaluates rules in order, so an earlier broad rule can override a later, more specific one. Domain rules and IP rules are not always interchangeable. In v2rayN, select the active routing profile and check each domain, address range, and outbound tag; use the logs to confirm the route actually selected. Test one known destination at a time. After temporarily adding a specific rule, start a new connection—do not judge the result using an existing connection that may be reused. Keep the original profile and merge changes into the long-term rules only after confirming they work.

Not necessarily, and you do not need to change everything at once. First find out whether DNS is handled by the system, the browser, or the core: secure DNS in the browser, app-specific resolution, and DNS interception by TUN can all change the request path. Record the current settings and test a domain that fails to resolve. Check the logs for timeouts or empty results, then verify that the current DNS server is reachable and whether requests go direct or through the proxy. Change only the layer used by the current path, then reconnect and test again. Disabling certificate verification does not fix DNS. A failed attempt to access an IP directly does not disprove a DNS issue, since the destination may require the correct hostname and TLS settings.

To keep nodes in sync, add the same active subscription on both devices and check whether your service limits the number of devices or concurrent connections. To move a single node, export a share link or QR code from v2rayN and import it in v2rayNG. Treat QR codes as configuration data and protect them like subscription URLs. Moving nodes does not transfer local listening ports, system proxy settings, app routing, or TUN settings; configure these separately on the new device. Test one node first and confirm that its protocol, transport, and authentication settings were preserved before setting up groups and routing. Use a full backup only when the target client explicitly supports restoring it.

Turn off the proxy first and confirm that your device has a working basic network connection. Then check the device clock and the node address and port. If one node fails, compare it with other nodes in the same subscription. If all nodes fail, check the network path, core status, and shared configuration for a common cause. Connection timeouts, connection refused errors, authentication failures, and TLS errors in the logs point to different issues; do not assume they all mean the node is down. You can test on another working network without changing the node configuration. Do not start by disabling the firewall or changing every security setting. Reproduce the issue with a known configuration and note the time of the error to distinguish remote service problems from local ones.

Connected usually means only that the core or system VPN interface has started; it does not prove that requests are reaching their destinations. Check the selected node and proxy mode, then visit a specific destination and look for a matching log entry. If there are no entries, check whether the browser's own proxy, the system proxy, or app routing is bypassing the client. For DNS errors, check the resolution path. For handshake or authentication errors, verify the node settings. If only a few sites fail, check their routes and whether the remote destinations are reachable. Change one setting at a time, close existing page connections, and try again so cached results do not mask the effect of your changes.

First check that the operating system proxy settings contain the correct local address and port. Then compare them with the actual listening values in v2rayN's parameter settings; do not assume a port based on common defaults. Confirm that the core is listening, and check whether the browser has its own proxy extension or connection settings enabled. Some programs do not follow the system proxy; configure a supported proxy entry for them, or consider TUN after confirming that the regular proxy works. If the settings revert immediately after you save them, check for other proxy tools, management policies, or background scripts. If the network stops working after you exit the client, clear the stale system proxy settings and restore a basic connection.

First distinguish a client interface crash from a core startup failure. If the interface stays open but the core reports an error, find the first relevant error from the latest startup in the log window. For a port conflict, check for duplicate processes and listening settings. For a configuration parse error, review the latest imported or edited content. For missing files, check whether installation completed and review your security software's activity. If the interface closes unexpectedly, note the crash time and check the system application logs. Back up your configuration before making changes; do not repeatedly overwrite the old folder or delete all settings. Restore a minimal working node configuration, then add routing and TUN settings one at a time. Hide addresses, authentication data, and subscription credentials before sharing logs.