V2Ray FAQ
Subscriptions, Proxies & Connection Troubleshooting

V2Ray is part of the Project V proxy ecosystem, with V2Fly and Xray as related core families. The core handles protocol connections, routing rules and traffic forwarding. v2rayN is a graphical client that manages servers, subscriptions and settings, then starts the core to apply the configuration. An open client interface does not mean the core started successfully. If a connection fails, check the core startup messages in the logs first, then confirm that the selected core supports the server's protocol and transport. Configuration fields are not necessarily interchangeable between cores.

For desktop devices running Windows, macOS or Linux, choose v2rayN. On Android, v2rayNG with the Xray core is the usual choice; consider v2flyNG if you need the V2Fly core. Most mainstream Android phones released after 2015 can usually use arm64, but check your device's processor and the app architectures supported by its system. A universal package includes multiple architectures and is typically larger, making it useful when you're unsure which architecture you need. If installation reports that the app is incompatible, check the system requirements and architecture instead of repeatedly downloading the same file. A universal package won't fix an outdated Android version.

A client manages configurations and connections; after installing it, you need to import an existing subscription or a single-server share link. A subscription URL retrieves and updates a group of servers, while a share link usually describes just one server. They can't be entered in the same way. Check which type your configuration provider supplied, then use the subscription group or clipboard import feature as appropriate. Subscription URLs may contain account identifiers, so treat them like credentials. Don't post them publicly, include them in screenshots or paste them into online conversion tools. Once servers appear in the list, select an active server and check the connection settings.

The system proxy tells apps that follow the system proxy settings how to send requests to the client. A routing preset determines which outbound route traffic entering the core will use. TUN mode captures eligible traffic through a virtual network interface, so it covers different traffic from the system proxy. Enabling the system proxy therefore doesn't send every app through the proxy, and choosing global routing won't capture requests that never reach the core. When setting things up, first test browser access with the system proxy. Enable TUN only if needed for specific apps, so you can pinpoint issues without changing the traffic entry point, routing and DNS all at once.

First check whether you're importing a subscription URL or a single-server share link. In desktop v2rayN, press Ctrl+V in the server list to import a share link. Add subscription URLs to a subscription group, then update the group. When copying, remove surrounding explanatory text, line breaks and extra spaces, but keep the full URL and its parameters intact. If the link isn't recognized, make sure you didn't copy a webpage URL, a QR code image URL or text truncated by a messaging app. If it still fails, check that the client supports the link's protocol and format, and ask the configuration provider for content compatible with your client. Don't change the encoding at random.

Working servers only show that their existing connection settings are still valid; they don't prove that the subscription URL is reachable. Keep the current group and servers, then check whether the update failed because of a parsing error, connection timeout, certificate error or account issue. If the client supports updating through a proxy, try a server you've already confirmed works. If that fails, compare the result with a direct update. Ask the subscription provider whether the URL changed, the account expired or the response format is incorrect. Don't delete the old group just to retry, and never post a full URL containing account parameters in public logs.

Whether you need an additional runtime depends on the release package and UI type. A crash alone doesn't mean .NET is missing. Extract the files completely before launching the app; don't run it from inside the archive. Put it in a folder your account can write to, and check your system's security or quarantine logs. Install the required desktop runtime only if the system explicitly reports that it's missing, and choose the version and architecture specified for the package. If the issue started after an upgrade, back up your configuration and check for compatibility with older settings. Don't delete all your data right away or run the app as an administrator indefinitely; either can hide the underlying permissions issue.

TUN creates a virtual network interface and changes routing, so desktop systems may require administrator approval, a privileged service or additional components. Requirements vary by client version and platform. Turn off TUN first and confirm that the regular system proxy works, then grant permissions as prompted by the client. On Android, approve the system VPN connection request the first time you connect, and check whether another app is already using the VPN connection. If TUN still fails after authorization, check the logs for errors creating the interface, adding routes or missing components. Don't simply turn off the firewall. After disabling TUN, confirm that normal network access has been restored.

