v2rayN FAQ

v2rayN is a graphical client for Windows, macOS, and Linux; v2rayNG is for Android. Clients manage subscriptions, edit configurations, and provide proxy entry points, while the core handles the actual connection. Xray and V2Fly are part of related open-source core ecosystems, and supported features vary by version. When troubleshooting, note the client name, core name, and error message instead of simply saying “V2Ray doesn’t work.” On Android, v2flyNG is another client option built on the V2Fly core; check the specific protocol and parameters to confirm configuration compatibility.

A subscription URL is usually a web address the client requests to retrieve a set of configurations, which can then be updated later. A single share link usually starts with a protocol prefix such as vmess://, vless://, or trojan:// and imports one configuration. Pasting a subscription URL into the single-configuration import field may result in a format error; entering a share link in the subscription URL field won’t allow updates. Identify the content first, then use the subscription group or clipboard import option. Subscription URLs may contain access credentials, so don’t share screenshots or the full URL.

Installing the client only prepares the software on your device. You’ll also need a valid server configuration or subscription obtained through legitimate means. After importing it, check the protocol, server address, port, and authentication parameters, then select it as the active configuration. If the client says it has started, that usually means only the local core or proxy entry point is running—not that the remote connection or every app is working. For your first setup, test with a browser that supports the system proxy before configuring terminals, games, or other apps. This site provides usage guides, not subscription URLs or connection accounts.

REALITY is not a proxy mode like “Global” or “Bypass LAN.” It’s a security-related technology in the connection configuration, commonly used with VLESS. Whether to use REALITY depends on the server setup; don’t switch it to TLS just to troubleshoot. After importing, check the server name, public key, short ID, and other parameters required by the server. Field names may vary by client version. The system proxy controls how apps connect through the client, while routing determines their outbound path. These are separate from REALITY parameters and should be checked independently.

Choose based on the app architecture supported by your device. Most recent Android phones support the arm64 package, which is generally smaller than the universal package. The universal package includes multiple architectures and is worth trying if you’re unsure which one your device needs. Don’t rely only on the phone’s purchase year: system support and chip capabilities don’t always match. If the installer reports incompatibility, check the architecture in your system settings or device documentation. If the universal package still won’t install, check your Android version, available storage, and any signature conflicts rather than repeatedly trying packages for the same architecture.

Add a group in the subscription group settings, give it a recognizable name, and paste the full subscription URL into the address field. Save it, then update the current subscription. First check that no spaces, line breaks, quotation marks, or extra text were included when copying, and make sure the URL is still valid. If you copied a single share link, use the clipboard option for importing a server instead. Base64 is an encoding used in some subscription content; it doesn’t mean any Base64 text can be pasted into the subscription URL field. Menu labels may vary, so use the corresponding subscription management option in your client version.

First, make sure you downloaded a client build compatible with your system, then extract the archive fully to a writable folder. Don’t run the app from the archive preview. Install the required .NET Desktop Runtime for your system architecture only if the build explicitly depends on an external runtime or the error says one is missing; not every startup crash is caused by a runtime. Next, check security software logs, folder permissions, and startup logs. If you suspect damaged settings, back them up and test in a separate new folder instead of deleting existing subscriptions and routing settings.

TUN creates or configures a virtual network interface. On desktop systems, it may require administrator approval, a service component, or network permissions, depending on the platform and client version. Close other tools that manage network traffic, then follow the client’s authorization prompts. Don’t grant unnecessarily broad permissions to the entire installation folder. On Android, confirm the system VPN permission; another active VPN connection may prevent TUN from starting. If it still fails after authorization, check the logs for interface or routing errors. For troubleshooting, turn off TUN first and verify the remote configuration with a regular local proxy, then troubleshoot TUN separately.

To route apps that support the system proxy through the client, choose “Set system proxy automatically.” “Clear system proxy” removes the system proxy entry set by the client, typically when disabling it or clearing leftover settings. “Do not change system proxy” leaves the current system settings untouched; it does not mean all traffic connects directly. The system proxy is an app entry point, not global routing, and it won’t automatically cover every program. Note your existing settings before switching, especially if your device already uses a workplace proxy. After testing, check that the system proxy is restored as expected when you exit the client.

Many command-line programs don’t use the desktop system proxy. They rely on their own proxy settings or environment variables such as http_proxy, https_proxy, and all_proxy. Check the program’s documentation to see whether it supports an HTTP or SOCKS proxy, then enter the local listening address and port currently enabled in the client. Don’t use a SOCKS port as an HTTP port, and don’t assume port numbers are the same across versions. Test the variables in the current terminal session first; make them persistent only after confirming they work. If you’ve configured a proxy before, check whether old variables or no_proxy are affecting the request.

Bypass LAN usually sends private IP ranges directly, allowing access to routers, printers, and local services. How other traffic is handled depends on the active ruleset. Global routing usually sends traffic that enters the client through the proxy, but it won’t automatically capture apps that never pass through the client. If local devices become unreachable, check which rule matches the target address and the rule order, then see whether TUN or DNS settings changed the route. Don’t change proxy mode, routing, and DNS at the same time. Adjust one setting at a time and retest the same target to pinpoint the cause.

Put configurations you added manually in a separate group. Avoid editing subscription-generated configurations directly, as an update may overwrite those fields. Before updating, back up the client configuration and custom routes, and note the active group and configuration. Backups may contain credentials, so store them securely. After the update, confirm the active configuration is still there and check whether the transport or security parameters changed. Automatic updates only fetch subscription content; they can’t renew an expired account on the server. If the results look wrong, check the response and logs first. Don’t repeatedly overwrite your only backup.

First, confirm your local network can reach sites you normally access directly, and enable automatic system time synchronization; an incorrect clock can cause secure handshakes to fail. Check that the client core is running and that no other program is using the local listening port. Then verify the server address, remote port, transport, and TLS or REALITY parameters. Use the logs to distinguish DNS resolution failures, connection timeouts, refused connections, and handshake failures; they’re different problems. If it fails only on a particular network, retest on another network you’re authorized to use. Don’t disable certificate verification to hide a configuration error.

First check whether “connected” means the local service started or a request to the remote server succeeded. In the same browser, try a site you normally access directly and a site that requires the proxy. Confirm the correct configuration is active, the system proxy points to the client’s current listening port, and the browser hasn’t enabled a separate proxy setting. Then check for a matching log entry when you visit the site. No entry? Check whether the app is reaching the client. An entry with a DNS failure? Check DNS. A handshake error? Verify the remote parameters. Also check the subscription service status: a running connection entry doesn’t mean the account is still valid.

Open your operating system’s proxy settings and check that the address and port match the client’s current listening entry. Then see whether a browser extension is overriding the system settings. Some browsers or work profiles use a separate proxy, an automatic configuration script, or a managed policy that won’t be overridden by changing the client menu. If permitted by your device management policies, temporarily disable proxy extensions, close and reopen the browser, and test again. Private browsing doesn’t necessarily bypass proxy extensions or management policies. If the client logs show no requests, fix the entry point first; don’t immediately replace the subscription or change the remote protocol.

Start by reading the update error. A timeout usually calls for checking the request route and network. An unauthorized or forbidden response points to subscription access permissions. A format error may mean the client received a login or error page instead of configuration data. If the client lets you choose the update route, try updating without the proxy first. If the subscription service requires proxy access, update through a working configuration to avoid a loop that depends on a configuration you haven’t imported yet. If the URL expired or was reset, get a new one from the original provider. When sharing an error, include only the error type and essential status details; hide the full URL, authentication fields, and credentials in the response.