V2Ray FAQ

Choose based on your device, then check the configuration requirements. Use v2rayN on Windows, macOS, and Linux. On Android, v2rayNG with the Xray core is usually the first choice; consider v2flyNG if you need the v2fly core. The client provides the interface, subscription management, and mode switching; the core handles the protocols. Similar names don’t mean configurations are interchangeable—transport and security settings must still match the server. If you already have a subscription, check the provider’s client and core requirements rather than judging compatibility by protocol name alone. Keep your existing settings before switching clients so you can compare them.

The client itself doesn’t provide a server you can connect to. Before configuring it, get a subscription URL, a single-node share link, or the full server settings you’re authorized to use, and make sure your device can access the local network. When entering settings manually, match the address, port, user ID, transport, TLS, and other fields exactly—don’t guess at missing details. Set the correct date and time zone on your device, then test with a configuration known to work. Subscription URLs and share links may contain credentials. Don’t post them publicly or send their full contents to strangers for troubleshooting.

Single-node share links usually start with a protocol prefix such as vmess:// or vless:// and describe one connection configuration. A subscription URL is usually an accessible HTTPS address that the client requests to retrieve a set of nodes. To add a single-node link, use the import-from-clipboard option. To add a subscription, open subscription management, save the URL, and update it. Entering a subscription URL as a server address usually won’t create a valid configuration. An imported single-node link won’t update when the original changes; a subscription can sync nodes on later updates, depending on the subscription service and network connection.

They control different layers. The system proxy sends requests from apps that honor the system proxy settings to a local proxy port. TUN receives traffic through a virtual network adapter and can handle some apps that ignore system proxy settings. Global routing determines how traffic that reaches the core is routed; it doesn’t ensure that every app’s traffic reaches the core. As a result, changing global routing without enabling an appropriate traffic-capture method may leave some apps connecting directly. For a first setup, test browser connectivity with the system proxy, then enable TUN if needed. When switching modes, check LAN, DNS, and exclusion rules, and avoid changing several settings at once.

Check your device’s processor architecture, not just its Android version. Most newer Android phones use arm64, so the matching package is usually the best choice. A universal package typically includes multiple architectures and is larger; use it if you can’t confirm your architecture and the package supports your device. If Android reports that the package is incompatible, check the architecture in your device settings or a trusted specification, then choose another download. An update may also fail because of a signature mismatch, a version downgrade, or insufficient storage. Don’t uninstall the existing app right away—back up your settings first, as uninstalling may erase subscriptions, nodes, and custom rules.

First, make sure you added a subscription rather than importing a single node. In subscription management, check that the URL is complete and remove any spaces, line breaks, or explanatory text copied along with it. Save the URL, update it manually, then check the corresponding subscription group. If it’s still empty, look for an update error indicating an access failure, a parsing failure, or an empty response. A web page, login page, or unsupported subscription format can prevent the client from recognizing nodes. Ask the provider whether the URL supports your client and whether your account is active. Don’t paste the URL into an unfamiliar online converter, and redact credentials from troubleshooting screenshots.

Check your processor architecture and package format first. On Windows, follow the download page to choose between the desktop and classic WPF editions, and confirm that your system meets the requirements. On macOS, check your chip in About This Mac and choose the Apple Silicon or Intel download. On Linux, select deb or rpm to match your distribution, then choose x64 or arm64. A downloadable package isn’t necessarily compatible with your system. If you see a security warning, verify the file’s source and understand the warning before taking action; don’t disable security features across the board. After the first launch, test a standard proxy connection. Configure a virtual network adapter or grant extra permissions only if needed.

Save your settings and disconnect first. Check the logs to see whether access was denied while creating a virtual network adapter, changing routes, or accessing a device. On Windows, the client may need to run as administrator or install a required service; follow its instructions. Permissions on macOS and Linux vary by version and package, so follow the current client prompts rather than copying elevation commands from another platform. On Android, approve the system VPN permission on first connection and check whether another VPN app is already using the connection. Restart the relevant feature after granting permission and check whether the error has cleared. Don’t bypass the problem by leaving system security protections disabled.

