V2Ray FAQsSetup and Troubleshooting

Start by distinguishing the configuration interface from the core that handles connections. V2Ray usually refers to the technology and software ecosystem associated with Project V. V2Fly and Xray are related core families that handle protocols, routing, and connections. v2rayN, v2rayNG, and v2flyNG provide graphical interfaces for importing configurations, selecting nodes, and changing settings. An option appearing in the interface does not mean the active core supports it. To check compatibility, look at the client version, the core actually in use, and the configuration fields—not just the client’s name.

For desktop, choose v2rayN based on your operating system. On Android, v2rayNG is usually the first option; consider v2flyNG if you need compatibility with its core. v2rayN supports Windows, macOS, and Linux. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. The two Android clients may differ in supported settings and release schedules, so a configuration for one core is not automatically portable to the other. If you already have a subscription, check its listed protocol and client requirements before choosing. Back up any settings you need before switching clients, then review routing and DNS after importing.

You’ll need a valid server configuration or a compatible subscription link; installing a client alone does not provide a working connection. A node configuration typically includes an address, port, authentication details, and transport and TLS settings. A subscription link retrieves multiple configurations at once. After importing, select an active node and enable the system proxy or TUN if your apps require it. Subscription links may contain credentials, so treat them like passwords. When asking for help, don’t share the full link, QR code, or credentials from a configuration screenshot; share a redacted error description and relevant log excerpts instead.

Choose arm64 if your device uses ARM64 and the operating system supports the app’s architecture. If you’re unsure, consider the universal package. Most recent Android phones use ARM64, but a supported processor does not guarantee that the system provides the required runtime; check older devices and emulators separately. Universal packages usually include components for multiple architectures and are therefore larger. Check the package notes for the architectures it supports. If installation fails to parse, also check the Android version, whether the download completed, and whether the signature conflicts with an app already installed on the device—not just the architecture.

Make sure you copied the subscription URL—not a login page, sharing page, or description of a single node. Remove any leading or trailing spaces and line breaks, add the URL to a subscription group, save it, and update that group. If you get a format error, check that the provider offers a subscription format your client can read. A returned webpage, login prompt, or empty response cannot be parsed as a node list. Import single-node share links through the appropriate option, such as clipboard import. If it still fails, note the exact error and when it occurred, and check that the subscription has not expired. Avoid repeatedly pasting the same invalid URL.

For a new installation, consider the cross-platform desktop version. If you prefer the classic Windows interface, choose the WPF version. Their main differences are the UI technology and runtime requirements; similar names do not mean they can share all settings files. Before installing, check your system architecture and the runtime required by the release package. If startup reports a missing component, install the one named in the error instead of repeatedly changing nodes. When migrating, use the client’s backup or export feature first, then check subscription groups, listening ports, and routing in the new interface. Don’t install both versions over each other in the same directory.

Start with the system proxy to verify the basics, then decide whether to enable TUN based on your apps’ needs. The system proxy directs apps that follow system settings to a local proxy port. Routing rules determine which outbound connection the core uses. These work at different stages. TUN captures more traffic through a virtual network interface, but still needs appropriate routing, DNS, and permissions. During initial setup, don’t enable the system proxy or TUN in multiple clients, and avoid stacking network interception tools from unknown sources. Keep the traffic path simple; once the connection works, add routing and traffic capture settings one at a time.

First grant the permissions required by your operating system and client, then check that the virtual network components are working. Some Windows implementations need elevated permissions or a corresponding service. macOS and Linux may require system authorization, helper components, or network interface access, depending on the package. On Android, allow the VPN connection and check whether another app is already using one. If authorization fails, turn off TUN, confirm that the regular proxy works, and then review the startup logs. Don’t leave security protections disabled to work around a one-off error, and don’t enable two virtual network traffic-capture tools at once.

Keep your existing nodes; don’t delete the group in an attempt to recover it. Subscription updates and node connections use separate paths, so working nodes don’t prove that the subscription URL is reachable. Check whether the subscription has expired or its URL changed, and whether the client is set to update subscriptions through a proxy. If a direct update fails, try updating through an existing working connection, or vice versa. The option may vary by version, so refer to your current interface. Record the exact certificate or HTTP status error. Don’t disable certificate verification to hide the problem or refresh repeatedly at a high rate.

First check which rule matched, then point traffic that should connect directly to an existing direct outbound. A common setup places geoip:private and geosite:cn rules before the catch-all proxy rule, but the right order depends on blocking rules and your needs. Rules are usually evaluated in order, so a broad proxy rule placed earlier can prevent later direct rules from taking effect. If you use geosite or geoip, make sure the active core can load the required rule data. Save and reload the configuration, then test with a new connection; existing connections may continue using the old route.

First determine whether the app, operating system, or core resolves domain names, then change the setting at that layer. Browser secure DNS, system DNS, core DNS, and TUN DNS interception can all be active at once, so changing just one may not affect the actual lookup path. Record the original settings, change one thing at a time, and test both domain access and connection logs. The routing field domainStrategy affects domain resolution and IP matching in specific cases; it is not a global DNS switch. Don’t copy fields from another core without checking compatibility. Consider per-domain DNS or FakeDNS only after confirming the lookup path.

Create a separate group for each source or purpose, and give each group a clear name rather than mixing every URL into one confusing list. After updating a group, check which nodes it returned and which one is active before connecting. Filters can hide nodes, so if the list is empty after an update, check name and protocol filters as well as the selected group. Update behavior varies by client, and manual edits to subscription-generated nodes may be overwritten next time. Manage custom entries separately using the method supported by your client, and back up any settings you need before deleting a group.

Check your device’s clock, subscription status, local core, connection settings, and server status—in that order. Avoid changing everything at once. Enable automatic time synchronization, update the subscription, and confirm the active node. Then check whether the core started successfully, whether its port is already in use, and whether the logs show a connection timeout or a failed TLS handshake. Verify the address, port, transport type, server name, and authentication details; fields for different protocols are not interchangeable. Finally, compare using another network or a different known-working configuration. Speed-test timeouts can also depend on the test target, so check whether normal browsing works.

First confirm that traffic is reaching the client. A running status only means the service or traffic-capture process has started; it doesn’t mean the destination connection succeeded. Check for new logs when you try to visit a site, then verify the active node, system proxy or TUN status, routing outbound, and DNS. If all domains fail, focus on resolution errors and the local listening port. If only some sites fail, check matched rules, destination connections, and protocol settings. You can temporarily test with simpler rules, but restore the required routing afterward. Change one setting at a time and record the results to identify the cause.

Yes. Browsers and command-line tools don’t necessarily use the same proxy settings. In the browser, check the system proxy toggle, proxy extensions, PAC settings, and the browser’s own settings. Confirm that it points to the current client’s listening address and port. For terminal programs, check whether they support proxy environment variables; existing terminal sessions may need to be reopened, and some tools have their own proxy options. Don’t enter a listening port for one proxy protocol as another protocol’s port. If the browser works but the terminal doesn’t, check the terminal settings before switching nodes. Consider TUN if you need to capture traffic from more apps.

First determine whether the client process was stopped, the VPN connection was replaced, or the node itself stopped working. Check persistent notifications and logs around the time of the disconnect, then review battery optimization, background activity, and auto-start permissions; the settings vary by device manufacturer. If another app starts a VPN, the connections may conflict, so keep only the traffic-capture option you need. If the issue occurs when switching between mobile data and Wi-Fi, reconnect and check DNS and network status. Don’t assume the subscription is invalid just because pages stop loading after the screen locks, and don’t disable every battery-saving feature at once. Test only the permissions you need, one at a time.