Routing presets and subscription content are separate settings. Switching between bypass-mainland-China and global routing usually doesn't require reimporting your subscription. Bypass-mainland-China uses the loaded domain and IP rules to decide which traffic goes direct and which goes through the proxy; the result also depends on rule order, data files and DNS results. Global routing generally sends traffic not matched by a higher-priority rule through the proxy outbound. After selecting a preset, apply or reload the configuration as prompted, then check the logs while visiting the same test destination. If you need access to local network resources, also check the direct-routing rules for private IP ranges. Global routing doesn't necessarily override every existing rule.

TCPing typically checks whether a TCP connection can be made to a target address and port. It doesn't test the full proxy protocol, authentication or a web request. A real connection latency test reaches a test destination through the proxy, so it better reflects actual use, but results still depend on the destination, DNS and current network conditions. Download speed tests measure sustained throughput, use data and don't represent the speed of every website. Start with real connection tests to find working servers, verify them with your actual apps, then run a brief download test if needed. Don't rank servers by TCPing alone or test many servers at once; concurrent connections can skew the results.

Create a separate group for each subscription URL and name it by source or purpose. Then filter the server list by group. This makes it easier to identify the source of an update failure and keeps servers from different subscriptions separate. An update may recreate the servers in that group; whether manually edited names or settings are preserved depends on the client. Export or copy any custom configuration you need to keep into a separate manual group before updating. Before deleting a group, check for entries you added manually. Group names are for organization and don't directly change routing or outbound selection.

If your subscription provider allows multiple devices, you can add the same subscription URL on each one. Connection, data and device limits still depend on your account. To migrate a single server, use its share link or QR code, then check the transport, TLS and related settings after importing. A full desktop client backup may also contain UI preferences, routing rules and local port settings, so don't assume it can be imported directly into an Android client. Sharing a subscription doesn't sync system proxy, TUN or DNS settings. After migrating, test one server first, then adjust the traffic entry settings for the new device's network.

First confirm that regular internet access works with the client closed. Then run a real connection test for one server and check the logs from the same time. If all servers fail at once, check local DNS, network changes, firewall blocks and whether the core started. If only a few servers fail, check their addresses, ports, account status and transport settings. A reachable port with failed authentication isn't the same as a timeout. Retest on another trusted network to narrow down the cause, but change only one setting at a time. When reporting the issue to your configuration provider, include the error type and time, but redact account details and authentication fields from addresses.

Connected may only mean that the local service or virtual interface has started; it doesn't confirm that requests are reaching remote destinations. Check the active server, then confirm that your browser follows the system proxy settings and that no separate proxy extension is overriding them. Visit a known working site and check whether the request appears in the logs. If there is no request, check the traffic entry point and local port. If there is a request but it fails, check routing, DNS, remote authentication and TLS. If only one site fails, test other destinations before reinstalling the client. When temporarily disabling TUN or a browser proxy extension, change one thing at a time, note the result and restore the original setting afterward.

The system proxy only affects apps that read and follow that setting. Some apps use their own network stack or proxy configuration. First confirm that the client works in a browser, then check for proxy settings in the app that bypasses it. If you need to enter the settings manually, use the client's current listening address, port and protocol. Don't swap the SOCKS and HTTP ports or copy numbers from an old screenshot. Another proxy app may override the system settings, so quit other proxy tools and check again. If an app doesn't follow the system proxy, consider TUN. If network access breaks after you quit the client, check whether the system proxy still points to a stopped service.

First identify where the error occurs: resolving the server hostname, updating a subscription or resolving a website through the proxy. Changing DNS affects the resolution path; it won't fix an incorrect server name, expired account or invalid TLS settings. For a certificate error, also check the system date, whether the certificate matches the server name, and whether the network requires a web-based sign-in first. Don't hide the error by disabling certificate verification. If DNS is confirmed as the cause, record the original settings, change one thing at a time and retest the same domain. If TUN and FakeDNS are both enabled, check that DNS requests enter through the expected interface and that routing rules don't create a loop.