V2Ray FAQ

V2Ray usually refers to the Project V proxy ecosystem and its core technologies, not a single graphical interface. v2rayN is a desktop GUI client for Windows, macOS, and Linux; v2rayNG is an Android client. Clients manage subscriptions, generate configurations, and control connections, while the core handles network traffic. When troubleshooting, note the client name, operating system, and active core before looking for the relevant settings. Simply saying you use V2Ray often isn't enough to identify the right menu. Menu names may change between versions, so look for the setting by its function.

The clients are free and open source, but installing one does not provide a proxy server or subscription URL. A subscription supplies the configuration needed to connect to a server and must come from a service you are authorized to use or a server you run yourself. Before importing, make sure you have a valid subscription or a complete share link; an ordinary webpage URL won't work as a subscription. Providers set their own subscription terms, data limits, and fees, separately from the client. Subscription links may contain access credentials, so protect them like passwords. Don't share the full URL or upload screenshots that expose credentials when asking for help.

Choose based on your configuration's requirements, not on how similar the names look. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Both belong to related open-source ecosystems, but they don't support exactly the same protocols and transport features. If your configuration requires REALITY or a specific Xray feature, first check that the current v2rayNG core supports it. For configurations designed for V2Fly, consider v2flyNG. Being able to import a share link doesn't guarantee that every field is supported, so check the logs and test the connection after importing. Save your existing configuration before switching clients to avoid mistaking format differences for network problems.

System proxy writes a local proxy address to the operating system's proxy settings. It's suitable for browsers and apps that use those settings, but programs that make their own connections or ignore the system proxy may bypass it. TUN receives traffic through a virtual network interface and passes it to the core for routing. It can cover more traffic, but requires the right permissions and must work with DNS, routing, and other network software. TUN doesn't mean every request must use the proxy; direct-connection rules may still apply. When setting things up, first use the system proxy to verify the server works, then enable TUN if needed. This makes it easier to pinpoint problems than changing several settings at once.

Check the processor architecture in your device information or a trusted system information tool. Most mainstream phones released after 2015 can usually try arm64 first, but a device's release year doesn't confirm its architecture, and some devices run a different system bitness. The universal package typically supports multiple architectures and is larger, making it a good choice if you're unsure of your architecture or a device-specific package won't install. If installation fails, also check the minimum Android version, available storage, signature conflicts with an older version, and whether installs from the current source are allowed. Back up your configuration before changing packages; don't uninstall your existing client just to try another architecture.

Start by checking what you entered. A subscription URL is usually a complete web address, while a share link may start with vmess://, vless://, or trojan://; each needs the appropriate import option. When copying, make sure you haven't included spaces, line breaks, quotation marks, or explanatory text. In v2rayN, enter the URL in the subscription group settings, save it, then update the subscription. In v2rayNG, add the URL in the subscription group settings, then update the subscription from the menu. Saving a group doesn't confirm that its contents are valid. If it remains empty after an update, check for a login page, an error message, or an unsupported format, then ask the provider to verify the URL.

First check that the installer matches your Mac's processor: choose arm64 for Apple Silicon or x64 for Intel, then follow the installation steps in the disk image. If macOS blocks the app because of its source or signature, verify that the file came from the expected download page, then review Privacy & Security in System Settings and follow macOS's approval steps for that app. Don't disable system-wide security or run terminal commands from an unverified source. If macOS reports that the app is damaged or incompatible, download the correct package again and check the system requirements. If the app launches but can't connect, troubleshoot the configuration and logs instead of repeatedly changing security settings.

Turn off TUN, then grant permissions using the method supported by your platform. Windows usually requires administrator privileges. On macOS and Linux, the client may need a supported privileged service, helper component, or permission to create a virtual network interface; follow the current version's documentation and system prompts. Don't apply instructions for another platform. After granting permission, restart the client and check the logs for errors creating the interface, adding routes, or being denied access. Company device policies may prevent virtual interfaces; contact your administrator if so. If you can't grant permission yet, use the system proxy to verify the basic connection and avoid running multiple virtual-interface proxy tools at the same time.

