V2Ray FAQ and Troubleshooting

V2Ray is part of the Project V proxy ecosystem, and V2Fly continues development of related cores; Xray follows a separate development path. v2rayN is a graphical client for managing servers, subscriptions, routing, and local proxies. The selected core handles the actual connection. If a configuration field or protocol is not recognized, check which core the client is using and its version rather than relying on the client name shown in the window. JSON configurations from different cores should not be mixed without review, especially their transport, security, and routing fields.

Use v2rayN on Windows, macOS, and Linux desktops. On Android, v2rayNG with the Xray core is usually the first choice. Consider v2flyNG if an existing configuration specifically depends on V2Fly behavior. All three clients pass subscription or server settings to a core, but their menus, supported protocols, and advanced options differ. Choose a client for your operating system, then check that it supports your server's protocol and transport. Before switching clients, save your subscription URL and any essential settings. You cannot simply import another app's entire data directory as a configuration.

Installing the client only prepares the local management interface and runtime; it does not provide a working server. You still need to import a subscription URL you are authorized to use, or enter the server address, port, user ID, and required transport settings. A subscription distributes server configurations; it is not the client itself. Its validity and server availability depend on the service provider. Check the configuration source and expiration date before importing it and selecting an active server. Never post a subscription URL containing access credentials in public comments, screenshots, or online conversion tools.

A system proxy directs requests from apps that honor system settings to a local proxy port; some command-line tools and apps ignore it. Routing rules decide whether traffic entering the core is proxied, sent directly, or blocked based on domains, IP addresses, or other criteria. TUN mode captures eligible traffic through a virtual network interface and typically involves system network permissions, routing tables, and DNS. When troubleshooting, first verify the server with a standard local proxy, then enable the system proxy or TUN separately. Changing all three at once makes it difficult to identify the source of a problem.

Most newer Android phones can use the arm64 package. The universal package includes multiple architectures, so it is usually larger and is a good option when you are unsure which architecture your device uses. The phone's age alone is not enough to tell: a processor may support 64-bit while the installed OS or app runtime is still 32-bit. Check the device specifications or a trusted system information page. If the arm64 package reports an architecture mismatch, try the universal package. A signature conflict is a separate issue: check the source and app ID of the installed app, back up your configuration, and then resolve the installation conflict.

Paste the full subscription URL, not the service dashboard, payment page, or a browser page that appears after signing in. In v2rayN, open subscription group settings, add a group, save the URL, and then update the subscription. In v2rayNG, save the subscription group first and then update that group. Check for leading or trailing spaces, line breaks, and truncated query parameters. If the log shows an HTML response, you probably received a sign-in or error page; get the correct URL from the provider. Don't repeatedly change the encoding to work around a bad URL, and never share a full link containing access credentials.

First check your distribution's package format: Debian, Ubuntu, and derivatives generally use deb packages, while Fedora and other RPM-based distributions generally use rpm. Then run uname -m to check the architecture: x86_64 corresponds to x64, and aarch64 usually corresponds to arm64. Package format and CPU architecture are separate requirements, and both must match. Install with your distribution's software installer or package manager so dependencies are handled properly. If a dependency is missing, check the specific package name. Don't force the installation while ignoring dependencies, and don't run the entire desktop client as root for routine use.

Turn off TUN first and confirm that a standard local proxy connects successfully, then address system permissions. Linux needs an available TUN device and permission to create a virtual interface and modify routes. Follow the guidance for your current v2rayN version and distribution; don't grant elevated privileges to software you don't trust. On Windows, approve the requested operation as prompted by the client. On macOS, check the relevant network or VPN permission in System Settings. On Android, approve the system VPN request; typically, another app already using the VPN connection must be stopped. After granting permission, restart the connection and check the log for the specific operation that failed.

Update the subscription, choose a server that supports the protocol used by your current core, and run the client's real connection test to check the handshake. Don't choose based on the server name or region alone. Latency tests and real connection tests may use different paths, and neither result by itself proves that a site will load. Set the server as active, enable the required proxy entry, visit a specific HTTPS URL, and check the log for the corresponding request. Keep routing settings unchanged during the initial test, and avoid switching servers and DNS settings repeatedly. Establish a reproducible working setup before comparing other configurations.

Terminal programs may not use the desktop system proxy. Check the client's local HTTP or mixed listening port first. If it is 10808, test with an explicit proxy using curl -I -x http://127.0.0.1:10808 https://example.com. If only a SOCKS listener is available, use the matching options; HTTP proxy syntax won't work for it. To use temporary environment variables, set http_proxy and https_proxy in the current terminal and clear them after testing. If an explicit proxy works but plain curl fails, check how the program reads proxy settings instead of immediately switching servers.

Start with the client's routing preset, then add only a few custom rules as needed. Route LAN and private addresses through a direct outbound. Match selected sites by domain rather than using just one IP resolved from the homepage; a site may use multiple subdomains or content delivery addresses. Rules are usually evaluated in order, and behavior depends on the core, so place more specific exceptions appropriately. After saving and applying the rules, check the log to see which outbound was selected. DNS resolution strategy can also affect IP-based matches, so avoid making major DNS and routing changes at the same time.

Use the client's built-in export or backup option when available. If you need to copy the configuration directory, fully exit the client first to avoid copying files that are still being written. Keep at least your subscription groups, manually added servers, custom routing rules, and any DNS settings you need. Backups may contain user IDs, passwords, or subscription credentials, so store them securely. On the new device, restore server details first, then check listening ports, system proxy settings, and TUN permissions; these depend on the system environment and should not be copied blindly. When moving between clients, re-import the subscription rather than overwriting the app's entire data directory.

First check that the subscription URL is complete and the service is still active, then review the update log for the error type. A timeout means the connection did not complete within the allotted time. For a DNS resolution failure, check the current DNS settings. HTTP 401 or 403 errors require you to verify access authorization, whether the URL has expired, and any server-side restrictions. If the client can update through a proxy, make sure that proxy server is working first; relying on a failed proxy to update the subscription can create a loop. Test direct access and an already-working proxy separately, changing one thing at a time. Remove credentials from sensitive links before sharing log details.

First make sure the device itself has a working internet connection. Then check that the server domain, port, protocol, and transport settings match the configuration source. A typo in manually entered fields such as TLS serverName or WebSocket path can cause a handshake failure even when the port is reachable. Use the client log to distinguish DNS failures, connection timeouts, refused connections, and TLS errors; also verify that the system clock is correct. Compare with a known-working configuration or a different network, changing one condition at a time. A single timeout does not prove that the server is down, and disabling certificate verification is not a safe fix.

A running status usually means only that the core process has started; it does not confirm a successful server handshake or website access. First test a request through the explicit local proxy to verify the local port and server connection. Then check whether the browser uses the system proxy, followed by routing and DNS. If the explicit proxy works but the browser does not, check browser extensions, separate proxy settings, and cached connections. If only certain domains fail, review the matching routing rule and DNS logs. If the problem starts only after enabling TUN, turn it off for comparison and check for conflicts with other VPNs or network filtering software. Avoid running multiple traffic-capture tools at once.

Linux proxy settings may come from the desktop environment, an app's own settings, or process environment variables. No single switch ensures every program uses the same route. Check that the system proxy points to the local loopback address and that its port matches the client's HTTP or mixed listener, then test the listener with an explicit proxy request. Check browser-specific proxy settings and extensions separately; apps that were already running may need to be restarted. In the terminal, check for conflicting http_proxy, https_proxy, ALL_PROXY, and NO_PROXY values. For apps that genuinely don't support proxies, consider TUN only after understanding the permission and routing implications.