V2Ray FAQ and Connection Troubleshooting

Start by distinguishing the core from the graphical client. Project V is the open-source ecosystem behind related tools and protocols. V2Fly maintains the V2Ray core, while Xray is a separate core fork. v2rayN provides a desktop interface for managing subscriptions, servers, and routing. v2rayNG is an Android client built around the Xray core; v2flyNG is an alternative that uses the V2Fly core. Whether a configuration works depends on the core the client actually runs and its version. If an import fails, check protocol and transport support rather than relying on similar product names.

The client manages configurations and routes traffic; the installer does not include usable servers. First obtain a subscription URL, share link, or configuration file you are authorized to use, then add it through the subscription group or import option. A subscription URL is used to update a set of configurations; an individual share link usually describes one server. They are not interchangeable. If you added a subscription but see no entries, update it and check the update log. Also make sure the selected group or search filter is not hiding servers. Do not use an account sign-in page URL as a subscription URL.

A system proxy exposes a local HTTP or SOCKS proxy for apps to use; only apps that read the setting will follow it. TUN mode routes traffic that matches its routing rules through a virtual network interface. It usually covers more traffic, but is also affected by permissions, exclusion rules, and DNS settings. v2rayNG's VPN mode uses Android's VPN interface to receive device traffic; it does not connect to a separate commercial VPN service. When troubleshooting, use only one traffic-capture method at first. Once it works, add routing rules as needed and avoid running multiple proxy tools that modify the network path.

Changing only the protocol name in the client is not enough. VMess, VLESS, and Trojan use different authentication fields and server configurations. REALITY is a transport security configuration, not a standalone server type alongside those protocols. The server address, port, credentials, transport, and security settings in the client must match the server. After importing a share link, keep the parameters supplied by its provider. If a field is unsupported, check whether the client or core needs an update. Do not troubleshoot by disabling security checks or switching protocols at random.

Check the URL first. Copy the complete subscription link, remove any leading or trailing spaces, and make sure it contains no line breaks, punctuation added by a messaging app, or truncated query parameters. In v2rayN, enter it in the subscription group's URL field and run an update. In v2rayNG, use the subscription group settings; do not import a subscription URL from the clipboard as if it were a single server link. If the response is a sign-in page, an error page, or a format the client does not support, ask the provider for the correct URL. Keep the error type when reviewing logs, and hide the full subscription URL and credentials before sharing screenshots.

Check your device's processor architecture and the application ABIs supported by its operating system. Most newer Android phones can use the arm64 package, but release year alone is not conclusive; some devices may still run a system that supports only other ABIs. The universal package includes multiple architectures and is usually larger, making it an option when you cannot confirm the right one. If installation fails or the app is reported as incompatible, also check the Android version, available storage, and whether the signature matches an existing installation. Do not uninstall the old version right away. Export and safely save your configuration first, then decide whether to reinstall based on the actual error.

Turn off TUN and save your settings. Then grant the permissions required by your operating system and client version to create a virtual network interface and change routes. On Windows, exit v2rayN and relaunch it as an administrator. On macOS and Linux, follow the client's authorization prompts; do not move a regular user's settings directory into a system directory without a reason. If it still fails, check the log to see whether the issue is a permission denial, virtual interface creation failure, or route conflict. Also check whether another VPN or network management tool is using the interface. Verify that a regular proxy connection works before troubleshooting TUN separately, so a server issue is not mistaken for a permissions problem.

On macOS, check About This Mac for your chip: choose arm64 for Apple Silicon and x64 for an Intel processor. On Linux, check both the processor architecture and your distribution's package format. Debian- and Ubuntu-based systems typically use deb packages; Fedora-based systems typically use rpm. Run uname -m in a terminal to help identify the architecture: x86_64 corresponds to x64, and aarch64 usually corresponds to arm64. A successful installation does not guarantee that dependencies and desktop permissions are ready, so watch for errors on first launch. Do not install packages from different distributions just because their file extensions look similar.

