Access Windows, macOS, Android, and Linux clients, with step-by-step guidance for subscription imports, routing, and JSON configuration structure—from platform selection through a configuration process that can be reviewed at each stage.
Clients handle the interface, subscriptions, and system proxy management, while the Xray or V2Fly core handles protocol processing, transport, and routing. Keeping these roles separate helps prevent interface options, core fields, and server parameters from being conflated.
The homepage organizes the material in this reading order: choose a platform, import a configuration, confirm routing, and check the connection. Go to Clients for a direct installation, Getting Started for step-by-step instructions, or the Configuration Reference to verify fields.
The entries below map common interface features to core concepts. Select an entry to review its operating sequence, field boundaries, and troubleshooting priorities.
Routing troubleshooting should begin with the input conditions: confirm which inbound receives the traffic, check whether the domain, IP, port, or process condition matches, and then inspect the target outbound's tag and definition. Rule arrays are usually evaluated in order, so a broad condition near the top can hide more specific rules below it. Client modes such as “Global,” “Rules,” or “Direct” are interface-level management of inbound, routing, and outbound relationships—not independent protocols.
After importing a subscription, confirm that its entries landed in the expected group, then run a manual update and read the status reported by the client. An update only retrieves and parses content; it does not prove that every configuration can connect. After switching nodes, verify that the entry is active, then check the system proxy or mobile connection toggle for the platform. When migrating devices, record custom routing and DNS settings first, since local rules may not be part of the subscription.
Before configuring DNS, clarify the resolution path: does the app pass the domain to the system, or does a client inbound receive it and hand it to the core? Server lists, static hosts mappings, query strategies, and domain-based server selection serve different purposes. If routing by domain or IP is enabled, also check whether the resolved result feeds into routing decisions. For troubleshooting, simplify to a single path first, confirm basic queries work, then add routing conditions one at a time.
Names such as VMess and VLESS describe connection semantics, while WebSocket, gRPC, and mKCP describe the transport layer. After importing a link or JSON, check the server address, port, user parameters, and encryption or security options first, then verify transport fields such as the path, service name, and hostname. Do not try to fix protocol parameters by switching system proxy modes: the integration layer only determines which traffic enters the client and cannot replace consistency checks between both ends.
Desktop system proxies mainly cover apps that follow system settings, while some software keeps its own network configuration. On mobile, the connection is carried by the system VPN service, with per-app proxying controlling which apps are included. If the browser works but other apps do not respond, first check whether the target app reads the system proxy, is excluded by per-app rules, and whether the client uses an integration method suited to the current scenario. Then continue with core logs and routing checks.
v2rayN is the primary desktop entry point, while Android users can choose between v2rayNG and v2flyNG based on core requirements. Installation packages and processor architecture details are centralized on the download page.
Windows users can choose the v2rayN desktop edition or the classic WPF edition. The former uses a cross-platform interface architecture; the latter suits workflows built around traditional Windows usage. The download page explains installation choices, system proxy access, and the positioning differences between the two release lines.
Go to DownloadsOn macOS, use the v2rayN desktop edition and select the installation file for Apple Silicon or Intel. If you are unsure which chip you have, check the processor or chip name in System Information before choosing a download, rather than mistaking an architecture mismatch for an application startup problem.
Go to DownloadsAndroid users can run v2rayNG with the Xray core or choose v2flyNG with the V2Fly core based on their configuration and core preferences. The download page provides separate arm64 and universal installation files and explains the basics of VPN service, background operation, and per-app proxying.
Go to DownloadsLinux desktops can use v2rayN. Choose a deb or rpm package according to distributions such as Debian, Ubuntu, or Fedora. The download page also lists x64 and arm64 options. After installation, follow the guides for desktop integration, subscription imports, and automatic startup of the login session.
Go to DownloadsQuick setup follows the shortest path. Once the first connection is stable, add custom DNS, complex routing, and per-app rules gradually so any issue can be traced back to a specific change.
Choose a client based on the operating system, processor architecture, and desktop environment. Windows and Linux also require a package format choice, macOS requires identifying the chip architecture, and Android offers arm64 or universal installation files. After the first launch, confirm that the interface opens normally and the core loads before importing a configuration, keeping installation issues separate from connection parameters.
Subscriptions are useful for centrally managing multiple entries, while an individual link or manually edited JSON is better for checking specific parameters. After importing, verify that the group, protocol, address, port, and transport type appear as expected, then select the active configuration manually. If the client reports a parsing error, first check the content format and copied range instead of repeatedly switching proxy modes to conceal an import problem.
After starting the client connection, enable the system proxy or mobile VPN service for the platform. For verification, begin with an app that follows system network settings, then check the client log for the corresponding request. Add bypass rules, DNS routing, and per-app scope only after the basic path works. This order helps distinguish issues in connection parameters, system integration, and routing conditions.
GUI clients, cores, and configuration formats are cooperating layers with different responsibilities. Understanding their relationships helps identify whether an option comes from the interface, the core, or the protocol itself.
Project V established a configuration model centered on inbounds, outbounds, routing, DNS, policies, and transport settings. It is not the name of a single GUI program, but a technical ecosystem formed by protocol implementations, core branches, client interfaces, and documentation practices. Many clients turn JSON fields into forms, menus, and mode selectors for easier daily use, while the underlying logic can still be explained through structures such as inbounds, outbounds, routing, and dns.
When reading a configuration file, start by building a picture of the data flow: application traffic enters the core through a local inbound, routing rules choose an outbound, and the outbound establishes a connection based on protocol and transport fields. DNS and policy add conditions for resolution, resource handling, and specific behaviors. Following this path is easier than memorizing isolated fields and makes it simpler to spot broken tag references or conflicting rule scopes.
V2Fly continues the Project V technical ecosystem and maintains its own work around protocols, routing, transport, and platform adaptation. v2flyNG uses the V2Fly core and provides another GUI client combination for Android. When choosing it, check the subscription content against the target core's supported range and rely on the options actually shown by the client, rather than judging compatibility from similar-looking links alone.
Core updates typically involve protocol implementation, dependencies, transport behavior, and bug fixes. Client updates also include the interface, subscription parsing, system integration, and platform packaging. Their release schedules may differ, so when troubleshooting a capability, identify both the client and its core family. An option absent from the interface should not automatically be taken as proof that the core lacks the underlying capability.
Xray is one core branch in the same technical ecosystem, with an independently maintained path around protocol, transport, and routing capabilities. v2rayNG is commonly paired with the Xray core, and v2rayN can also manage the relevant core within its supported range. When migrating configurations, check the actual fields instead of assuming that every extension has identical names, defaults, and support across cores.
For VLESS, Reality, gRPC, or fine-grained routing, core differences matter more than basic system proxy operation. A safer approach is to keep the smallest working configuration, then add transport security, sniffing, DNS, and routing conditions one at a time according to the current core documentation. Changing several fields at once makes it difficult to tell whether a failure comes from protocol parameters, transport settings, or local integration.
v2rayN, v2rayNG, and v2flyNG are all publicly maintained client projects. Open code allows the technical community to discuss and review interface behavior, configuration conversion, and core invocation, while enabling each platform to build its own interface around shared configuration concepts. Open source describes a development and collaboration model; it should not be generalized into a judgment about any configuration source or network environment.
When updating, distinguish among the client application, core components, and subscription content. An application update may change the interface or parsing logic, a core update may change protocol or transport implementation, and a subscription update only replaces configuration entries. Recording what changed and when narrows the rollback window when problems appear. This site's download page covers platform and installation-file choices, the Configuration Reference explains field meanings, and the blog tracks architectural differences and common maintenance issues.
The questions below provide brief checks in troubleshooting order. For specific button and field locations, continue to Getting Started or the Configuration Reference.
The desktop edition uses the cross-platform Avalonia architecture and runs on Windows, macOS, and Linux; the WPF edition is Windows-only and retains the classic interface and workflow. For a new installation, start with the desktop edition. Users with an established Windows workflow can compare the interfaces, dependencies, and migration methods before deciding. The download page keeps separate entry points for both editions.
A successful import only means that the client read the subscription content. You still need to select the active configuration, start the connection, and enable the system proxy or VPN service for the platform. If there is still no response, check the address and port, protocol and transport fields, system time, integration scope, and client logs in that order. Do not immediately attribute every problem to the subscription URL.
The system proxy describes how app traffic enters the client, while Global or Rules mode describes how traffic is assigned an outbound after entering the core. The former is the system integration layer; the latter is the routing layer. If an app does not read the system proxy, it may send no traffic to the client even when routing is set to Global. Conversely, traffic that does enter is still affected by the selected routing mode.
First determine whether the domain is resolved by the system or handed to the core, then check the DNS servers, query strategy, and static mappings. If multiple handling methods are enabled, reduce them to a single path, confirm basic resolution, and then restore routing gradually. When combining domain and IP rules, also verify whether the resolution result participates in routing matches.
The article section covers release-line differences, platform runtime strategies, and proxy-mode boundaries as focused supplements to the download page and configuration documentation.
A breakdown of the roles of the two v2rayN release lines, comparing platform coverage, interface rendering, system dependencies, update cadence, and configuration migration considerations.
Read the Full Article →Explains battery changes from three angles—persistent VPN service, vendor background restrictions, and per-app proxy scope—and provides background settings to review step by step.
Read the Full Article →Separates system integration from core routing and explains the traffic scope, boundaries, and switching criteria for three common options.
Read the Full Article →