Use v2rayN by default on desktop platforms
v2rayN is available on Windows, macOS, and Linux. Installation formats differ across platforms, but the core workflow—subscription groups, server lists, routing, and logs—is similar. To use the same servers on multiple desktop devices, import the same subscription on each and configure the system proxy separately.
Desktop and WPF on Windows are different interface implementations, not a simple ranking of protocol capabilities. Desktop is usually better for new users; WPF may feel more natural if you rely on a fixed workflow, traditional menu locations, or tutorials for the classic interface.
On Android, check the core requirement before the architecture
Without a specific preference, start with v2rayNG. It uses the Xray core and suits common subscription imports, per-app proxy rules, and routing configuration. v2flyNG uses the v2fly core and is an alternative when compatible configurations are required. The two clients keep separate configurations, so switching apps requires importing the subscription again in the target client.
After choosing the client, select the arm64 or universal package. arm64 targets mainstream 64-bit ARM phones; the universal build supports a wider range of devices and is useful when the architecture cannot be identified. If installation reports an architecture mismatch, switch to the other package for the same client.
On Linux, check both package format and architecture
Linux has one more selection step than the other platforms: the distribution determines deb or rpm, while the processor determines x64 or arm64. An incorrect package format may not be recognized by the system package manager; an incorrect architecture can cause a format mismatch during installation or launch.
For Debian or Ubuntu families, deb is usually the right choice; Fedora and enterprise Linux derivatives generally use rpm. Check the device architecture in system settings or with uname -m instead of judging by the device's appearance.
Keep existing configuration before updating
Before updating the client, use its configuration export feature or record the current subscription URL, routing rules, and DNS adjustments. Users who rely only on subscriptions generally need to keep only the subscription source; users who maintain multiple nodes, custom outbounds, or complex routing manually should save those configurations as well.
After updating, first confirm that subscription groups and server lists are intact, then test the system proxy. Avoid making broad routing or DNS changes during the client upgrade; otherwise, it becomes difficult to tell whether a connection problem comes from the version or the configuration.