V2Ray FAQ

The Project V ecosystem, which includes V2Ray, provides components for proxy communications. V2Fly and Xray are related core projects that handle protocols, connections, routing and DNS. v2rayN, v2rayNG and v2flyNG provide graphical interfaces for importing server details, managing subscriptions and changing settings. An open client window does not mean the core is running, and a running core does not guarantee the remote service is available. When troubleshooting, check the client settings, core startup logs and server parameters separately instead of relying only on the connection status shown in the interface.

For desktop use on Windows, macOS or Linux, start by looking at v2rayN. On Android, v2rayNG, which uses the Xray core, is usually the first option to consider; choose v2flyNG if you need a V2Fly core. Before deciding, check which protocols, transport methods and core features your subscription requires—similar-looking interfaces do not guarantee compatibility. Import formats, routing presets and settings locations can vary by client and version. When switching, keep your working configuration and test with a single entry first. Clients do not provide servers, so you will still need valid node details or a subscription URL.

The arm64 package is for devices that support 64-bit ARM apps. A universal package typically includes components for multiple processor architectures, so it is usually larger. Most newer Android phones can start by checking the arm64 option, but a device’s age alone does not tell you its architecture: some processors support 64-bit apps while the operating system supports only 32-bit apps. Check the architecture in your device information. If you can’t confirm it, consider the universal package and consult the client’s current release notes. If installation fails, also check the Android version, available storage and possible signing conflicts with an existing app rather than assuming it is a network issue.

Changing the protocol name in the client alone is not enough. VLESS, VMess and Trojan are different proxy protocols; REALITY is a related connection security configuration. The client may also need to match the server’s transport and handshake parameters. The server address, port, user ID or password, and any required server name, public key or short ID must match the server configuration. If the subscription provides complete settings, keep them as supplied; save your current configuration before making manual changes. Choose a protocol based on server support and compatibility with your core—not on the name alone as an indicator of speed or availability.

First, distinguish a subscription URL from a link for sharing a single node. Subscription URLs are usually added as a subscription group; individual node links are imported through the clipboard or share-link option. Remove any leading or trailing spaces, check that a messaging app has not cut off the link, and make sure you have not copied the page title along with it. After saving a subscription group, you may need to update it and check whether any filters are enabled. A URL can open successfully yet produce no usable entries if it returns a login page, an error page or a configuration format the client does not support. Note the update message and ask the provider which formats are supported. Subscription URLs contain access credentials, so do not share them publicly.

Downloading a subscription and connecting through an existing node use different request paths, so one working does not prove the other is working. Check whether the error points to DNS resolution, a connection timeout, a certificate error or expired authorization. Then verify your device’s clock and the subscription’s validity period. If the client offers an option to update through a proxy, try it when an existing node is confirmed to work. Conversely, if the proxy path is unavailable, check whether a direct update can reach the subscription. Keep the existing subscription group and working entries while troubleshooting; don’t clear everything before updating. If you see a rate-limit message, wait before trying again instead of clicking repeatedly or creating duplicate groups.

TUN mode creates a virtual network interface and changes routing, so it needs more permissions than a regular local proxy. On Windows, follow the client’s instructions to run as administrator or install its service. On macOS and Linux, grant access using the prompts for your version; avoid changing permissions for the entire configuration directory. On Android, approve the system VPN connection request and check whether another app is already using a VPN connection. If TUN still fails after authorization, check the logs for interface, driver or routing errors. Restore regular proxy mode and confirm the node works before troubleshooting TUN. Don’t leave the firewall or other system protections disabled as a workaround.

First, confirm that the client core has started. Then check that the system proxy points to the local address and port the client is currently listening on; the HTTP and SOCKS ports may differ. A browser’s own proxy extension or network settings can override the system settings, and some apps do not use the system proxy at all. For testing, use just one proxy manager, restart the browser and check the system proxy bypass list. Don’t bind the listener to all network interfaces to fix a problem on the same device. If the app does not use the system proxy, check for a manual proxy option or use TUN after understanding which traffic it will capture.

