V2Ray FAQ

V2Ray is part of the Project V proxy ecosystem. Its core handles protocols, connections, and routing, while graphical clients provide an interface for managing subscriptions, servers, and proxy settings. v2rayN is available for Windows, macOS, and Linux; its protocol support depends on the core and version in use. v2rayNG is an Android client that uses the Xray core, while v2flyNG is an alternative built on the V2Fly core. To check whether a configuration is compatible, verify the client, core, and transport settings—not just the name of the share link.

Yes. The client provides local proxy and configuration management features; the installer itself does not include a remote service to connect to. Before first use, obtain a subscription URL, server share link, or complete configuration that you are authorized to use, then import it through the appropriate option. Subscription URLs often contain access credentials, so keep them private and never post them on public forums or in screenshots. After importing, make sure the server address, port, and protocol are recognized by the client, then test a server connection. A server appearing in the list only confirms that the configuration was imported—it does not mean the remote service is available.

A system proxy registers a local proxy address with the operating system and mainly affects apps that follow that setting. TUN routes eligible traffic through a virtual network interface, which can help with apps that ignore the system proxy, but requires additional permissions and correctly configured routes and DNS. Global routing is a traffic-selection policy in the client or core; it does not mean every program will automatically use the client. When troubleshooting, first check whether traffic reaches the local entry point, then check which outbound route it takes. Establish a working baseline with the system proxy before enabling TUN as needed, and avoid changing several variables at once.

Importing a link depends on the client’s parsing support; connecting also depends on whether the current core supports the protocol and its additional parameters. Even with the same protocol, differences in transport, TLS, server name, path, or REALITY fields can prevent a connection. After importing, open the server editor and compare each setting with the details from the configuration provider. Don’t disable certificate verification just to clear an error. If the format isn’t supported, check the client version and link type, then request a share link compatible with that client instead of changing only the link prefix.

Most mainstream Android phones released since 2015 can use the arm64 build, but check which app architectures your device actually supports; some devices may have system-level restrictions. The universal build includes components for multiple architectures and is usually larger, making it a useful option if you’re unsure. If installation fails or reports incompatibility, check the Android version and supported architecture, then make sure the download completed. Updating over an existing app also requires a compatible signing key. If you see a signature conflict, export your configuration and confirm where the existing app came from before uninstalling it, so you don’t lose subscriptions or local settings.

Open About This Mac from the Apple menu. If it lists an Apple chip, choose the Apple Silicon (arm64) build; if it lists an Intel processor, choose the x64 build. If you see a security prompt on first launch, verify the installer’s source and system requirements, then check Privacy & Security in System Settings to see whether you can approve the app. The exact steps vary by macOS version. Don’t bypass the prompt by disabling system security features wholesale. If the app launches but its core won’t run, check the client folder permissions and make sure the core architecture matches your device.

First, distinguish a subscription URL from an individual server share link: add subscription URLs to a subscription group, and use the appropriate option—such as importing from the clipboard—for share links. Remove leading or trailing spaces, line breaks, and punctuation added by chat apps. Make sure the URL hasn’t expired and your account still has access. If an update returns an empty list, check the logs for a login page, web error, or unsupported subscription format. A page opening in a browser doesn’t mean the client can parse it as subscription data. If you already have a working group, keep it and test with a new one rather than repeatedly overwriting the existing configuration.

Turn off TUN first and confirm that a regular system proxy connection works. Then grant the permissions requested by your client. On Windows, this usually involves administrator access and a virtual network adapter component; on macOS and Linux, authorization or helper-service requirements depend on the client version and how it runs. Don’t make the entire installation folder writable by all users or leave the firewall disabled. If TUN still fails after authorization, check the first error in the logs, virtual interface creation, route updates, and whether another VPN is using the same resources. Change one setting at a time, then enable TUN and test again.

