V2Ray FAQ

V2Ray usually refers to the proxy core and related tools in the Project V ecosystem. V2Fly is a community project continuing V2Ray development, while Xray is a separate core fork. v2rayN, v2rayNG, and v2flyNG provide graphical interfaces for importing configurations, choosing servers, and managing proxy entry points. A client opening successfully does not mean its core is running; check the core startup logs when troubleshooting a connection. Whether a configuration works depends on the core's support for its protocols and specific settings—not just the client name.

For Windows, macOS, and Linux desktops, start with v2rayN, then choose a download based on your processor architecture and package format. Windows offers a desktop edition and a classic WPF edition; macOS downloads differ for Apple Silicon and Intel; on Linux, check both the architecture and your distribution's package format. On Android, v2rayNG with the Xray core is the usual choice; choose v2flyNG if you need a V2Fly core. Check your configuration's protocol and transport requirements before choosing a client to avoid mistaking core differences for a broken subscription.

A client manages connections; it does not include a remote server you can use out of the box. A subscription provides server configurations in one place, while an individual share link usually describes one connection, including its address, port, credentials, and transport settings. After installation, import a configuration you manage or are authorized to use, then select an active server. Subscription URLs often contain access credentials and should be kept private. When asking for help, don't share the full URL, its QR code, or screenshots containing credentials.

They handle different parts of the connection. The system proxy provides a local proxy address to apps that use the system setting. Global routing determines which outbound route traffic takes after entering the core; it does not automatically capture traffic from every app. TUN uses a virtual network interface to receive traffic within its capture scope. Start with the system proxy and default routing to verify the connection, then consider TUN if your apps need it. Enabling everything at once to troubleshoot one webpage makes it harder to tell whether the issue is at the entry point, in the rules, or with the remote connection.

First check whether you're importing a subscription URL or a single share link, and use the corresponding subscription manager or clipboard import option. Remove spaces, line breaks, and chat app notes when copying, and make sure the URL wasn't truncated. After saving a subscription group, update the subscription; if the list is empty, check the group filters and update logs. If the response is a login page, error page, or unsupported configuration format, pasting it again won't help. Check your access permissions or get a subscription format compatible with your client.

Most mainstream Android phones released after 2015 can usually start with arm64, but check the device's processor and the app architectures supported by its system. If you can't confirm the architecture, choose the universal package. It includes files for multiple architectures and is usually larger. If installation fails, check the Android version requirement, available storage, and whether an app with the same name but a different signing key is already installed. Back up your configuration before changing installation sources, and don't uninstall the existing app straight away. Even after installation, confirm compatibility by launching the app and testing a connection.

The Windows desktop edition uses a newer cross-platform interface, while the classic WPF edition suits users who prefer the established workflow. Menus and some features may appear in different places. If you're new to v2rayN, start with the desktop edition from the downloads page. If you already have a stable workflow, choose WPF for compatibility as needed. Don't run both editions at once to manage the system proxy or listen on the same port. Export your configuration before switching and keep the original folder. If startup reports a missing runtime, install the component required by that package instead of repeatedly changing subscriptions.

v2rayNG and v2flyNG use Android's VPN service to create a local traffic entry point, so Android asks for permission when you connect for the first time. Allow it only after confirming the prompt comes from the client you're using; granting permission does not mean the remote server is reachable. If the connection drops immediately afterward, check whether another VPN service is in use and whether Android restricts background activity. On managed devices or devices with work profile policies, an administrator may control these permissions. Don't try to bypass management restrictions by repeatedly reinstalling the client.

The system proxy only works with apps that follow the system proxy settings. Some apps use their own network settings, and existing connections may keep using an old route. First confirm the client core is running and the system proxy address and port match the client's local entry point, then restart the app. If your browser has a separate proxy extension, check whether it overrides the system setting. For apps that don't use the system proxy, try their built-in proxy settings or configure TUN after understanding its capture scope. Changing global routing does not capture traffic by itself.

For everyday use, start with the client's rules or bypass-mainland-China preset, then adjust them to suit your needs. Global mode typically sends traffic that enters the core through a proxy outbound, subject to exceptions in the preset. Bypass-mainland-China mode uses domain and IP rules, plus related rule data, to send matching connections direct. Custom rule mode selects an outbound based on rule order. Mode names and behavior vary between clients, so check the active rules instead of relying on the label. Test with a new connection after switching to avoid misleading results from an existing one.

TUN creates a virtual interface and adjusts routes. If permissions are insufficient, first check the logs to see which operation failed. Windows may require administrator privileges or a service mode provided by the client; on macOS and Linux, follow the client's prompts to grant system permissions. Whether elevated privileges are needed continuously depends on the installation method and service setup. Turn off TUN first and confirm the regular proxy entry works, then investigate permissions and interface conflicts. Check for other VPN or virtual network software, and don't disable system protection altogether.

Create a separate subscription group for each source and give each group a recognizable name. Before updating, check the selected group, filters, and active server so you don't mistake a filtered list for missing entries. Updates may recreate server entries from the source, so don't rely on directly editing subscription entries to keep custom settings. If you need separate changes, copy entries into a local configuration and manage it independently, if your client supports that. Export backups regularly, and check whether local entries will be deleted with a group before removing a subscription.

First make sure the device itself is online. Then check that the core started successfully and that the local port isn't already in use. Verify the server address, port, authentication settings, and transport settings; an incorrect device clock can also affect secure connections. A test timeout only means the test did not finish in time—it doesn't prove on its own that the server is unavailable. Some tests use a different request path from normal web traffic. Cross-check with a known-working configuration and another network, and use the logs to distinguish DNS failures, connection refusals, certificate errors, and remote response timeouts.

Connected usually means only that the local service or virtual interface has started; it doesn't mean requests are reaching the remote server. Make sure you've selected a working server, then check the logs for a matching connection when you open a webpage. If there's no entry, focus on the app's traffic entry point, system proxy, and TUN capture scope. If an entry appears but fails, check outbound routing, DNS, authentication, and transport settings. Test a specific page in one browser, temporarily stop other proxy tools, and change one setting at a time. Don't reset everything at the outset—you could lose useful clues.

Check the update logs first to see whether the issue is a connection timeout, DNS failure, access denial, or a response the client can't parse. Check whether the subscription has expired, its URL has changed, and the device clock is correct. If the subscription is only reachable through an existing proxy, use the client's update-through-proxy option if available—but only if a working server is already active. If direct access works, there's no need to force traffic through a proxy. Don't delete old entries that still work or post the full subscription URL in a public forum. Note the error and ask the subscription provider to confirm access.

FakeDNS isn't a general-purpose fix. First distinguish between system DNS, browser Secure DNS, and core DNS to identify where resolution fails. Check whether the current DNS server is reachable through the intended outbound route. If only some domains fail, review domain rules, resolution policies, and stale caches. FakeDNS returns virtual addresses for mapping and must work with traffic capture and routing; enabling it alone can cause new problems. Restore a basic DNS setup you understand, then configure and test settings for your use case, such as TUN, one at a time.