The system proxy determines which app requests are passed to the client. Routing determines which outbound is used for requests that reach the core. TUN changes how traffic is captured. These are separate settings at different layers. A client’s global mode usually sends captured traffic through the proxy outbound by default; it does not automatically control every program. Rule-based routing selects proxy, direct or blocked routes based on domains, addresses or other conditions. Routing rules may still apply when TUN is capturing traffic. When troubleshooting, first confirm that the request reaches the core, then check the rule match so you don’t mistake a traffic-capture issue for a node problem.

A test result reflects only how a particular test method performed at that moment. A successful port check may mean only that the remote port is reachable; it does not guarantee a successful protocol handshake, DNS lookup or request to the target site. A request-based test applies only to the test address used. Before choosing a node, confirm that it can load the sites you need, then check its stability over time and review the provider’s traffic multiplier and region details. Lower latency in one test does not mean higher throughput. Keep the test method and network conditions consistent, and switch nodes one at a time. Changing DNS, routing and nodes all at once makes it difficult to tell what helped.

Create a separate group for each source, give each group a descriptive name, and check its update URL and filters. Before enabling automatic updates, confirm that the new subscription parses correctly. Keep manual entries you want to retain in a separate place so a subscription refresh does not overwrite them. Duplicate names do not necessarily mean the entries point to the same server; compare the address, port, protocol and group source. If a list gets shorter after an update, check the filters and the provider’s response before deleting any groups. Exported or backed-up configurations may contain subscription credentials, user IDs and passwords, so store them securely.

Before making changes, note the current preset and working nodes. Change one setting at a time, then save, reload or restart the core as required by the client. Routing rules often depend on their order, so check that a broader rule is not matching before the one you want to test. DNS results can also be affected by browser-level resolution, system caches and core caches. Repeat the test with the same destination and check the logs for the actual outbound or resolution error; don’t rely only on a toggle in the settings page. Restore the usual log level afterward. Before sharing logs, remove addresses, credentials and personal browsing records, and include only the relevant lines.

Turn off the proxy first and confirm that your basic internet connection works. Then check the selected node’s address, port, protocol and subscription status. If only one node fails, compare it with other entries in the same subscription. If all nodes fail, check whether the core has started, whether your device’s clock is accurate and whether the local firewall is blocking the client. A connection timeout and an authentication failure in the logs mean different things; for authentication errors, check the credentials and protocol settings. If needed, test on another known-working network, but don’t reinstall the client and rewrite the configuration at the same time. The provider will need to resolve server outages or expired subscriptions.

A connected status may only mean that the core is running. First, confirm that browser requests are reaching the client: check the system proxy mode, local listening port and any browser-specific proxy settings. Then look for DNS resolution failures, handshake errors or routing to the wrong outbound in the logs. Try the same website with a known-working node to distinguish a node issue from a local configuration issue. Next, check DNS settings and routing rules. If needed, temporarily restore the client’s default preset for comparison. If only certain sites are affected, consider whether those sites are available or restricting access rather than assuming the entire proxy connection has failed.

First determine whether the failure is resolving the server’s domain or the destination website’s domain. The former prevents the node from connecting; the latter may let the node connect while websites remain unavailable. Check the DNS protocol and address, and confirm that it is reachable. With encrypted DNS, also check how its own hostname is resolved initially. Don’t route every DNS request through a proxy that hasn’t connected yet, as this can create a dependency loop. Browser-level DNS and system DNS may use different paths, so check them separately. Change one setting at a time, reload the core and test again. A public DNS address is not a guaranteed fix for every network.

After closing the client, check whether the system proxy still points to a local port that is no longer running. If needed, restore automatic settings or disable the manual proxy in your system network settings, and check for leftover settings from other proxy tools. If you use TUN, close it normally through the client first, then confirm that the virtual interface and routes have been restored. Don’t delete system interfaces you don’t recognize. After switching Wi-Fi networks or waking from sleep, reconnect to the network, restart the core and test the node again. If the problem continues, save the error logs and undo recent changes one at a time. Don’t reset all network settings, as this could disrupt other work connections.