V2Ray FAQ

V2Ray generally refers to proxy tools and related technologies in the Project V ecosystem. The core handles protocol connections, routing and traffic forwarding; the GUI client manages server lists, subscriptions and system integration. On desktop, v2rayN is a common starting point; v2rayNG is widely used on Android, while v2flyNG is an alternative built on the V2Fly core. A setting appearing in the interface does not guarantee that the current core supports it. When troubleshooting compatibility, note the client name, core type and error message—not just the app icon or a screenshot of its window.

Changing the protocol name in the client alone is not enough. The protocol, port, identity details, transport and security layer must all match the server. VLESS does not encrypt payloads on its own and is commonly paired with security options such as TLS or REALITY. VMess has its own authentication and encryption mechanisms, while Trojan typically relies on TLS. REALITY is a security layer, not a standalone server type that can replace every protocol. Import a complete share link when possible, then check the transport and security settings. If a field is unsupported, check the core's capabilities rather than removing security settings to force a connection.

A subscription URL retrieves a set of server configurations and fetches them again when updated. A share link usually describes one server, for example with a vmess:// or vless:// URL. Raw JSON may contain a full configuration, including inbounds, outbounds, DNS and routing. These formats are not interchangeable just by changing a file extension, and they may require different import options. Check whether the provider supplied a subscription, a single server or a custom configuration, then choose the matching menu. Subscription URLs may contain access credentials; redact the full path, query parameters and identity details before asking for help publicly.

Most newer Android devices can use the arm64 build, but a device’s age alone isn’t a reliable guide: some processors support 64-bit while the installed OS is still 32-bit. Check the device or system specifications for ABI information and confirm that arm64-v8a is listed. If you’re unsure, choose universal; it usually supports more devices but has a larger file size. If installation fails, check the Android version requirement, available storage, permission to install from that source and possible signature conflicts. Export any settings you need before switching clients or download sources—you don’t want to uninstall first and discover that the subscription URL wasn’t saved.

First, make sure the copied URL is complete. Remove any spaces, line breaks or punctuation added by a messaging app. In v2rayN, save the URL in the subscription group settings, then run an update; saving the group alone won’t populate the server list. Check the update log next to distinguish a request failure from a parsing failure. For request failures, check the network, URL expiration and access permissions. For parsing failures, check whether the client recognizes the subscription format. A successful request that returns a login page or error page still won’t produce servers. Make sure group filters aren’t hiding the results before trying to import again.

Keep your current working configuration; don’t clear the list after a single failed update. Check the device time, network and subscription expiration, then use the log to identify a DNS failure, timeout or access denial. In v2rayN, first try updating the current subscription without using the proxy. If the URL is only reachable through a working proxy, choose the option to update through the proxy. Don’t use an expired server for updates, or you may end up in a loop where updating depends on a connection that itself depends on an update. If failures continue, ask the provider to confirm the URL and service status, and avoid sending repeated requests in quick succession.

A system proxy provides a proxy address to apps that support the setting; it doesn’t automatically route traffic from every app. Make sure the client core is running, then check the local listening address and port. Don’t enter an HTTP port in a SOCKS setting. Check whether the app has its own proxy settings, needs to be restarted or lists the destination domain as a proxy exception. Some command-line tools and games don’t use the system proxy and need separate configuration or a suitable TUN mode. Start testing with a browser known to support the system proxy; one app’s behavior doesn’t tell you what the whole system is doing.

TUN creates a virtual network interface and changes related routes. The required permissions depend on the operating system, client version and installation method. Close other VPNs and virtual network tools first, then check the log for permission, driver or interface creation errors and grant access as prompted by the client. Windows may require administrator privileges; other desktop systems may require a service to be installed or system authorization. Don’t leave security software disabled as a substitute for troubleshooting. Confirm that regular proxy mode works before enabling TUN. If the network fails afterward, disable TUN and restore connectivity, then check DNS, routing and interface conflicts separately.

