V2Ray FAQ

V2Ray generally refers to proxy tools and related implementations in the Project V ecosystem. Clients manage subscriptions, edit configurations and integrate with the operating system; cores handle protocols, connections and routing. v2rayN is a desktop client, while v2rayNG and v2flyNG are Android clients that primarily use the Xray and V2Fly cores, respectively. When checking protocol support, verify the bundled core version and its support for the transport and security layer you need. A client’s name alone doesn’t tell you whether a configuration will work.

V2Ray Select is a client download hub and technical reference, not the official site for Project V, V2Fly or Xray, and it does not provide connection services. Installing a client only prepares the software; you still need an authorized server configuration, a single share link or a subscription URL to connect. Open-source client licensing is separate from how connection services are priced. For account, subscription expiry or server issues, contact the configuration provider. Our Getting Started guides focus on GUI setup and troubleshooting.

Links beginning with vmess://, vless:// and similar schemes usually contain a single configuration. Importing one saves it locally; it won’t automatically reflect changes made by the provider. A subscription URL is typically a web address that the client fetches to retrieve a set of configurations, which can then be refreshed by updating the subscription. A regular webpage URL isn’t necessarily a subscription URL, and a login page may not be importable. Both types of link can contain credentials, so keep them private and never share the full URL in screenshots or support requests.

Check which app architectures your device’s processor and operating system support. If it supports arm64, choose the arm64 package; most mainstream phones released after 2015 fall into this category, but a phone’s purchase date doesn’t confirm its architecture. The universal package includes multiple architectures and is useful when you’re unsure, though it’s usually larger. If installation fails, check the minimum OS requirement, available storage and whether the signing certificate matches the installed app. Don’t keep swapping packages to fix a signature conflict. Back up your subscription and essential settings before changing sources or uninstalling the app.

Make sure you copied the full subscription URL—not a management page, instructions or a single share link—and remove any spaces or line breaks at either end. Save the URL in the client’s subscription manager, then run an update; adding a subscription group alone may not fetch configurations. If the list is still empty, check the logs to see whether the request failed, the response couldn’t be parsed or the configurations were filtered out. The subscription may return a webpage, login prompt or unsupported format; ask the provider which formats the client supports. Don’t submit a private subscription URL to an unfamiliar online converter.

Keep the existing configuration and note the update log and time of failure; there’s no need to delete the subscription right away. Check your network and system clock, whether the URL changed, and whether the subscription expired or was disabled by the provider. Some clients let you update through a proxy. If the current proxy route is unavailable, try a direct update; if you already have a working connection, try updating through it instead. If the response is a login page or access-denied message, check your account status. Once the update succeeds, verify the list before clearing any local configurations that still work.

On desktop, start by selecting a configuration and launching the core, then enable the system proxy and test with a browser that follows system proxy settings. This helps you check separately whether the core connects, the app uses the proxy and the routing rules match. TUN captures a wider range of network traffic but also involves a virtual adapter, routes and DNS, so it’s best not to troubleshoot it at the same time as your first import. Android clients typically capture traffic through the system VPN interface, which works differently from a desktop system proxy. Follow the client’s authorization prompts and check its app-routing settings.

Check the logs first to see whether the error concerns permissions, virtual adapter creation or routing. Desktop TUN usually requires elevated privileges or a service configured as described by the client. On Windows, follow the prompt to run with administrator privileges; on macOS and Linux, grant the required system authorization or configure permissions for your version. Don’t blindly change system directory permissions just to clear an error. If another VPN, virtual adapter tool or security app is running, pause the conflicting software and test again. After exiting TUN, confirm that system routes and DNS settings have been restored before enabling it again.

For everyday use, start with the client’s rule-based mode to send selected domains or addresses through a direct, proxy or blocked route. geosite generally matches domain groups, while geoip matches IP address groups. Results also depend on rule order, DNS resolution strategy and the version of the rule data. Global mode can help determine whether routing rules are causing an issue, but it doesn’t mean all app traffic is being captured. Save your current settings before editing rules, change one condition at a time and retest the target site. Avoid changing the mode, DNS and core together, or it may be hard to identify the cause.

Before switching, check that your client provides the target core and that it supports the protocol, transport and security layer used by your configuration. Xray and V2Fly share roots in the same ecosystem, but their features and configuration fields don’t always match. Don’t assume configurations using features such as REALITY can be migrated directly. REALITY is a security-layer mechanism, not a standalone proxy protocol alongside VMess. Back up your configuration, test one compatible configuration, and switch the rest only after confirming that connections and routing work. If the test fails, restore the original core.

Keep the client’s default DNS setup initially, then adjust it based on how traffic is actually captured. System proxy, an app’s encrypted DNS and TUN may handle DNS through different paths. If a browser works but other apps don’t, check whether they use the same resolver. Changing the DNS address to a public resolver alone doesn’t prove the issue is fixed: check that DNS requests can reach it, that the returned addresses are expected and that domain rules still match. Reconnect after making changes, and clear the affected app’s DNS cache if needed before testing again.

A full subscription URL, share link, QR code, user ID or authentication details may let someone else use the same connection. Redact them before sharing. For troubleshooting, the client name, app and core versions, operating system, protocol and relevant error log are usually enough; don’t upload the full configuration. When moving to another device, use a trusted private transfer method, then check that subscription groups and routing settings were restored. If credentials have been exposed, deleting the screenshot won’t revoke access. Contact the provider to replace the credentials or subscription URL.

A timeout only means the test didn’t finish within its time limit. Possible causes include your local network, DNS, destination address, port, server status or the test method itself. Check your regular internet connection, verify the system clock and configuration fields, try accessing a target site with the same configuration, and review the core logs. Some clients only test the port; others make an actual request, so their results aren’t directly comparable. If every configuration fails, check your local environment first. If only one fails, ask the provider to confirm the address, port and server status.

A connected status usually means the local core or system VPN interface is running; it doesn’t confirm that requests are reaching their destination. Make sure an active configuration is selected, then check whether the logs show connections when you visit a webpage. If there are no request entries, check the app’s proxy settings, app-routing rules and which traffic is being captured. If requests appear but fail, investigate DNS, the remote connection and the routing exit. You can temporarily test a known working configuration or switch modes for comparison, but change only one thing at a time. If just one site fails, check for an outage, browser cache issues or a problem with your login session.

A system proxy isn’t a traffic switch that forcibly applies to every process. Some apps use their own network settings, terminal programs may need proxy environment variables, and browser extensions can override system settings. Check the local listening address and port shown by the client, then confirm that the target app uses the system proxy or has the matching proxy type configured. Don’t mix up HTTP and SOCKS ports. If you need to capture traffic from apps that ignore the system proxy, consider TUN. If only one app is affected, check its settings first rather than making broader system changes.

Check whether the system restricts the client’s background activity, auto-start or battery use, and allow the background operation it needs in your device settings. Then check whether another app is using the system VPN interface. A typical personal setup can have only one active VPN connection, so starting another app may replace the current one. If disconnections happen only when switching between Wi-Fi and mobile data, check the logs and try reconnecting; also verify that the configuration still works. Don’t rely on the notification icon alone to confirm a connection. After unlocking, test with an actual request and note the conditions that caused the disconnect.