V2Ray FAQ and Troubleshooting

For Windows, macOS, and Linux desktops, v2rayN is the usual choice, with full access to server lists, subscription groups, system proxy, routing, and TUN settings. On Android, v2rayNG, which uses the Xray core, is generally preferred; choose v2flyNG when you specifically need the V2Fly core ecosystem. Their configuration interfaces differ, and whether a subscription can be imported still depends on the protocols and fields provided by the server.

V2Ray generally refers to the protocol and tool ecosystem built around Project V. V2Fly and Xray are common core families responsible for low-level connection, transport, routing, and DNS tasks. v2rayN, v2rayNG, and v2flyNG are graphical clients that save configurations, invoke a core, and provide controls such as the system proxy. When troubleshooting, distinguish between interface settings, core startup, and remote nodes.

A subscription link usually returns a set of server configurations that the client can save in groups and update regularly. A single share link describes one node, typically including its address, port, identifier, transport, and security parameters. Use the subscription management entry for subscriptions, and the clipboard import or scan entry for a single link. Using the wrong entry commonly results in an empty list or an unrecognized-format error.

A system proxy passes traffic from proxy-aware apps to the client through the operating system's proxy settings. It is simple to configure and works well with browsers and desktop apps that follow system proxy settings. TUN mode creates a virtual network interface and can capture more apps that ignore system proxy settings, but it requires additional permissions and is more sensitive to the local firewall, virtual adapters, and DNS configuration. For a first setup, verify the system proxy before enabling TUN if needed.

The right frequency depends on how often the subscription provider changes its configurations. If node information remains stable, frequent refreshes are unnecessary. Update manually after a configuration notice, widespread node failures, or a change in the subscription contents. Avoid setting an automatic interval that is too short, as frequent requests may trigger limits. Keep the currently working server before updating, then check whether the group and active server were replaced.

Update the subscription first, then select an entry in the server list as the active server. The client's test results are useful for filtering, but you should ultimately start the core and visit the target site. If a test fails, first check the logs for DNS resolution, connection refusal, handshake failure, or timeout messages. Do not judge by name or ranking alone, and do not change the protocol, routing, DNS, and proxy mode at the same time, or it will be difficult to identify the source of the change.

Global mode generally sends all capturable traffic through the current server and is useful for temporarily verifying that a node works. Rule mode decides between proxy and direct connections using conditions such as domain, ip, and geosite, making it suitable for daily use. Direct mode is mainly for pausing the proxy path and comparison testing. When configuring a new subscription, verify the connection in global mode first, then switch back to rule mode. If the result changes, check the rule order and final fallback rule.

First confirm that the rule type matches its content: put domain names in a domain condition, address ranges in an ip condition, and use the correct geosite name for predefined categories. Most routing rules are matched from top to bottom, so a broad rule earlier in the list may capture the traffic first. After editing, make the client reload the configuration and use the logs to confirm the actual destination domain, resolution result, and matched outbound. If you change rules without restarting the core, the old configuration may remain active.

Starting with the system, starting the core, and enabling the system proxy are three separate actions. First enable launch at system startup in the client settings, then confirm that the previous server loads at startup, and finally enable setting the system proxy after launch if needed. Reboot once after the initial setup to verify that the client runs, the core starts, and the system proxy is written. Seeing a tray icon alone does not mean the proxy path is working.