Save your current configuration using the client's backup or export feature. Then create separate subscription groups for each source and give them recognizable names. Update only the group you need, and clear any server-list search filters first so you can confirm the results. Server parameters provided by a subscription may be overwritten during an update. If you need to keep manual changes, create a separate entry instead of editing a subscription entry and expecting those changes to persist. Manage routing rules separately from subscription contents. You can note entry changes and logs before and after an update, but do not put a full subscription URL in public notes.

Start by checking what the test measures. A TCP connection test mainly shows whether a connection can be established to a specific port. A test request sent through the proxy is closer to a real visit, but still cannot represent every website's performance. Download speed also depends on network congestion, server load, the destination, and your local bandwidth, so do not choose a server based only on the lowest latency. Test in batches on the same network and against the same target, then try the services you actually need. Speed tests use data and may trigger server-side limits. Avoid frequent concurrent tests across an entire subscription, and do not treat a single timeout as permanent failure.

Read the mode description on the per-app proxy screen for your version before selecting apps. The list may specify apps to route through the VPN or apps to exclude; selecting an app does not have a fixed meaning by itself. After changing the list, restart the VPN connection as prompted to apply the new app scope. Start by testing with one browser rather than adding many apps at once. System components, work-profile apps, and separate download processes may not be covered by the same settings. If an app behaves unexpectedly, return to a simpler app list and check exceptions one at a time.

Connect both devices to the same trusted LAN. In v2rayN, enable connections from the LAN, confirm the listening address and HTTP proxy port, then allow that port through the computer's firewall only on trusted networks. In the phone's Wi-Fi proxy settings, enter the computer's LAN IP address, not 127.0.0.1. Use the port shown by the client. This mainly affects apps that follow the Wi-Fi HTTP proxy setting; it does not route all phone traffic. If the connection fails, check for guest-network isolation, computer sleep, or a changed IP address. Turn off LAN listening when you are done to avoid exposing the proxy more broadly.

If existing servers work, the data connection may be fine; subscription updates use a separate request path. Start with the update log. Timeouts often point to the access path or DNS. For an authentication error, check whether the URL has expired; for a parsing error, check the response format. If your version supports updating subscriptions through a proxy, try that while keeping your working servers, and confirm that the update request actually uses one of them. Do not clear all your settings or repeatedly delete and recreate the group. For TLS or certificate errors, check the system time and any network sign-in page instead of disabling certificate verification.

First confirm that your device has a working internet connection, then check the server address, port, and subscription status. Test a server known to work as a comparison to determine whether one entry or all entries are failing. If all fail, check the local firewall, other VPNs, DNS resolution, and network restrictions. If only one fails, focus on the server status and whether its parameters have changed. A successful TCP test followed by a timed-out request can still indicate mismatched authentication, transport, or security settings. Connection refused, DNS resolution failure, and request timeout are different errors in the log; troubleshoot each according to its type.

A connected status usually means only that the local proxy or VPN interface has started; it does not prove that the server or destination websites are reachable. Test the current server with the client's connection test, then confirm that your browser is actually using the local proxy. If the log shows a DNS resolution failure, check that the DNS server is reachable and that DNS requests are not being sent through a proxy chain that is not yet working. If only some domains fail, check routing rule order and the selected outbound. Restore simple rules for comparison and keep a backup of your original configuration. Do not change DNS, protocol, and routing at the same time, or it will be hard to tell which change helped.

In v2rayN, confirm that automatic system proxy configuration is enabled and check the current HTTP and SOCKS listening ports. A browser may use the system settings, or an extension or separate proxy setting may override them. Terminal tools often use their own configuration or proxy environment variables instead. You can temporarily run curl --proxy http://127.0.0.1:10809 https://example.com to test the HTTP proxy path; replace the port with the actual value. If an explicitly configured proxy works but ordinary commands do not, set the environment variables for the relevant terminal tools. Keep local proxy issues separate from timeouts on the remote server.