V2Ray FAQ

No. V2Ray is part of the Project V proxy ecosystem, and V2Fly continues community maintenance of related cores. Xray belongs to a separate core family, and protocol and feature support varies by version. v2rayN is a graphical client for managing servers, subscriptions, routing, and core startup. After you import a configuration, the core launched by the client handles the connection. If a protocol is unsupported or startup fails, check both the client and core details—not just the product name shown in the window. For settings such as REALITY, make sure the server requirements match the capabilities of your current core; changing the protocol name alone will not help.

For Windows, macOS, and Linux desktops, start with v2rayN and choose an installer that matches your operating system and processor architecture. On Android, you can choose v2rayNG with the Xray core or v2flyNG with the V2Fly core. First check the protocol, transport, and security settings required by your provider, then confirm that the client’s included core supports them. The two Android clients may differ in their settings and configuration options, so don’t assume every option transfers directly between them. If your current setup works reliably, back it up before considering a switch; changing clients won’t improve server quality by itself.

The client reads configurations and establishes connections; the installer does not include servers. Get a subscription link, share link, or manual configuration details from a provider you’re authorized to use, then import them into the client. A subscription is an entry point for a set of server configurations that can be updated; an individual share link usually describes one configuration. Use the appropriate import method for each. A purchase page, login page, or regular web address is not a subscription link. Subscription links may contain access credentials, so treat them as sensitive information and don’t post them in screenshots, forums, or logs. Avoid importing and enabling links from unknown sources.

System proxy settings add a local proxy address to the operating system’s proxy configuration. Usually, only apps that follow those settings will use it. TUN uses a virtual network interface and system routes to capture traffic more broadly, but requires the appropriate permissions and can conflict with other virtual interfaces or VPNs. Routing rules decide which outbound a request uses after it reaches the core; they don’t make every app send traffic through the client. Troubleshoot these steps separately: check whether traffic enters the client, then where it goes. For a first test, use system proxy settings to check a website. Once the server works, enable TUN to avoid mixing up permission, DNS, and server issues.

For most mainstream Android phones released after 2015, arm64 is a reasonable first choice, but the device’s supported app architecture is what matters—not its purchase date. Some devices have 64-bit processors but only support 32-bit apps, so an arm64 package may still fail to install. A universal package includes multiple architectures and is usually larger; choose it if you’re unsure of the architecture or arm64 won’t install. Before switching packages, check your Android version, available storage, and the installation error. If an app with the same name is already installed, a signing mismatch may prevent an update. Back up your configuration before uninstalling the existing app, if needed.

Make sure you copied the complete subscription URL, with no extra spaces, line breaks, explanatory text, or missing characters at the end. In v2rayN, add the URL under subscription group settings, then run an update. Use the server import option for an individual server share link; choosing the wrong import method can cause parsing errors. If the link downloads but still produces an error, check whether the response is a login page, an expiration notice, or a format the client doesn’t support. A URL opening in your browser doesn’t prove the subscription is valid. Keep the original link and ask your provider which clients and formats it supports rather than changing URL parameters yourself.

Check your service account and subscription expiration, and confirm whether your provider changed the URL. Then make sure your current network can reach the subscription service. Some update requests need to use an existing proxy; others should connect directly. Follow the client’s update options and your provider’s instructions rather than switching settings at random. If the fetch succeeds but no servers appear, check the response format, server filters, and core compatibility. Keep any working configurations before updating; don’t delete the entire group right away. If the server returns an empty response, clicking update repeatedly won’t help. Note the error and when it occurred, and hide the full subscription URL when reporting the issue.

Turn off TUN first and confirm that a regular proxy connection works, then address system permissions. On Windows, run the client as administrator if prompted, or check that its service mode is installed and running correctly. On macOS and Linux, grant the permissions required by the instructions for your version. On Android, approve the system VPN prompt for the client you’re using. Avoid running multiple apps that capture traffic at the same time. If the error persists after granting permission, check the logs for virtual interface, device creation, or route-writing errors. Don’t disable all security features as a first step or install drivers from unknown sources.