In most cases, start with rule-based routing, which uses destination domains, addresses, and rules to decide whether traffic connects directly or through a proxy. Avoid routing every request through the same exit indefinitely. When accessing devices on your local network, make sure routing is configured to bypass the LAN so printers, shared folders, and local admin pages aren't sent to a remote server. To troubleshoot a specific site, briefly compare proxy and direct modes, then restore your original rules. Mode names vary by client version, so check the current routing rules and system proxy status as well. Changing routing only affects traffic that already reaches the client; it won't make an app that ignores the system proxy use the proxy.

First distinguish between system DNS, the client core's DNS, and encrypted DNS built into the browser; each may handle different requests. Check which resolver is active in the current mode, then confirm that direct and proxied destinations follow the intended DNS routing. Entering a remote DNS address doesn't guarantee that DNS requests go through the proxy; check the outbound rules for those requests too. With TUN, DNS interception must work alongside virtual-interface routing. Enabling FakeDNS by itself won't fix every problem. Change one setting at a time, restart the relevant app or clear its cache before testing again, and keep a copy of the original configuration so you can revert.

Select a valid configuration in the client and start the connection. Enable the required system proxy or TUN, then make a new request in the app you're testing. Check the client logs for a connection from that app and compare the reported exit IP with the expected route. The IP lookup site is also affected by routing rules, so its result alone can't prove that every app follows the same route. If a browser works but another program doesn't, check whether each one uses the system proxy. Close other proxy tools during testing, and don't assume all traffic is covered just because a toggle is on, a connection icon is visible, or a configuration test succeeded.

Set the update interval to match how often the provider changes the subscription; frequent updates aren't needed to keep a connection working. An update fetches the subscription group again, so entries removed or changed by the provider may change in your client too. It may also overwrite local edits to subscription entries. Back up manual configurations you want to keep or put them in a separate group. Check which group is selected before updating, then confirm your active configuration is still there. If an update replaces the configuration in use, you may need to select it again and restart the connection. Automatic updates still depend on a valid URL, network access, and the client running; they won't fix an expired subscription or malformed data.

First make sure the subscription URL is complete, the service hasn't expired, and your device's clock is correct. Then try both Update subscription (without proxy) and Update subscription (through proxy). The first needs direct access over your current network; the second requires an already working proxy connection. If you don't have a usable configuration yet, updating through the proxy may not work. Check the logs to distinguish DNS resolution failures, connection timeouts, certificate errors, access denials, and parsing failures. If the URL returns a webpage instead of subscription data, ask the provider to fix it. Don't keep clicking Update or post the full URL in public logs; noting the error type and time will help with troubleshooting.

A timeout only means that a particular test didn't finish within the allotted time; it doesn't prove the server is down. First confirm that your device has a working internet connection, then check that the server address, port, protocol, and transport settings match the subscription. Distinguish a TCP connectivity test from an actual connection to a destination through the proxy: a successful TCP test doesn't confirm that authentication or protocol negotiation works. Compare with a known-good configuration and check the logs for DNS failures, connection refusals, or handshake errors. If only certain test destinations fail, check the test URL and its route. If every configuration fails, start by checking the local network, permissions, and conflicts with other proxy software.

Connected usually means only that the client or core has started; it doesn't guarantee that browser requests are going through the proxy. Check that the system proxy address and port point to the current client, then look for new log entries when you visit a webpage. If there are no entries, check the browser's own proxy settings, extensions, and system proxy configuration. If there are entries but requests fail, investigate DNS, authentication, protocol negotiation, or remote connection errors. You can temporarily turn off TUN and test with the system proxy, but use only one clearly defined traffic-capture method at a time. If internet access still fails after stopping the client, clear any leftover system proxy settings and check the virtual network interface. Don't reset all network settings right away.

First confirm that a regular browser can access the internet through the proxy, then check the client's local listening address and port. If only one app is affected, it may ignore the system proxy, use its own proxy settings, or rely on another network interface. Check whether it supports manually configured HTTP or SOCKS proxies, and make sure the selected port uses the right protocol; you can't determine that from the port number alone. If the app doesn't support proxies, consider TUN and make sure permissions, routing, and DNS are set up correctly. Command-line tools may also use environment variables, so the system proxy toggle might not affect them. Restore temporary settings after testing to prevent an old proxy address from breaking connections when the client exits.