For everyday use, start with rule-based routing so matching domains or addresses use their assigned outbound. Global proxy mode is useful for a brief comparison test to see whether routing rules are the problem, but results still depend on how apps are intercepted and on bypass settings. Global mode doesn’t guarantee that every app will use the proxy. For a fair test, keep the server, destination and network the same; change only the mode, compare results, then restore your usual settings. If global mode works but rule-based routing doesn’t, check rule order, the default outbound and domain matching. Don’t delete every direct-connection rule to fix a single site.

In routing settings, AsIs matches against the original destination and doesn’t resolve domains for IP rules. IPIfNonMatch resolves the domain and retries IP matching if no domain rule matches. IPOnDemand resolves a domain when a rule requiring an IP address is encountered during matching. This controls routing matches; it doesn’t mean every DNS request follows the same process. If you mainly use domain rules, keep the client’s default setting. Change it only if you rely on IP rules, and verify the result alongside your DNS settings. Unnecessary changes can alter rule matches or add DNS lookup delays.

Per-app proxying on Android relies on VPN-based traffic interception. In common configurations, when per-app proxying is enabled without bypass mode, the selected apps use the VPN. With bypass mode enabled, selected apps usually bypass the VPN and the remaining apps use it. Check the current screen’s description to confirm how its list works and avoid reversing the selection logic. An app using the VPN doesn’t necessarily send all its traffic through the remote proxy; direct-connection rules may still apply. After changing the app list, reconnect and restart the app you’re testing. If another VPN is running, resolve the conflict first—Android generally allows only one active VPN at a time.

A latency test reflects the response time measured by a particular method; it doesn’t directly predict page loads, sustained downloads or video playback. TCP connectivity checks, real requests and ICMP tests differ in purpose and method, so their results aren’t directly comparable. Use the same network and test method, then compare with real-world access and logs. Before making changes, use the client’s export or backup option to save subscription groups, manually added servers and custom rules. Confirm that the backup can be restored before proceeding. Backups may contain subscription credentials and identity details, so store them securely and redact sensitive information from screenshots or logs before sharing.

Turn off the proxy first and confirm that the basic network connection works. Check the device’s date and time zone, then verify the server address, port and subscription status. Look in the logs for DNS failures, connection refusals or handshake errors rather than assuming every issue is a slow connection. With the same settings, try another working server, or test the same server on a different network—change only one condition at a time. If just one server keeps failing, ask the provider to check its status. If all servers fail, focus on the local network, core startup and traffic interception. Record the error instead of repeatedly clicking Connect.

Connected may only mean that the local service or Android VPN has started; it doesn’t prove that the remote server is reachable. Check that the right server is selected and that the core log shows no errors. Then confirm that the browser is using the system proxy or is covered by VPN or TUN interception. Test several domains to distinguish a single-site issue from a general failure. If only rule-based mode fails, check routing and DNS. For Android connections that drop in the background, check battery optimization and background activity restrictions. Don’t change the protocol, DNS, routing and port all at once; you won’t know what fixed the issue. Keep each change reversible.

Note the failing domains and the errors in the log. If a domain won’t resolve, DNS times out or the returned address looks wrong, check the current DNS configuration and whether it’s reachable. If resolution succeeds but traffic goes through the wrong outbound, inspect the matched rule and rule order. Routing’s domain resolution strategy, the core’s DNS, system DNS and the browser’s secure DNS may each operate at different stages; changing one doesn’t automatically change them all. Temporarily disable the browser’s custom DNS for comparison, then restore the setting. If IPv6 is involved, check that both the local network and selected outbound support IPv6 connectivity.

In the client, turn off TUN or stop the VPN, clear the system proxy, then exit normally. If the app has already crashed, check the system network settings for a manual proxy pointing to a local loopback address. Remove it only after confirming it was added by this configuration. Reconnect to the network and check for other running VPN or proxy services. Don’t bulk-delete network adapters or system routes. If connectivity still won’t return, note the operating system, client and core versions, interception mode, when the issue began and relevant error logs. Redact server addresses, subscription credentials and identity details before asking for help.