v2rayN
For Windows, macOS, and Linux. Manage configurations, subscription groups, routing, and logs in one place, making it easier to review settings on desktop.
Choose a desktop download →Choosing between v2rayN, v2rayNG, and v2flyNG
Start with your device platform, then check which core your server configuration requires. Subscription imports, split routing, and traffic routing are separate functions; don't choose a client based on a feature label alone.
For Windows, macOS, and Linux. Manage configurations, subscription groups, routing, and logs in one place, making it easier to review settings on desktop.
Choose a desktop download →Uses the Xray core. Import a subscription and grant VPN permission first, then configure per-app proxying if needed. Consider v2flyNG when you have a specific core requirement.
Choose an Android download →Maintenance status is a general description, not a promise about update frequency or features. Menu labels and available options may vary by release; check the package notes and the client's current interface before relying on this table.
On narrow screens, scroll the table horizontally to see the full comparison.
| Comparison criteria | v2rayN | v2rayNG | v2flyNG |
|---|---|---|---|
| Platforms | Windows / macOS / Linux | Android | Android |
| Core family | Xray is a common choice; other core options depend on the release | Xray | v2fly |
| Maintenance | Actively maintained | Actively maintained | Ongoing maintenance as an alternative for the v2fly ecosystem |
| Ease of use | Easy to import a basic configuration; distinguish system proxy from TUN | Straightforward basic setup; note VPN permissions and background restrictions | Similar basic workflow; verify core compatibility separately |
| Subscription groups | Manage subscription sources, notes, and updates in subscription group settings | Manage subscription sources in subscription group settings, with server filtering options | Subscription management available; filtering and update options depend on the current interface |
| Routing rules UI | Routing settings make it easy to edit and switch rule sets | Routing settings support domain, IP, and per-app options | Routing settings are available; rule fields must be supported by v2fly |
| TUN and traffic routing | TUN options are available; system permissions and required components may be needed | VPN mode routes traffic through Android's VPN interface; it is not the same as a desktop TUN toggle | Routes traffic through Android's VPN interface; network stack options depend on the release |
| Best for | Desktop use, editing rules, and organizing multiple subscriptions | Everyday Android use, per-app proxying, and users with Xray configurations | Android users with existing v2fly configurations who can verify protocol and field compatibility |
For desktop, start with v2rayN. Its GUI brings configuration lists, subscription groups, routing settings, and logs together, making it easier to review changes as you go. For your first setup, add the subscription URL under “Subscription Group Settings,” update it, and then select a configuration. Check the logs and test access in the apps you use to confirm the connection; don't rely on the tray icon or connection status alone.
A system proxy mainly affects apps that honor the OS proxy settings. TUN routes traffic at the network layer and has different coverage and permission requirements. If you mainly use a browser, start with the system proxy. Consider TUN if an app ignores it. Before enabling TUN, check for conflicts involving local network access, DNS handling, or other networking tools. Permission steps also differ across Windows, macOS, and Linux.
The Windows download page offers Desktop and classic WPF builds. Desktop is the newer cross-platform interface; WPF is the classic interface. These are not different proxy protocols or performance tiers. Stick with WPF if you're comfortable with its workflow, or try Desktop if you want a similar experience across desktop platforms. For macOS, choose the build for your processor architecture. For Linux, match the package format and processor architecture to your distribution.
For advanced users, the main benefit is more room to manage configurations—not automatically better routing after import. Maintain subscription-provided server settings separately from local routing rules. When switching cores, check whether the transport, security layer, and custom fields are supported. A configuration being accepted by the UI doesn't guarantee the core can run it.
v2rayNG is a good fit if you're getting started with an Android client by importing a subscription. Add the subscription URL under “Subscription Group Settings,” save it, and then update the subscription. Use the relevant import option for individual share links. Both can create configurations, but they are updated differently. Keeping separate groups by source makes it easier to find the problem if a URL expires or an update fails, without checking every entry.
The first time you start VPN mode, Android asks you to approve the VPN connection. The VPN icon in the status bar means the traffic-routing interface is active; it doesn't confirm that the remote server is reachable. If you only need a local proxy port, you can explore “Proxy Only” mode, but you must configure the proxy in each app as well. It won't route every app's traffic automatically.
“Per-app proxy” limits which apps are included in proxy handling. This is separate from routing rules: an app must first be included, then its traffic is routed according to rules such as domains and IP addresses. When troubleshooting an app, check whether it's included before reviewing routing—don't change DNS as your first step. After an OS update or app reinstall, verify that the selected apps are still correct.
The Xray core is a good fit when you need its supported protocols and security-layer settings, but sharing a protocol name doesn't mean every configuration field is interchangeable. Before enabling traffic sniffing, FakeDNS, or Mux, keep a working baseline and change one option at a time. That makes it easier to identify the cause of a problem and roll back a specific change.
Choose v2flyNG if you already have a v2fly configuration or a specific need for its core—not just because its name resembles v2rayNG. Both are Android GUI clients, but their cores may differ in supported protocols, security layers, and configuration fields. Before importing a share link from an Xray setup, check that its fields have corresponding implementations. Don't assume a feature specific to one core is available across the entire Project V ecosystem.
When migrating, start with a configuration from a known source that you've confirmed is compatible. Test the connection with basic routing, then gradually restore subscription groups and custom rules. If the imported configuration is incomplete, check its format and the core's support first. If the startup log reports an unknown field, review what the original setting means rather than repeatedly reinstalling. A subscription that can be read only proves its format is parseable; it doesn't mean every configuration in it is suitable for the current core.
v2flyNG can be a focused choice for users familiar with v2fly who are comfortable maintaining a separate configuration. Android beginners without a specific core requirement should start with v2rayNG. Don't assume v2flyNG is better for an older phone: compatibility also depends on the OS requirements, processor architecture, background policies, and enabled features. You can't infer resource usage from the client name.
When switching clients, handle server settings separately from local traffic-routing settings. Server settings include the address, port, transport, security layer, and authentication details. Local settings include the system proxy, VPN mode, DNS, routing, per-app list, and listening ports. A subscription generally supplies only the configurations it contains; it won't automatically copy the full setup from another device.