V2Ray FAQ

V2Ray is part of the Project V proxy ecosystem, which includes the V2Fly and Xray core families. Cores handle protocols, connections, and routing; graphical clients provide server lists, subscription management, and settings. For desktop, you can use v2rayN. On Android, options include v2rayNG, which uses Xray, and v2flyNG, which uses the V2Fly core. Whether a setting works depends on support in both the client and its core—not just the software's name.

A client manages connection settings; installing one does not provide servers. Import a subscription URL, individual share link, or configuration file that you are authorized to use. A subscription is typically an update source for a group of server configurations, while an individual share link describes a single connection. Follow the quick-start guide to create a subscription group and import it, then check whether the current group filters are hiding other servers. Do not use a provider's login page URL as a subscription URL.

With a system proxy, apps that honor the setting send requests to the local proxy. TUN mode receives traffic through a virtual network interface. Both determine how traffic reaches the client. Routing presets determine whether traffic goes direct or through the proxy once it reaches the client. Global routing does not capture every app: programs that ignore the system proxy may still connect directly. When getting started, test the system proxy first, then consider TUN based on your needs. Changing traffic capture and routing at the same time makes problems harder to pinpoint.

Subscription URLs may contain access credentials, and share links or full configurations may include authentication details. Treat them like account credentials. Before asking for help, redact tokens in subscription paths, server addresses, user IDs, and passwords. Share only the error keywords, client name, operating system, and steps to reproduce the issue. Check logs line by line for sensitive data; hiding the window title is not enough. If a subscription URL has been exposed, reset it through your provider if possible, then update it in the client.

First check the processor and app architecture shown by your device or operating system. Most mainstream phones released after 2015 use arm64, but a 64-bit processor does not guarantee that the operating system can install a 64-bit app. Do not choose based on purchase year alone. If your system supports arm64, choose that package; if you are unsure, use the universal build, which is usually larger. If installation fails or the package cannot be parsed, check the OS version, whether the download was interrupted, and whether its signature conflicts with an installed version. Avoid repeatedly trying the same failed package.

Identify whether you are importing a subscription URL, an individual share link, or a configuration file, then use the appropriate subscription group or import option. Check for leading or trailing spaces, line breaks, and punctuation added by chat apps. Do not change URL parameters. In v2rayN, saving a subscription URL in the group settings is not enough; you must also update the subscription. Pasting a URL may not immediately populate the server list. If the format is unsupported, ask the configuration provider which export formats are compatible with your client. Do not paste an entire configuration into an individual share-link field.

Open the subscription update log and determine whether the issue is a network connection, authentication, or content parsing failure. Handle expired URLs or subscriptions through your provider account. For timeouts, check whether your current network can reach the subscription service. If the client offers updates through or without a proxy, choose the option that works on your current network; do not try to update your first subscription through a proxy that is not yet working. After a successful update, check the relevant group and clear any filters. Keep existing working configurations; do not repeatedly delete all servers just to test.

On desktop, quit the client first, then grant the permissions required by your operating system to create a virtual network interface and change routes. On Windows, this usually means running the client as an administrator. On macOS and Linux, follow the permissions prompt for your current version; do not change system directory permissions indiscriminately. On Android, approve the system VPN request when connecting for the first time. If TUN still fails after permission is granted, temporarily stop other VPN or virtual network adapter tools and try again. Check the logs for interface creation errors. Switching back to the system proxy can help distinguish a permissions issue from a server connection problem.

Choose the subscription group, select a server in its list, then run the real connection latency test available in your client. The test sends a request to a test address through the client core, so it more closely reflects an actual proxy connection than a basic network probe. Results still depend on the test address, network, and current load. Set a server with a successful result as active, then verify it in a browser. Do not judge reliability by region labels or a single best latency result. For timeouts, check the logs and test again instead of repeatedly switching routing presets.

To route traffic by destination, start with the Bypass mainland China (Whitelist) preset and add rules for your needs. To check whether routing affects a particular request, temporarily use Global as a comparison. Blacklist behavior depends on the preset's matching rules; do not infer what it does from the name alone. Note the original mode before switching, and restore it when you finish testing. Global mode only changes the destination of traffic that has already entered the core. It does not make apps use the system proxy or guarantee that DNS follows the same route.

Create a separate group for each subscription source, give each one a clear name, and save its URL separately. Before updating, confirm whether the action applies to the current group or all groups. Afterward, check that group's logs and server list. Manually edited servers may be replaced when a subscription refreshes, so keep and back up custom configurations separately if you need them long term. If servers seem to be missing, check group tabs, search terms, and filters before deciding that the subscription has fewer entries. A filtered list can look like servers were removed in an update.

Look for per-app proxy settings in v2rayNG. In your version, check whether the option means proxy only selected apps or bypass selected apps, then choose the apps and reconnect. These options do the opposite of each other, so do not assume another client's workflow applies. A browser and an app that opens content in that browser may be separate processes; make sure you test the app that actually sends the request. Work profiles and multi-user spaces may also have separate restrictions. Note the original selections before changing them so you can restore them.

A timeout only means the test did not finish within the allotted time; it does not prove the server is down. Check that your device clock is correct and your basic network works, then test another configuration in the same subscription. If all tests fail, check the logs for DNS resolution, TLS handshake, authentication, or connection-refused errors. If only some fail, ask the configuration provider to verify the address, port, and protocol settings. An unreachable test address can also affect results. If your client allows it, try a suitable alternative test address rather than assuming all servers are down.

Connected may only mean that the local proxy or virtual interface started; it does not confirm remote access. First make sure an active server is selected and passes a real connection test. Then check whether browser traffic appears in the client logs. If there are no requests, check the system proxy, the browser's own proxy settings, and per-app rules. If requests appear but fail, check for DNS, routing, and authentication errors. You can temporarily test with Global routing as a comparison, then restore your original settings. Change one thing at a time and keep the logs from before and after the error. Avoid enabling multiple traffic capture tools at once.

A system proxy does not force every app to use it. Some apps use their own proxy settings or connect directly. In v2rayN's system proxy menu, first confirm that Set system proxy is selected. Then check that the system proxy address and port match the client's current listening values. Restart apps that need to reload proxy settings. Browser extensions may also override system settings. If an app has manual proxy settings, enter the address and port the client is actually listening on. If it has no such option and must be captured, consider TUN mode; Global routing is not a substitute.

For a port conflict, first make sure the client is not running twice, then quit any other proxy tool listening on the same port. If the conflict persists, choose an unused local port in v2rayN's parameter settings and update the system proxy and any apps configured manually. Changing only one of these will not work. If your browser still tries to use the local proxy after you quit, check whether the system proxy setting was left behind. Clear the system proxy before closing the client normally. After an unexpected TUN shutdown, also check other VPNs and network interfaces. Prefer normal shutdown and reconnect steps; do not delete unfamiliar system routes.