A working server only confirms that its saved connection settings are still valid. The subscription may use a different domain, certificate, or set of access credentials. Check the subscription’s expiration date, system clock, and update logs, then find out whether the client fetches updates directly or through the proxy. If your version supports updating through a proxy, try again after connecting to a working server. If the proxy itself is unavailable, don’t make subscription updates depend on it. If you encounter rate limits, stop retrying for a while. Keep the existing group until an update succeeds, and ask the provider whether the subscription URL has changed.

First confirm that the core has started. Then check that the address and port in your operating system’s proxy settings match the client’s current inbound listener. In a browser that follows the system proxy, visit a permitted test destination and watch the client logs for the corresponding request. If the request appears in the logs, traffic is reaching the client; check the routing result to confirm whether it uses a remote outbound. Browser extensions, per-app proxy settings, and connection pools can override or delay system settings, so disable extensions and restart the app if needed. Restore the original settings after testing to avoid mistaking another app’s issue for a server problem.

In common V2Ray and Xray routing configurations, rules are generally evaluated from top to bottom, so put specific domain or app exceptions before broader rules. Each rule’s outbound tag must match an outbound that is actually defined, and rule-set names and data files must be compatible with the core in use. Save the current configuration before making changes. Start with one easy-to-verify destination, check the match in the logs, and expand from there. Don’t copy configuration syntax from another core unchanged when switching cores. DNS resolution, domain sniffing, and caching can all affect matching, so consider the type of request rather than checking only whether a webpage opens.

Enable LAN connections in the client and make sure the inbound listener isn’t restricted to the loopback address. On other devices, enter your computer’s LAN IP address and the proxy port currently in use—not their own loopback address. Some client configurations commonly use SOCKS on 10808 and HTTP on 10809, but ports and inbound types vary by version, so check the current settings. Allow only the necessary ports through the firewall for trusted LAN devices, and never expose the proxy listener to the public internet. Configure access authentication if your setup supports it. Sleep, IP address changes, or wireless access point isolation can also interrupt sharing.

First enable automatic time synchronization and check the time zone. Then make sure the core started successfully and that another app isn’t using the local listening port. Next check server DNS resolution, the remote port, and your local firewall; finally verify the transport, TLS server name, path, and authentication settings. If all servers time out, focus on the local network and shared settings. If only one fails, check that server and its parameters. Some latency tests use probes that servers may reject, so a test timeout alone isn’t conclusive. Keep the first error in the logs and verify the connection with an actual request.

First check whether requests appear in the client logs. If there are none, check the system proxy, per-app proxy settings, and whether TUN is actually capturing traffic. If requests appear but fail, check DNS, routing matches, and remote outbound errors. If only some domains fail, review the routing rules and DNS results instead of reinstalling the client right away. Quit other VPN or proxy tools and test again to avoid conflicting network settings. With TUN, also check that IPv6 and DNS routing match your configuration. After each change, send a new request; if needed, restart the browser to rule out existing connections and cached results.

In the client, select the option to clear the system proxy. Then check your operating system’s network settings for a manual proxy or automatic configuration URL that still points to a local port. When the client exits, its local proxy listener stops; any leftover proxy settings can prevent apps that follow them from connecting. If you can’t open the client, you can turn off the relevant proxy manually in system settings, but record the original values first—especially if they belong to a work network. Restart the browser to verify the connection, then check whether another app is rewriting the settings. If TUN caused the problem, also check the virtual interface and routes; clearing the system proxy alone does not disable TUN.

When connecting for the first time, approve the system VpnService request and check that no other VPN is running. If the connection drops in the background, see whether the system is restricting background activity. Allow the app to run in the background and adjust battery optimization as needed; menu names vary by device manufacturer. If some apps aren’t using the proxy, check whether per-app proxy settings include only selected apps or exclude selected apps, then reconnect. Some apps keep long-lived connections after a setting changes, so fully quit and reopen them. If the VPN icon is still visible but requests fail, check the logs and server status rather than relying on the icon alone.