V2Ray FAQ and client troubleshooting

For Windows, macOS, and Linux desktops, v2rayN is the preferred choice. On Android, v2rayNG with the Xray core is a good default; choose v2flyNG when you need the V2Fly core. Their configuration screens differ, but the basic workflow—importing a subscription, choosing a node, and starting the proxy—is similar.

The protocol must match the parameters provided by the server or subscription; renaming or switching it only in the client will not work. With an existing subscription, use the node type it provides. For manual setup, verify the address, port, user ID, transport, TLS, and security settings one by one. A protocol name alone is not a complete configuration.

A subscription link usually contains multiple nodes and can sync additions, removals, and parameter changes through updates. A single-node link represents one configuration, so later changes require importing it again. When using subscriptions, create a separate group and keep the currently working configuration before updating to prevent bad content from replacing the active node.

Global mode sends connections within the client’s coverage through the selected node. Rule mode uses domains, IPs, or rule sets to decide whether traffic is proxied or connects directly. Direct mode avoids nodes whenever possible. For everyday use, start with rule mode and inspect the match result when a specific site fails; switching modes alone is not a complete troubleshooting method.

Xray and V2Fly both grew out of the Project V ecosystem, then developed separate maintenance paths, implementations, and release schedules. v2rayNG usually uses the Xray core, while v2flyNG uses the V2Fly core. Choose based first on the protocols and transport features required by the subscription, then on the client interface and device platform.

Most mainstream Android phones released after 2015 use 64-bit ARM processors, so arm64 is usually the first choice and typically has a smaller file size. If the architecture is unknown, the device is older, or arm64 reports an incompatibility, use the universal build. The two versions offer the same core features and configuration process.

The desktop edition uses a newer cross-platform interface and suits users who want a similar workflow across desktop systems. The classic WPF edition is mainly for Windows and follows familiar long-term workflows. For a first installation, try the desktop edition; Windows users with an established workflow can keep using classic WPF.

First, make sure the link was copied in full, with no extra spaces, line breaks, or non-ASCII punctuation. Add it through the client’s subscription-group entry point rather than a single-node address field. Then check the system time, current network, and link expiration. If it opens in a browser but fails in the client, inspect HTTP status and certificate messages in the log.

First, confirm that the download matches the device chip: choose arm64 for Apple Silicon and x64 for Intel. Move the app completely into the Applications folder, then check the reason for the block in Privacy & Security settings. Do not repeatedly run it from an archive or temporary folder, and do not mix files built for different architectures.

Debian, Ubuntu, and derivatives generally use deb packages. Fedora, RHEL, Rocky Linux, and other distributions in the rpm ecosystem use rpm packages. You must also choose x64 or arm64 for the processor. Check the package manager and architecture before installation; the desktop appearance alone cannot identify the distribution.

Confirm that the current network works, then update the relevant subscription group and wait for the client to finish parsing. Afterward, do not check only the node count: verify whether existing nodes were replaced, whether the correct group was selected, and whether the active node still exists. Frequent automatic updates are unnecessary; set a reasonable interval based on how often the subscription changes.

A speed test reflects only the test time, target, and current network conditions; it does not represent sustained real-world performance. First compare connection success and response differences within the same test run, then verify stability with actual websites or services. A failed test may mean the test address is unreachable, so it does not immediately prove that the node configuration is invalid.

A system proxy provides a connection entry point for apps that follow the operating system’s proxy settings. It is easy to configure and has a relatively clear scope. TUN mode uses a virtual network interface to capture more kinds of traffic, including traffic from apps that ignore system proxy settings, but it usually requires higher privileges and is more affected by firewalls, routing tables, and other network software.

Exit the client first, then grant the administrative permissions required by the current operating system to create a virtual network interface. On Windows, check that the client is running as an administrator. On macOS, review system-extension or network-permission prompts. On Linux, check the relevant capabilities and service permissions. Restart the client afterward and make sure no old virtual interface is still occupying the resource.

Keep the default rules first and complete a basic connectivity check, then gradually add domain, IP, or rule-set conditions based on actual needs. Change only one type of rule at a time and record whether the intended action is direct, proxy, or block. When there are many rules, check their order and overlap first: a broad earlier condition may prevent a later precise rule from matching.

Check in a fixed order: verify the local network and system time, update the subscription and try other nodes in the same group, then review the address, port, protocol, user ID, transport, and TLS parameters. If every node times out at once, check the network, DNS, and subscription status first. If only one node times out, focus on that node’s configuration.

First confirm that the active node actually works. Then check whether the system proxy is enabled, whether the browser uses its own proxy settings, and whether rule mode incorrectly sent the target to a direct connection. Try resolving a common domain and inspect the runtime log. If an IP is reachable but the domain is not, focus on DNS instead of continually changing nodes.

Some programs do not read operating-system proxy settings or keep their own proxy parameters. Check the program’s network settings and restart it completely. If it still does not work, consider whether TUN mode is needed. Also verify that the local proxy port was not changed or claimed by another process, and that security software or another proxy tool has not overridden the system settings.

Copy the subscription address again and verify that it is complete, then confirm that the system time is accurate. Check the update log for timeouts, access denials, certificate errors, or parsing messages. For a timeout, start with the network and DNS; for access denied, confirm the link status; for a parse failure, check whether the response is still in a subscription format supported by the client. Do not keep clicking Update and obscure the first error.

Record the exact time the problem occurred, then inspect nearby connection targets, inbound ports, outbound tags, and error keywords. timeout often indicates an unreachable network or an unresponsive service; rejected means the connection was refused or a rule produced that result; invalid user usually points to mismatched identity parameters. Keep the first error when troubleshooting, since later messages may only be cascading failures.