Make sure the client is running, a server is selected, and system proxy is enabled. Then check that the proxy address and port recorded in the system match the client’s current local listening settings. Browser extensions, separate proxy settings, bypass lists, and PAC rules can change the route. Some apps need to restart to pick up system settings; others don’t use the system proxy at all. Temporarily disable browser proxy extensions and make a request that should use the proxy, then check the client logs for a connection. If there’s no log entry, troubleshoot how traffic enters the client. If there is one, check routing and the server. A website loading successfully alone doesn’t prove the proxy is working.

Identify the domains or address ranges that should connect directly, then add matching rules in the routing settings and select a direct outbound. Rules are usually matched in order, though the exact behavior depends on the core and generated configuration. Put specific exceptions before broader rules that could override them. Domain rules and IP rules aren’t interchangeable, and DNS results can affect matching. Change one type of condition at a time, apply the settings, then verify the selected outbound using a real request and the logs. Don’t switch all traffic to direct for a single website or import multiple rule sets without understanding their priority. Back up complex policies and test them in stages.

Not necessarily. System DNS, a browser’s secure DNS, and core DNS operate at different layers. Whether DNS requests pass through the client depends on the proxy mode, request method, and routing settings. First determine whether the problem is name resolution or the connection itself, then adjust the relevant layer. A browser using its own secure DNS may return different results from a system test. In TUN mode, also check whether DNS interception is enabled. Record the original settings before making changes, and change one variable at a time. Clear relevant caches before retesting if needed. Avoid changing multiple DNS providers and enabling FakeDNS at once, or it’ll be hard to tell what fixed—or caused—the issue.

Connect both devices to a trusted local network where they can reach each other. In v2rayN, enable connections from the local network, then check the local HTTP or SOCKS listening port. On the other device, enter the computer’s local network address and the matching port—not a loopback address. Allow the port through your system firewall only on trusted networks; router guest isolation may also block access. Match the device’s proxy settings to the listening protocol. Many TVs and apps don’t follow system proxy settings. Turn off local network access when you’re done, and don’t expose the port to the public internet. Sharing will stop if the computer sleeps, its address changes, or the client exits.

Turn off the proxy to confirm your basic network connection works, synchronize your system clock, then check that the correct server and mode are selected. Next, verify the server address, port, user parameters, transport, and TLS or REALITY settings. Finally, check DNS and core logs. Change one setting at a time and keep the original configuration. A TCP connectivity test, a real proxy request, and a speed test measure different things; a timeout doesn’t prove that every connection is unavailable. If other known-good servers work, focus on the affected server or its parameters. If none work, check your local network, proxy entry point, and whether the core started successfully.

“Connected” may only mean that the local core or VPN service has started; it doesn’t guarantee that requests can reach the remote server. Check the logs while opening a website. If there’s no connection entry, check system proxy settings, app-specific proxy settings, or TUN traffic capture. If there is an entry, review outbound selection, DNS, handshake, and timeout details. Try different websites to distinguish a problem with one destination from a general connection failure. If switching to a known-good configuration fixes the issue, check the original server parameters and service status. Don’t keep changing DNS before confirming that requests reach the client, and don’t rely only on a tray icon or Android VPN indicator to confirm connectivity.

Turn off TUN to restore the previous connection method and keep the error logs. Then check permissions, the virtual network interface, DNS interception, and whether routes were created successfully. Other VPNs, virtual machine networks, or security software may conflict with TUN; exit related apps one at a time and test again instead of changing everything at once. If you use FakeDNS, confirm that the related routing and DNS settings work together. If basic TUN isn’t working, switch back to regular DNS first. If you still can’t connect after closing the client, check for leftover system proxy settings or an abnormal network interface. Restart the system if needed, then retry step by step rather than deleting system network components.

Include your operating system, client and core versions, mode, steps that failed, time of the issue, and relevant error logs. Reproduce the issue once, then capture startup or connection errors from that same time period. Say whether a direct connection works, whether other configurations work, and what you changed recently. Don’t share full subscription URLs, user IDs, passwords, private keys, or an entire unredacted configuration. Check screenshots for address bars and server details, too. Timeouts, resolution failures, permission errors, and handshake errors point to different parts of the connection; the exact error text is more useful than simply saying it doesn’t work. Before sharing debug logs, make sure they don’t contain sensitive request information.