V2Ray FAQ
Setup & Connection Troubleshooting

V2Ray is part of the Project V ecosystem, and V2Fly continues development of the related core. Xray follows a separate core development path. The core handles protocol connections, routing and DNS, while v2rayN provides a desktop GUI for managing these settings. On Android, v2rayNG commonly uses the Xray core, while v2flyNG uses the v2fly core. A client’s ability to import a link does not mean its current core supports every parameter in it. When choosing a setup, check the protocol, transport, security layer and core version.

The client reads configuration and establishes a connection; installing it does not generate usable server details. You’ll need a subscription URL, share link or complete server configuration that you’re authorized to use. When entering details manually, the server address, port, user ID or password, TLS settings and transport options must match the server. First make sure the device has basic network access, then test with a configuration from a trusted source. Installing the client successfully does not mean the server connection is working.

System proxy settings direct requests from apps that honor them to the client; apps that ignore these settings may connect directly. TUN routes traffic through a virtual network interface, typically covering more traffic, but depends on system permissions, routing and DNS configuration. Routing rules determine whether traffic that reaches the core is proxied, sent directly or blocked. These operate at different stages. When troubleshooting, first check whether app traffic reaches the client, then inspect the routing decision. Enabling TUN alone does not guarantee that all requests will use the proxy.

Choose the type provided by the server; changing a protocol name in the client does not convert the connection. VLESS, VMess and Trojan use different authentication fields and security settings. REALITY is generally a security-layer configuration used with protocols such as VLESS, not a protocol name you can swap in at will. Also check TLS, transport options and core support. There is no fixed speed ranking that applies to every deployment. Start with a combination the server explicitly supports, with complete parameters and a compatible client core, then judge it by actual connection performance.

First identify what you’re importing. Share links commonly start with vmess://, vless://, trojan:// or ss://; subscription URLs are usually HTTPS addresses. Remove any copied explanatory text, line breaks or extra spaces, then use the appropriate clipboard import option or subscription group. If the client reports an unsupported format, check whether the client and core support that transport configuration. A webpage URL, login page or native JSON file is not necessarily a share link. JSON files with complex outbounds or routing rules may not convert to a single node.

Most newer Android phones can use arm64, but check the ABI supported by the device’s system rather than relying on the processor’s advertised model. A universal package usually includes multiple architectures and is larger, making it a suitable choice if you’re unsure; check the specific release for the architectures it contains. If installation fails or reports incompatibility, check the Android version, make sure the package downloaded completely, and confirm that the app’s signature matches the installed version. Back up your configuration before switching clients, and don’t uninstall the only copy of a configuration you can use.

In v2rayN, select the server you want to use and make sure the core starts successfully. Then configure the system proxy or enable TUN as needed; selecting a row in the list does not mean app traffic is being routed through the client. On Android, start the service and approve the system connection prompt when using VPN mode. Test with an actual browser and check the logs to confirm that requests reach the core and which outbound they use. A connection indicator or latency result only reflects part of the process; it does not by itself prove that the browser, DNS and destination website are all working.

On desktop, check the logs for the specific failure: creating a virtual interface, adding a route and binding a port require different fixes. On Windows, run with administrator privileges if the client requires it. On macOS and Linux, follow the instructions for your version to grant system permissions or install the required helper; don’t loosen permissions across the board. Android VPN authorization works differently from desktop TUN permissions, and you may need to stop other apps using the VPN interface. Restart the service after granting permission, and check that an old virtual interface or another network tool hasn’t taken over the system routes.

Keep subscription content and manual configurations in separate groups, and check which subscription group you’re updating before you proceed. A refresh may rebuild or change the group’s nodes based on remote content, so don’t rely on edits made directly to subscription nodes if you need to keep them. To make changes, copy a node into a separate configuration and edit that copy; if credentials change, make sure they also match the server. Regularly export or back up configurations using the client’s built-in tools, and store the files securely. Subscription URLs and exported configurations may contain access credentials, so don’t share them publicly as screenshots or attachments.

Start with the client’s built-in routing profile, then add custom rules one at a time rather than replacing the entire configuration. Check rule order, domain strategy and the default outbound. For example, geosite:category-ads-all → block blocks domains in that set, provided the selected core and rule resources support this syntax. Rule formats are not interchangeable across cores. After making a change, test destinations that should connect directly and those that should use the proxy, and review the logs. IPIfNonMatch controls how domains are resolved when they don’t match a rule; it does not force all domains through the proxy.

First determine whether the system is stopping the service or the service is still running but the connection has failed. If the system is stopping it, check battery optimization, background activity permissions and the manufacturer’s app-sleep settings; allow the client to run in the background where needed. If the service remains active, check network changes, subscription settings and core logs. To investigate battery use, look for long-running transfers, repeated reconnects and unnecessary background requests; use per-app proxying to limit which traffic is routed if needed. VPN mode does not automatically mean abnormal battery drain, and disabling battery restrictions for every app to keep the client alive is not recommended. Change one setting at a time and see whether it helps.

Subscription URLs may contain access tokens, and share links or QR codes may include full connection credentials. Before sharing troubleshooting materials, redact sensitive parts of subscription paths, user IDs, passwords, private server addresses and any access domains in logs you don’t want to disclose. Include the client name, exact version, operating system, original error message and time of the issue; these details usually help identify the cause. Don’t publish a full configuration just to provide context. Instead, describe the redacted fields, including the protocol, transport and security layer, and note any settings you recently changed.

First confirm that the device has basic network access. Then check whether the server address resolves, the port is correct, the subscription is current and the server is still running. A client’s TCP test is not the same as a real proxy request: an open port doesn’t confirm protocol authentication, and a single timeout doesn’t prove the configuration is invalid. Retest the same configuration on another network and review authentication, TLS or transport-related logs. If only one configuration fails, check that configuration first. If all configurations fail, look for local proxy conflicts, DNS issues and problems with the current network.

First check whether the client logs a request when you try to browse. If there’s no log entry, check whether the system proxy is enabled, whether the browser has its own proxy settings, and whether per-app rules exclude it. If a request is logged but fails, distinguish between DNS resolution, an incorrect routing outbound and a failed remote connection. If only domain names fail, focus on DNS, but don’t treat connecting directly to an HTTPS site’s IP as a general-purpose test. Temporarily switch back to a known working configuration and test one setting at a time; changing DNS, routing and transport options together makes the cause harder to identify.

Check the client settings for the actual local listening ports, then make sure the address and ports configured in the system proxy match. Some configurations use SOCKS on 10808 and HTTP on 10809, but these are not fixed values across all versions or setups; use the current client interface and logs as your source of truth. Browser extensions, other proxy software or enterprise policies may override system settings. Apps that ignore the system proxy need to be configured separately or routed through an appropriate TUN setup. Exit other proxy tools, reapply the system proxy settings and check whether the ports are in use. Changing nodes repeatedly won’t fix a local traffic-routing issue.

For a failed subscription update, first check that the URL is complete, the access token is valid, and the response hasn’t turned into a login or error page. Handle connection timeouts separately from invalid response formats. If updates use a proxy, make sure that proxy is working first; if needed, try another update method supported by the client. For a TLS handshake error, check the system clock, certificate validity, SNI and server requirements. Don’t confuse the subscription domain with the node’s serverName. Avoid leaving allowInsecure enabled to bypass certificate checks. Correct the time, domain or server certificate, then test again.