V2Ray FAQ
Configuration and connection troubleshooting

Project V provides the ecosystem background for related proxy tools, while V2Fly and Xray are separate core projects. The core handles protocol connections, routing, and traffic forwarding; graphical clients provide subscription management, server selection, and settings. On desktop, you can use v2rayN. On Android, options include v2rayNG with Xray or v2flyNG with the V2Fly core. Protocol support depends on the core actually running and its version, not just the client name. If you run into compatibility issues, note the client and core versions first, then check the features required by the server.

The client provides a local proxy interface and an environment for running the core; server configurations must be imported separately. A subscription URL typically returns a set of configurations, while a share link usually describes a single one. Import each through the appropriate option. After installation, get a subscription URL or share link you’re authorized to use, then import it and select a server. An empty list does not mean installation failed, and enabling the system proxy will not create servers. Don’t include subscription URLs in public screenshots or support requests; they may contain credentials that grant direct access to your subscription.

The system proxy directs requests from apps that follow system proxy settings to a local listening port; it does not necessarily capture every app. Routing mode handles traffic that has already entered the core and decides whether to proxy, connect directly, or block it. TUN receives eligible traffic through a virtual network interface and involves routing, DNS, and permission settings. These controls operate at different layers. To troubleshoot, first confirm that app traffic reaches the client, then check which route matched, and finally inspect the outbound connection. Enabling the system proxy does not mean all traffic is being proxied.

Not necessarily. A TCP test mainly checks whether a connection can be established to the target address and port; it does not fully verify authentication, transport settings, or web access. A real connection test is closer to an actual request, but results still depend on the test target, DNS, current routing, and network conditions. To check whether a server works, select it, try accessing a site through a real app, and review the client logs from the same time. Don’t assume the lowest latency means a working connection. If the test passes but websites don’t load, check the app’s proxy settings and DNS first, then verify the server parameters.

Make sure you copied the complete share link, including a prefix such as vmess://, vless://, trojan://, or ss://, rather than a webpage or subscription URL. Remove leading or trailing spaces, extra text added by a messaging app, and inserted line breaks, then use the clipboard import option. If it still fails, check the import message to distinguish an invalid format from an unsupported protocol. Don’t modify encoded data, authentication fields, or transport settings just to force an import. Get the original link again and check whether your client and core support that configuration.

In v2rayN, add a group in the subscription group settings, enter a recognizable name and the full subscription URL, save it, then update that group. On Android, save the subscription and run an update; adding only a group name is not enough. Adding a URL does not mean configurations have been retrieved. After the update, check the status message, group filter, and server list. If the response is a login page, error page, or regular webpage, the client cannot generate usable configurations. Check whether the URL has expired and whether the response uses a subscription format supported by the client.

Most mainstream Android phones released since 2015 are likely to use arm64, but check which app architecture your device actually supports. A universal package includes components for multiple architectures and is usually larger; it’s a good option if you’re unsure of your device’s architecture. It does not add protocol support. If arm64 is reported as incompatible, check your Android version and device architecture before trying the universal build. When updating an existing client, use the same app source and signing identity. Don’t uninstall the app to work around an update error; back up important settings first to avoid losing subscription groups and manually added servers.

On desktop, check the logs to see whether the failure occurred while requesting permission, creating the virtual interface, or setting up routes. Grant the permissions required by your client, using the operating system’s authorization flow if elevated privileges are needed. On Android, the first connection usually requires approval of the system VPN request; also check whether another app is using that connection. Avoid repeatedly toggling multiple traffic-capture tools. Disable conflicts, confirm a regular proxy connection works, then enable TUN on its own. If it still fails after authorization, check the virtual interface, service components, and routing errors rather than switching servers again.

If you mainly use browsers that follow system proxy settings, start by enabling automatic system proxy configuration, then choose routing rules that suit your needs, such as bypassing mainland China. To check whether routing affects a particular destination, temporarily switch to rules that send more traffic through the proxy, compare results, then restore your original settings. Mode names can vary by version, so check the actual rules. “Global” usually refers to routing choices for traffic that has entered the core; it does not mean every app is automatically captured. For apps that ignore system proxy settings, configure the local proxy address in the app or use TUN after checking compatibility.

Open the client’s settings and check the current HTTP, SOCKS, or mixed listening port. In the app, select the matching proxy type and usually enter 127.0.0.1 as the address. Don’t enter the server’s remote port as the local port, and don’t assume every version uses the same default. After changing the listening port, make sure the core reloads successfully and update the app’s settings to match. If the proxy is only for local use, leave LAN access disabled. If other devices need to connect, check the listening address, firewall, and access controls to avoid exposing the proxy to an untrusted network.

Subscription servers are usually managed remotely and may be replaced, removed, or recreated during an update, so manual edits may not persist. Save custom configurations you need to keep in a separate group, if your client supports it, and note why you changed them. Check which groups an update will affect to avoid changing the wrong one. If a parameter keeps reverting, don’t keep editing the subscription entry. Check for a local override option in the client or ask the configuration provider to confirm the original parameter. Backups may also contain subscription credentials, so store them securely.

First confirm that the request has entered the core, then check the active routing configuration rather than just the rules in the editor. Rules are usually matched in order, so a broad rule near the top may prevent a more specific rule below it from running. Send a request to a single destination and use the logs to check the target, matched rule, and outbound route; the available details depend on the core and log level. Also check that rule resources are available and domain handling matches your expectations. Change one setting at a time and note its original value. After testing, disable unnecessary debug logging to avoid accumulating files that contain browsing activity.

Check that the subscription URL is complete and hasn’t expired, and verify the device’s clock before reviewing the update logs. Timeouts, certificate errors, authentication failures, and content parsing errors have different causes. If the current proxy isn’t working, updating through it may fail too. If the client offers the option, try a direct update; if the subscription URL isn’t reachable directly, you’ll need another working connection path. Don’t repeatedly paste the same URL into third-party conversion sites. If the server returned content but parsing failed, check the response format instead of changing the local listening port.

First make sure your local network can reach common sites directly, then check the device’s clock, server address, port, and configuration validity. Treat TCP tests and real connection tests separately. If the TCP test fails, check address resolution, the network path, and the remote port. If it passes but the real connection fails, check authentication, TLS, SNI, transport paths, and core compatibility. Test a small number of configurations one at a time on the same network; testing many servers at once can make results harder to interpret. If you need help, note the error type and time. Before sharing logs, hide addresses, subscription details, and authentication information.

“Connected” may only mean the local core or VPN interface has started; it doesn’t mean requests are reaching the remote destination. First check whether a connection appears in the logs when the app makes a request. If there’s no entry, check the system proxy, the app’s own proxy settings, or whether TUN is capturing its traffic. If there is an entry, determine whether the issue is DNS, a connection timeout, authentication, or an incorrect route. If only certain domains fail, check their DNS resolution and routing rules rather than reinstalling the client. Temporarily disable other proxy tools and test with one app, changing one setting at a time to pinpoint whether the issue is at the proxy entry, DNS, or remote exit.

Make sure v2rayN is running, the core has started without errors, and the system proxy’s local address and port match the client settings. A browser may use its own proxy or extension settings that override the system configuration, so check those too. If you can’t get online after exiting, open your operating system’s proxy settings and see whether they still point to a local port that is no longer listening. Clear any stale proxy settings and try again. If another app also changes the system proxy, identify which tool is managing it. Before exiting next time, use the client’s option to clear the system proxy. Apps that don’t follow system proxy settings still need to be checked separately.