V2Ray FAQs
Subscriptions, Proxies & TUN

First, distinguish the core from the graphical client. V2Ray is part of the Project V ecosystem, with related cores maintained by V2Fly. Xray is a separate core branch; its protocol and transport capabilities evolve with each release. v2rayN provides a desktop interface for managing subscription groups, servers and routing, and runs connections using the selected core. To determine whether a configuration will work, check both whether the client can parse the link and whether the core supports its configuration fields. A client’s name alone does not guarantee support for REALITY or any particular transport.

A client reads configuration and establishes connections; installing it does not automatically provide usable servers. A subscription URL is the entry point for retrieving a set of server configurations. It is usually provided by your configuration provider and may include an account identifier. Save the URL in a subscription group, then update the subscription. If you have only added the URL but not updated it, the server list may still be empty. Check that the service is active and the subscription has not expired before changing client settings. Never post the full URL in a public forum. When sharing screenshots for troubleshooting, hide query parameters and personal identifiers.

A subscription URL typically retrieves multiple configurations over the network and is managed through a subscription group. A single-server share link describes one server configuration; common prefixes include vmess://, vless:// and trojan://. Don’t identify a link by the appearance of its QR code—check the decoded content instead. Add individual links through an option such as importing from the clipboard; save subscription URLs in a subscription group. Manually imported servers may not change when a subscription is updated. If your provider changes a port or authentication parameter, reimport the link or check the relevant fields.

No. The system proxy provides a local proxy endpoint for apps that follow system settings. Global routing determines which outbound route requests entering the core usually take. TUN uses a virtual network interface to capture eligible traffic. Enabling global routing does not automatically send apps that ignore the system proxy into the core, and enabling TUN does not mean every route will use the proxy. First check how app traffic reaches the client, then inspect its outbound route. For an initial test, enable only one traffic-capture method to avoid conflicts with other network tools or entry points.

Check your device’s processor architecture rather than relying only on its Android version. Most newer phones use the arm64 package, which is generally smaller than the universal package. If you’re unsure of the architecture or installation reports an incompatibility, try universal; it is still subject to requirements such as the minimum Android version. Desktop downloads must also match your device architecture: Apple Silicon and Intel installers are not interchangeable. Before upgrading, keep your subscription URL and essential settings, then choose the right platform in the download center. Don’t install files from unknown sources to work around an architecture issue.

First, make sure you copied the complete subscription URL. Remove any leading or trailing spaces, line breaks or text added by a messaging app. Open the subscription group settings, enter the URL in the available Url field, make sure the group is enabled, and update the subscription. If parsing fails, the response may be a login page, an error message or an unsupported subscription format. Ask your provider which format your client supports. If the update reports success but no servers appear, clear the group filters and filter regex, then check again. Don’t hide the original error by repeatedly creating groups with the same name.

First, try updating all subscriptions without a proxy on your current network, and note any network errors or HTTP status codes in the log. If the URL can only be reached through a working proxy, try updating all subscriptions through the proxy—but only if the active server and local proxy are actually working. Don’t rely on a failed server to update the subscription that uses it. Authentication failures, expired URLs and error responses from the server usually won’t be fixed by switching update methods. Check the URL, service status and response format one at a time. Hide subscription parameters before sharing logs.

First, make sure the core is running and a local listening port is open. Then check that the system proxy address and port match the client settings. Next, check whether the browser uses its own proxy settings, extension rules or direct-connection exceptions; some apps don’t use the system proxy at all. Fully quit and reopen the browser, then compare a request to the same test URL with the client log. If another network tool keeps changing the system proxy, quit the conflicting tool before setting it again. The system proxy provides an entry point; routing rules in the core determine whether traffic is proxied.

Turn off TUN first, then check the log to see whether the failure involves permissions, virtual interface creation or adding routes. Windows usually requires administrator privileges. On macOS and Linux, follow the authorization or service setup instructions for your client version; not every error is a permissions issue. On Android, confirm system VPN permission on the first connection and check whether another app is already using the VPN connection. If it still fails after authorization, check that all required components are installed and review security software logs for blocked actions. Temporarily use the system proxy to test the server and avoid mistaking a permissions issue for an invalid subscription.

TCPing mainly checks whether a TCP connection can be established to the server port. It doesn’t prove that authentication, the transport handshake or the target request will succeed. Real connection latency sends an actual request to a test address through the server, making it more representative of the connection path, but it also depends on the test address being reachable, routing and network load. Make sure the test address and settings are consistent before comparing servers. Don’t treat one low result as a reliable measure of sustained speed. If TCPing works but real connection latency fails, check protocol parameters, the TLS handshake and the test target—not just the server port.

Switch to the relevant subscription group, check the update result, then confirm the active server in the server list. An update may change server names, addresses or ordering, so the old row position is not a reliable way to identify a server. Select the server you want and set it as active. Check the log to see whether the configuration has reloaded; if needed, stop and restart the connection. Don’t manually edit a subscription server and expect the changes to last, as a later update may overwrite those fields. To keep custom parameters, save a separate configuration and keep track of who maintains it.

Choose a test domain and check whether it matches the expected rule and whether the rule’s outbound tag exists. Routing rules are usually evaluated in order, so a broad rule near the top can prevent more specific rules below it from matching. The domain strategies AsIs, IPIfNonMatch and IPOnDemand affect whether DNS resolution occurs during matching and how IP-based rules are evaluated. Check the destination and outbound in the logs; don’t rely only on whether a page loads in your browser. Reload the configuration after making changes and test with a new request, since existing long-lived connections may continue using their original route.

Before enabling the proxy, note the exit IP shown by a test page. Then enable the proxy, visit the same page and compare the request and outbound route in the client log. The test destination must match a rule that should use the proxy; otherwise, an unchanged exit IP may simply mean the connection is correctly going direct. A browser test shows only that browser’s request path—it doesn’t prove that all apps are being captured. If the results don’t match expectations, check the system proxy, app-specific proxy settings, routing and TUN status one by one. Retest in a new tab or connection after changing settings to avoid interference from cached results or existing connections.

Save the current error details, then test another known-working server on the same network to distinguish a single-server issue from a broader connection problem. If only one server fails, check its address, port, authentication parameters and service status. If all servers fail, check your local network, DNS, firewall and active core. Testing the port before running a real connection latency test can narrow down the issue, but an open port does not guarantee the protocol will work. Don’t change the port, transport and security settings all at once. Change one thing at a time and retest so you can tell what helped, and keep a recoverable copy of the original configuration.

Turn off the system proxy and TUN first, then confirm your regular network can reach sites that were accessible before. Fix any underlying network issue before troubleshooting the proxy. Next, start the core and check for startup or listening errors, then run a real connection latency test on the active server. If the test succeeds, enable only one traffic-capture method and check whether app requests appear in the log. If requests reach the core but the destination is unavailable, check routing, DNS and the destination site. A connection icon often indicates only that the client is running, not that every request succeeds. Don’t delete all your settings up front; reproduce the issue with a minimal configuration first.

First, determine whether the error occurs during startup or while connecting. If the core fails to start, check the earliest error line for a port conflict, invalid JSON, an unknown field or a protocol unsupported by the selected core. Don’t rely only on the final exit message. For TLS or x509 errors during a connection, sync your system date and time zone, then check the SNI, certificate domain and security parameters required by your provider. Don’t treat disabling certificate verification as a standard fix. If you need to share logs, include only the relevant time range, hide addresses, user identifiers and subscription parameters, and keep the error keywords visible.