V2Ray Troubleshooting FAQ

First, distinguish cores from graphical clients. V2Ray is part of the Project V ecosystem, and V2Fly continues related core development. Xray is a separate core fork; their features and configuration details are not identical. v2rayN is a desktop client for managing subscriptions, selecting servers, routing traffic, and launching a core. v2rayNG is primarily for Android and uses the Xray core; v2flyNG is an alternative that uses the V2Fly core. Before importing a configuration, check that both the client and the core it runs support it. A graphical interface does not mean every included core supports every protocol combination.

A client reads configuration and establishes connections; installing it does not provide access to a remote service. You need a subscription URL, a single-server share link, or complete connection details from a service provider that you are authorized to use. Subscriptions are generally for importing and updating multiple servers, while a single-server link describes one connection; they are not interchangeable import options. This site provides client downloads and usage guides, not server accounts. If the server list is empty, check whether you imported a configuration. If servers are listed but all fail, check the service status, connection details, and local network instead of repeatedly reinstalling the client.

Changing only the protocol name in the client is not enough. VMess, VLESS, Trojan, and other connection types must match the server configuration, including authentication, transport, and TLS settings. REALITY is a transport security mechanism, not a standalone replacement at the same level as these protocols; it is commonly used in specific VLESS configurations. If the server requires REALITY, also check fields such as the public key, short ID, server name, and flow control, and confirm that the core supports them. If the combination is unsupported, update to a compatible client and core or ask the service provider for a compatible configuration. Don’t troubleshoot by guessing at settings one by one.

First, make sure you copied the complete subscription URL, including all query parameters, with no extra spaces or line breaks. In v2rayN, you typically need to open the subscription group settings, save the URL, and then update that group. In v2rayNG, add the URL in the subscription group settings and then update the subscription. Saving the URL without updating it won’t create a server list. If the input is a single-server link starting with vmess:// or vless://, use the clipboard import option instead. If the list is still empty after updating, check that you selected the right group and haven’t enabled a list filter. Then check whether the response is a login page, error page, or unsupported subscription format.

Keep the existing group and any working configurations so a temporary update problem doesn’t leave you without a way to connect. Check the update error: a parse failure usually means the response format needs checking; a timeout calls for checking your network and the route used for the update; an authentication failure may mean the subscription has expired or its URL has changed. If the client offers an option to update through the proxy, try it only when the existing proxy works. If the proxy itself is down, updating directly may be a better option. Change one condition at a time and retry. Don’t post your full subscription URL in public forums; its access credentials may let others view your service configuration.

If you’ve confirmed that your system supports 64-bit ARM apps, choose arm64. If you’re unsure of your device architecture or need a package for a range of devices, choose universal. Most recent phones support arm64, but 64-bit hardware doesn’t guarantee that the installed OS provides a 64-bit app environment, so check older devices and custom ROMs carefully. If installation reports an incompatibility, check the OS version and app architecture requirements rather than trying packages from unknown sources. Universal packages are usually larger and don’t improve connection speeds. Switching to a package signed by a different source may also cause a signature conflict, so back up any needed configuration before uninstalling.

TUN creates a virtual network interface and changes some network routes, so it usually needs more permissions than the system proxy. On desktop, close the client first, then relaunch it with elevated permissions as required by your OS, or complete the client’s service installation process. The exact steps vary by version. On Android, this usually involves granting the system VPN permission: review and approve the connection request, and check whether another app is already using the VPN connection. If it still fails, look in the logs for errors involving the virtual interface, route creation, or ports in use. Don’t disable your security protections to bypass the prompt. While troubleshooting, turn off TUN, verify that a basic proxy connection works, and then address the permissions needed to route traffic.

The system proxy provides an entry point for apps that follow the system proxy settings, but not all apps do. TUN routes traffic covered by its configuration through a virtual network interface. It usually covers more traffic, but makes routing and DNS issues more complex to troubleshoot. If you’re new to the client, first use the system proxy to confirm that the connection works, then try TUN if your apps need it rather than enabling multiple options at once. How clients handle both modes together varies; follow the documentation for your version. If you see connection loops or traffic being intercepted twice, use just one mode and check whether other proxy tools, browser extensions, or app-level proxy settings are still active.

For everyday use, start with the client’s rule-based routing so matching requests go through the proxy or connect directly as appropriate. Global proxy can help you check whether a problem is caused by routing rules, but it usually only changes routing decisions for traffic that reaches the client; it doesn’t guarantee that every app’s traffic is being captured. Note the original mode before switching, test the same site, and check the logs to see which route was used. Don’t change routing, DNS, and the core at the same time, or it will be difficult to tell what made a difference. If only one domain takes the wrong route, check its matching rule and rule order rather than changing how all traffic is handled permanently.

The same subscription may work on both a desktop client and an Android client, provided the service allows those devices and the target clients support the protocols and subscription format. Import the subscription separately on each device instead of copying the entire program folder as a universal configuration. Local ports, system proxy, TUN, file paths, and routing rules vary by platform and need to be checked separately. After importing, confirm that the protocol, transport, and security settings are intact. Updating a subscription doesn’t sync all local settings. If one device connects and the other doesn’t, compare core versions and import results first rather than assuming the subscription is invalid.

First, turn off the proxy and confirm that your local network works. Then check that the service is active and that the server address and port are complete. Next, distinguish between an unreachable TCP connection and a failed proxy handshake: for the former, check the network route, destination port, and whether the server is listening; for the latter, check authentication, TLS, server name, and protocol settings. Compare against a known-working configuration or test on another local network to narrow down the cause. Check relevant logs when the problem occurs, noting the error type and time; hide addresses and credentials before sharing them. Increasing the timeout won’t fix incorrect settings. Before switching cores repeatedly, confirm that the current configuration is compatible with the core.

The system proxy is a setting that apps can choose to follow; it doesn’t force all network connections through the proxy. First, verify the connection in a browser that follows the system proxy. If the browser works but a particular app doesn’t, check whether that app has its own proxy settings or defaults to a direct connection. When entering proxy settings manually, check the protocol, listening address, and port. Don’t mix up HTTP and SOCKS endpoints or copy port numbers from another client. Once the basic connection works, consider TUN if you need to route traffic from all apps. If no apps work, check that the client’s local listener is running, that its port isn’t in use, and that another program hasn’t overridden the system proxy.

First, check whether the system still points to a local proxy port that is no longer running. Reopen the client, clear the system proxy or restore the original settings, and then exit normally. You can also remove any leftover manual proxy settings in your system network settings. If you were using TUN, turn it off and check that the virtual interface has stopped. On Android, also check whether Always-on VPN or blocking connections without a VPN is enabled in the system VPN settings. Reconnect to your current network and test basic access. Don’t start by resetting all network settings, especially on devices with work network settings or custom DNS. Record the original values first so you don’t lose settings needed for normal use.