V2Ray Client FAQ

Use v2rayN on Windows, macOS, and Linux desktops. On Android, v2rayNG with the Xray core is the usual choice; consider v2flyNG when you need a V2Fly-core configuration. Start by checking your operating system, then confirm which protocols and core features your subscription requires. Similar client names don’t mean identical settings, so don’t apply desktop system-proxy instructions directly to Android. If your existing configuration relies on features such as REALITY, check that your current core supports them. See the comparison guide to weigh your options.

A client manages configurations and launches a proxy core; it doesn’t provide servers to connect to. Your configuration provider supplies a subscription URL, which the client reads to create selectable entries. You can also import an individual share link or a complete configuration file. Check the source and expiration date before importing the content in the appropriate format. A regular information page isn’t a subscription URL. Subscription links may contain access credentials, so don’t share them in screenshots, comments, or with unfamiliar conversion sites.

A system proxy sets the proxy address in your desktop’s system settings. It works with browsers and apps that use those settings, but doesn’t capture traffic from every program. TUN routes traffic through a virtual network interface for broader coverage, and may require administrator permissions and changes to routing or DNS settings. Android clients usually route device traffic through the system VPN interface, without a desktop TUN driver. Choose the traffic-capture method that fits your needs, then configure routing rules. Avoid running multiple tools that capture network traffic at the same time.

Not necessarily. Global mode usually determines how traffic that has reached the core is routed; it doesn’t ensure that every app’s traffic reaches the core. With only the system proxy enabled, apps that ignore system proxy settings may still connect directly. With TUN enabled, check excluded apps, bypassed subnets, and routing rules. Troubleshoot in two steps: first confirm that the target app’s requests reach the client, then check which outbound route they match. Don’t infer the traffic path from the mode name alone—check the client’s logs and rules.

Most newer Android devices use the arm64 architecture. If your system supports it, choose the arm64 package. If you’re unsure, check your device specifications or choose the universal package, which includes components for multiple architectures. A 64-bit-capable processor doesn’t necessarily mean the operating system supports a 64-bit runtime, so don’t rely on the device’s age alone. If installation fails, check the Android version requirement, available storage, installation permissions, and whether the existing app has a conflicting signature. A universal package can resolve some architecture mismatches, but it can’t bypass system requirements.

First identify what you’re importing: an individual share link, a subscription URL, or a configuration file. Add subscription URLs in the subscription settings, save them, then update. Clipboard import is generally for supported share links; it won’t necessarily recognize an arbitrary webpage URL as a subscription. Check for spaces, line breaks, quotation marks, or extra text added by a messaging app, then make sure the URL is still valid. If it returns a login page or an error, repeatedly trying to import it won’t help. Ask your configuration provider for the correct URL and client-compatible format.

The Desktop version uses a cross-platform interface and suits users who want a similar experience across desktop operating systems. The WPF version has the classic Windows interface and may suit users already familiar with its menus. Their runtime requirements and settings locations may differ, so follow the download page’s guidance rather than relying on the file name alone. If you’re new to v2rayN, install one version first and test subscription import and connectivity. Before switching versions, back up your configuration and use a supported import method to avoid overwriting the data directory in use.

Turn off TUN first and confirm that standard proxy mode starts. Then use the logs to identify whether the issue involves permissions, a service, or a driver. On Windows, you may need administrator privileges or the relevant service installed correctly. On macOS and Linux, follow the client’s prompts to grant permissions or set up helper components; the steps vary by version. Check whether another VPN, virtual network adapter, or security app is blocking access. Don’t repeatedly install drivers from untrusted sources. On Android, if VPN authorization fails, resolve the system permission issue and check that another app isn’t already using the VPN connection.

Create a separate subscription group for each configuration source and give each group a descriptive name. Don’t repeatedly import multiple sources into the same group. An update may replace entries in that group, so save long-term manual configurations separately. Whether manual changes are retained depends on the client’s current behavior. Before updating, check the selected group and URL; afterward, make sure your active configuration is still there. Before deleting duplicate groups, back up your configuration and check that you’ve preserved any required routes, notes, and manually added entries.

First check whether your configuration provider offers a format the target client can read. If it does, you can usually import it directly without conversion. If conversion is necessary, check that both formats support the protocols, transports, security settings, and extensions you need. A successful conversion doesn’t guarantee that every field was preserved. Test one configuration before converting or using a batch. Don’t send subscription URLs containing credentials to unfamiliar online services, and don’t delete unrecognized fields just to get an import to work. First check whether the client or core needs an update.

For everyday desktop browsing, start with the system proxy: select a working configuration, start the core, enable automatic system proxy configuration, and check that your browser uses the system settings. Consider TUN only if you need to route traffic from apps that ignore the system proxy or have a specific need to capture network traffic. Change one setting at a time and note what happens before and after. You don’t have to enable the system proxy and TUN together; using both can make problems harder to diagnose. On Android, enable VPN routing through the client as instructed.

Open the client’s runtime or core logs and note when the problem occurs. Reproduce the failed action once, then check the relevant error and the lines around it. Before sharing logs, redact the full subscription URL, user IDs, passwords, tokens, and any other reusable credentials. Consider hiding server addresses as well. Keep the error type, field names, and sequence of actions so others can help diagnose the issue. Raise the log level briefly only when needed, then restore the usual level to avoid recording excessive activity over time. Don’t publish your entire configuration file.

A working old configuration only shows that its saved server settings can still connect; it doesn’t mean the subscription service is working. Check whether the subscription URL has expired or been reset, then see whether the update request timed out, encountered a certificate error, or was denied. If the client offers an option to update subscriptions through a proxy, try changing the update route while a working configuration is available. This avoids relying on a configuration that hasn’t been updated yet. Don’t delete a working group in a hurry. Back it up first, then check your system clock, basic network connection, and the provider’s subscription service.

Don’t draw conclusions from a single test. First check what the test measures: some only check whether a port is reachable, while others make an actual proxy request, so failures can have different causes. Verify your device’s clock, server address, port, protocol, transport, and security settings. In particular, don’t use a configuration with a core that doesn’t support it. Compare the results using another known-working configuration or a different network. If every configuration fails, check local permissions, your firewall, and network first. If only some fail, contact your configuration provider.

First confirm that the core is running without startup errors. Then check how traffic is routed: on desktop, does the system proxy point to the current listening port? On Android, has the client been granted VPN permission? Next, check the logs for requests when you try to browse. If there are none, check for a browser-specific proxy, excluded apps, or other proxy tools. If requests reach the core, check DNS, the outbound route, and whether the configuration works. Change one setting at a time and test again instead of resetting everything. For detailed steps, see the connection troubleshooting checklist.

Check that the system proxy address and port match the client’s current listening settings. Also check whether your browser has its own proxy configured or an extension that controls proxy settings. If the core reports address already in use, another process or client instance is using that port. Close duplicate instances first. If you need to change the port, update any apps that specify it manually. Test the system proxy only after confirming that the core started successfully. Before closing the client, clear the system proxy settings it applied to help prevent your browser from connecting to a stale port.