Choose based on whether the subscription URL is reachable. If your current network can access it directly, try a direct update first. Use an update through the proxy only if the URL requires a proxy and you already have a working node. If all nodes are down, relying on them to update the subscription creates a dead end; use a network that can reach the URL or ask the provider for a new, valid address. Note the current group and error message before updating, then check whether the nodes actually changed. Don’t send repeated rapid requests, as the service may limit them. A local DNS failure, certificate error, and expired account are different problems, not the same update failure.

Usually not. Choose the node you want in an existing group, make it the active connection, then reconnect or reload the configuration as prompted by the client. If you’re testing one node, don’t also change routing, DNS, and proxy mode, or it will be hard to identify the cause of any difference. Subscription updates may replace node IDs, so check that the selected node is still valid afterward rather than pointing to a removed entry. Record important custom settings before updating; don’t assume subscription-generated settings are stored permanently. Re-add the subscription only if its URL has changed, the original group is damaged, or the configuration format needs to change.

Enable a routing ruleset suited to your needs, then check the order in which its rules are matched. Most rules are evaluated in order, so place LAN addresses and specific domains where they’ll be matched before broader rules can override them. Domain rules, IP rules, and DNS resolution policies can affect one another; changing a single direct-connection label doesn’t guarantee that all requests will behave as expected. After making changes, test LAN services, the websites that should connect directly, and the websites that should use the proxy. Check the actual outbound route in the logs if available. Global proxy mode can change how rules take effect, so confirm that the appropriate rule mode is selected before testing routing.

A common cause is that the system is still pointing to a local proxy port that has stopped listening. Before exiting normally, turn off or clear the system proxy in the client, then disconnect. If the client crashed, reopen it and clear the proxy, or check the proxy switch and address in your system network settings and remove any local proxy entry left by the client. With TUN, also confirm that the virtual adapter and routes have been restored; if needed, reconnect and disconnect using the normal process. Don’t remove settings required by your workplace or campus network. Record the original values before changing them. Finally, restart the browser and check whether basic network access has returned.

Make sure your regular network connection works, then check the node address, port, and subscription status. Identify the test type: a failed TCP connection test may mean the target is unreachable, the port is blocked, or the server isn’t listening. A real connection test also depends on the protocol handshake, TLS, DNS, and the test website. A timeout in one test alone doesn’t prove that every app is unusable. Keep one configuration unchanged, compare it with another known-working node, and check the logs for the same time. If only one node fails, check that node and the server first. If all nodes fail, check the local firewall, network, device time, and whether the core started correctly.

Connected usually means only that the local service or VPN tunnel has started—not that requests to remote sites are succeeding. First check that the core is running, then confirm that browser requests are reaching the client. If there are no request logs, check the system proxy, any browser-specific proxy, and the local listening port. If requests appear but connections fail, check the node settings, server status, and TLS errors. If domain names don’t resolve, check DNS settings and whether the resolver is reachable. Change one setting at a time and repeat the same test. Don’t disable all protections or change certificate settings at random; skipping certificate verification is not a general-purpose fix.

First check whether the app uses the system proxy. Some apps have their own network settings, use a separate proxy extension, or connect through a different network interface; enabling the system proxy won’t automatically change how they connect. Compare with a browser that follows system proxy settings, then check whether the app supports a separate HTTP or SOCKS proxy and enter the address and port the client is actually listening on. If the app can’t be configured separately, consider whether TUN is suitable and check exclusions and permissions. Don’t enable LAN access just to connect an app on your own device; that broadens the listening scope and is a separate issue from whether the system proxy works locally.

Keep the time of the issue, OS and client versions, core, proxy mode, test steps, and relevant log lines from before and after the error. Disconnect, reproduce the issue once using the same steps, then share a short section of logs; it’s usually easier to diagnose than a complete history. Before sharing, hide subscription URLs, user IDs, passwords, access tokens, and personally identifiable information. Redact QR codes and share links in screenshots, too. You can describe the address type and error category without sharing credentials. If the logs only show a successful startup, include entries from an actual request and say whether all apps fail or only a particular site or app.