V2Ray FAQ

V2Ray is part of the Project V proxy ecosystem. V2Fly continues maintenance of related community cores, while Xray is a fork within the same technical ecosystem. v2rayN is a graphical client that manages subscriptions, generates configurations, and launches a core; the core handles the actual connections. When troubleshooting, distinguish interface settings from core errors: an import failure may be caused by an unsupported subscription format, while a connection failure calls for checking protocol parameters and core support. A client’s name alone does not tell you which protocols it supports. Check which core the current configuration uses and what that core supports.

For desktop use on Windows, macOS, or Linux, choose v2rayN to manage subscriptions, routing, and the system proxy. On Android, v2rayNG with the Xray core is the usual choice; consider v2flyNG if you need a v2fly core configuration. These are separate applications, not different interfaces for the same program, so their settings and supported configuration formats may differ. Choose a client for your operating system, then check that it supports the server protocol and transport parameters. When switching clients, re-import the original subscription where possible rather than assuming one client’s full configuration is a universal format.

A client provides connection and management features; it is not a remote proxy service. A subscription link retrieves a set of server configurations, while a node configuration describes one server’s address, port, protocol, and authentication parameters. After installation, import a valid configuration and select an available server so the core can establish a connection. Subscription expiry, server access, and client updates are separate matters; updating the app will not restore an expired service. Subscription links often contain credentials, so store them securely. When asking for help, hide the link, user ID, and authentication fields.

REALITY is not a complete node configuration that works on its own. It is a security mechanism used with a proxy protocol, transport, and related parameters, commonly in Xray configurations. A connection also depends on matching fields such as the server address, port, user ID, serverName, public key, and shortId, as well as core support for that combination. Import the configuration provided by your service provider; do not change the domain or copy parameters from another node. A successful import only means the client recognized the data—it does not mean the server accepted the connection.

The system proxy directs requests from apps that honor system settings to a local proxy port; it does not automatically capture traffic from every app. Routing determines which outbound—such as direct, proxy, or block—handles requests that reach the core. TUN uses a virtual network adapter to capture more traffic, but still requires routing and DNS configuration. Start with the system proxy to confirm the node works, then enable TUN if your apps need it. If one app bypasses the proxy, first check whether it honors system proxy settings rather than assuming the node has failed. Changing how traffic enters the core and changing routing rules are separate operations.

Create a separate group for each subscription source, add a clear label, and set its update URL. To filter server names, use Japan|日本 in a regex-enabled server filter to match either keyword, or ^HK to match names starting with HK. Regex characters have special meanings, so handle characters such as parentheses and periods according to the match you want. Start with a simple keyword, confirm the results, then combine conditions. If the list suddenly appears empty, remove the filter before deleting the subscription. A filter changes what is displayed; it does not prove that the subscription’s servers are offline.

Enable per-app proxying in v2rayNG settings, then confirm whether the current mode proxies only selected apps or bypasses selected apps—the two modes do the opposite. Reconnect after changing the app list, then test with the target app. Android routes traffic through VpnService, which generally cannot run alongside another service using the same VPN channel. If connections often drop when the screen is locked, allow the app to run in the background in Android’s battery settings and configure auto-start if your device offers that option. Don’t change many battery settings at once. Check the logs and system notifications first to determine whether Android stopped the process or the remote connection dropped.

geosite matches domain lists, while geoip matches IP address ranges. Updating the data files adds classification entries; it does not automatically change rule order or outbound tags. Confirm the core has loaded the updated files, reload the configuration, and check whether a broader rule earlier in the list is taking precedence. For geosite:cn to match, the core also needs the domain information; having only the destination IP may not be enough. Use the logs to see which rule and outbound actually matched, then verify rules one by one. Don’t assume every unexpected connection is caused by an outdated database.

Check that the subscription URL has not expired or been reset, and make sure your device’s clock is accurate. Then try updating both without a proxy and through a proxy: the first relies on your current direct connection, while the second requires an already working node—an inactive node cannot fetch its own replacement. Check the logs for DNS, TLS, timeout, or HTTP status details. If the response is a login page or an authorization error, resolve the subscription account or URL issue instead of reinstalling the client repeatedly. Keep your existing groups while troubleshooting so you don’t accidentally delete working configurations. Redact the full subscription URL and credentials before sharing logs; never post the raw URL publicly.

A timeout on one node does not prove the entire subscription has expired. Confirm that the device is online, then test another node in the same subscription against the same website. If possible, repeat the test on a different local network. If only one node fails, check that server’s address, port, and status. If all nodes fail, check the local firewall, DNS, system clock, and conflicts with other proxy apps. Client connectivity tests do not necessarily reflect every real-world use case, so compare them with actual browsing and logs. Change one setting at a time and record the result before moving on.

“Connected” usually means the local proxy or virtual network adapter has started; it does not guarantee that the remote server or target website is reachable. Try another node and another website to rule out a single-point failure. Then check that the system proxy port matches the client’s listening port and that requests are reaching the core. If the logs show a domain resolution failure, focus on the DNS server, query path, and possible DNS loops. If a direct connection to the server times out, troubleshoot the network or node first. If the issue began after enabling TUN, switch back to the system proxy temporarily to test, then restore DNS and routing settings one at a time rather than changing everything at once.

Confirm that the client is set to configure the system proxy automatically, then check the proxy address and port in your operating system’s network settings. Browser extensions, app-specific proxy settings, other proxy tools, and organization policies can override system settings. If the problem affects only one app, check that app’s network options first. Clear the system proxy before quitting the client. If an unexpected exit leaves you unable to connect directly, turn off any leftover manual proxy in system network settings, then reopen your browser to test. Disabling the proxy is not the same as disconnecting from the network: if the local proxy port has stopped listening but the system still points to it, requests will fail.