Start by choosing a client, follow the steps to complete subscription import and proxy configuration, then check that applications access the network as expected.
Open-source codeConfiguration guidesClient and core layers
AddressEnter the link provided by your subscription provider
Routing Settings
Rules determine the request's outbound path
DomainIP
DNS Settings
The resolution path must match the routing policy
ResolveOutbound
TUN Mode
Virtual network adapter and traffic takeover
Check permissions Check routing
System proxy options ↘
System Proxy
Expanded options overview
Clear system proxy
Automatically configure system proxy
Leave system proxy unchanged
System proxy and TUN cover different traffic scopes
Settings overview is not a screenshot of an active session; options do not indicate default states.
GUI clientsv2rayN · v2rayNG · v2flyNG
Core familiesXray · V2Fly
Configuration orderImport → Take over → Verify
Confirm your device, then choose the right package
V2Ray Client downloads
Start with v2rayN on desktop; for Android, check v2rayNG first, and consider v2flyNG when you need the V2Fly core. Before downloading, confirm the system architecture, installation permissions, and compatibility with existing settings. The client manages configuration, but a working connection still requires valid server information.
v2rayN offers a modern cross-platform desktop edition and a classic WPF edition. For a first installation, compare the interface and system requirements. If you already have an established setup, first confirm that your subscription groups, routing rules, and core settings can be migrated before switching interfaces.
Check the architecture under “System type” in your system settings. This site provides x64 packages; do not infer the architecture from the computer brand alone. After installation, use standard permissions to complete import and system proxy checks. If you need TUN, verify the required permissions separately. Export your configuration before upgrading, and do not let two instances modify the system proxy at the same time.
With the v2rayN desktop client, check the chip under “About This Mac”: choose arm64 for Apple Silicon and x64 for Intel. Package architecture and subscription protocol are separate concerns; successful subscription import does not prove that the package architecture is correct.
If a system security warning appears on first launch, review the file source and warning details, then use the system-provided procedure. Do not disable the entire security layer. After configuring the system proxy, existing browser sessions may need to reconnect. If an application has its own proxy setting, check whether it overrides the system configuration.
Prefer v2rayNG with the Xray core; v2flyNG, which uses the V2Fly core, is an alternative. Most newer devices suit arm64. When the architecture is unclear, check the universal build and its documentation. Protocol support depends on the selected core, so the two apps are not interchangeable for every configuration.
The first proxy startup usually requires approval for the system VPN permission. This allows the app to create a local traffic-takeover channel; it does not mean the server is connected. If another VPN app is active, decide which app should handle traffic first. If background operation stops, check battery restrictions and logs before changing other background settings.
Devices with a graphical desktop can use v2rayN. Choose a deb or rpm package for the distribution, then match x64 or arm64. Package format describes installation; processor architecture describes the runtime environment. Both must match—do not rely on the file extension alone.
Desktop environments differ in their system proxy support, and browsers, terminals, and background services may read different settings. Verify one application with clear proxy support first, then handle other programs. For router or gateway deployment, understand the boundaries of gateway and DNS takeover first; do not treat desktop client installation as a gateway solution.
Get one configuration working before adding routing, DNS, or takeover rules. Interface options help organize settings, but they do not replace server parameters or remove differences between network environments. The sections below explain each common setting and the recommended order for checking it.
ActionPurpose and usageRequirements and common pitfalls
Subscription Management
Enter the provider's address in a subscription group, save it, run an update, and check that the expected configurations appear in the group. Updating a subscription only retrieves node information; it does not prove that a node is reachable or replace the step of selecting the active node. Create groups by source and keep manual configurations separate to avoid confusion during updates. Addresses often contain access credentials, so hide the full link when troubleshooting and never include it in public screenshots or notes.
Requirements: a valid subscription from a trusted source and access to its update address. If import fails, determine whether the network request failed, the returned content is unsupported, or the link has expired. Pasting the same address repeatedly will not change its format.
System Proxy
After selecting “Automatically configure system proxy,” the client provides a local proxy endpoint for applications that follow system settings. This is useful for testing browser access, but it does not take over every program. “Leave system proxy unchanged” preserves the current system state; it does not restore a direct connection automatically. To undo takeover, explicitly clear the system proxy, then check the system settings. Network problems after the client exits may also come from a leftover proxy endpoint.
Requirements: the local proxy service is running and the target application reads the system proxy. Built-in application proxies, extensions, or other network tools may override the setting; keep one clear configuration source at a time.
TUN Mode
TUN receives traffic through a virtual network adapter and can handle applications that ignore the system proxy, but its actual scope still depends on routing, exclusion rules, and permissions. First confirm that a normal proxy connection works, then try virtual adapter takeover to separate server issues from system takeover issues. If LAN devices, remote desktop, or certain services become unreachable, check direct-connection rules and subnet exclusions instead of immediately changing the subscription.
Requirements: the system grants the necessary network permissions and the relevant components work correctly. Other VPNs, virtual adapters, or security software may affect routing. Preserve the original settings before making changes and prepare a way to disable TUN.
Routing
Routing uses conditions such as domains and IPs to decide which outbound path a request takes. First understand the difference between direct, proxied, and blocked traffic in the existing rules, then add rules for specific needs. Pay attention to match order: broad rules may override more specific conditions. When using GeoIP or GeoSite, ensure that the database and tags are available. Global proxy changes how requests already inside the core are sent out; it cannot bring an application that is not being taken over into the core automatically.
Requirements: a clear decision about which requests should connect directly and which should use the proxy. After changes, retest with the relevant domains and logs; one accessible website is not enough to prove that every rule works as intended.
DNS Settings
DNS resolves domains to addresses, but requests may be initiated separately by the application, system, or core. First identify which layer performs the resolution, then check the resolution request's outbound path and result. Replacing one DNS address does not guarantee that every application will use it. If domain access fails while other connections work, use logs to inspect the resolution path, timeouts, and cache. A browser's own encrypted DNS may also make observations differ from system settings.
Requirements: an understanding of the selected core's DNS rules and how the resolution service is reached. Do not mix configuration fields from different cores. After changing the resolution policy, reconnect and account for caching.
Choosing a takeover method
Use the following as a starting point for verification, not as default configuration advice. The complete set of actions remains in the comparison table above.
Start with the system proxy
Select a valid configuration, start the local service, and set the system proxy. Open a test page in a browser that follows system settings while watching the client logs. Do not add a browser proxy extension during testing, or it will be difficult to determine which path the request used. Add routing rules only after verification. If the browser still cannot connect, check the configuration and local service before enabling more takeover features.
Check application settings first, then consider TUN
When the browser works but an application does not, check whether that application supports its own proxy, ignores system settings, or needs existing connections rebuilt. If it supports a proxy, identify its endpoint first. Consider TUN only when broader takeover is genuinely needed, and then check its permissions and exclusions. Do not attribute a single failed connection to the node before confirming that the application's request reached the client.
First-use verification order
Three-step setup and connection verification
Quick setup covers three stages: subscription, node selection, and making the proxy effective. Interface labels may change between clients, but the goal stays the same: obtain the configuration, select an outbound path, and confirm the actual traffic route used by the application.
01
Import a subscription and confirm its configuration
After installing and launching the client, use the subscription group or import entry to add existing information. The v2rayN desktop client is well suited to organizing groups by source; on Android, start with subscription management or an import function in v2rayNG. Check that the address is complete and contains no extra spaces or line breaks, then update the subscription. After import, confirm that the protocol, server address, and required transport parameters are present—do not rely on the display name alone.
For a single share link, use the corresponding link-import method instead of treating it as a subscription update address. A subscription is an updateable collection of configurations; a node is an individual connection configuration within it. Their entry points and maintenance methods differ. If you have no connection information, ask the service provider; installing a client does not create nodes.
02
Choose a node and one takeover method
Select the configuration to use and confirm that the client has started the corresponding core. On desktop, begin by using the system proxy to test a browser. On Android, approve the VPN permission when prompted, then start the connection. Keep routing simple at first. Do not change the core, DNS, TUN, and routing rules at the same time, or it will be difficult to identify the cause of a problem.
“Selected” and “in use” may not be the same interface state. Confirm the active configuration or start operation using the controls provided by the client, then rebuild the test connection after switching configurations. If you need printers, shared folders, or LAN services, preserve the relevant direct-connection conditions and record the original rules so they can be restored.
03
Cross-check tests, access, and logs
Run the connection test provided by the client, then use the target application to open the real page while watching the logs at the same time. A true connection test usually makes a request through the proxy to determine whether the test target is reachable; download speed tests focus more on throughput, and neither replaces the other. A successful test does not mean every application on the system is being taken over.
If the test fails, distinguish among resolution errors, connection timeouts, authentication failures, and handshake errors. If the test succeeds but the browser fails, check the system proxy and the application's own settings first. Change one item at a time and retest against the same target. Before sharing logs, remove subscription addresses, credentials, and identifiable server details.
First distinguish who manages configuration, who performs forwarding, and who provides the remote connection. Understanding these three roles is more useful for choosing software and troubleshooting than looking only at protocol names or a client's appearance.
The relationship between Project V, V2Fly, and Xray
Project V is an open-source ecosystem built around proxy and network communication tools, with V2Ray as one of its major projects. The V2Fly community continues to maintain V2Ray-related implementations, while Xray has developed its own features and configuration system from related technical foundations. They share background, but not every feature or field is interchangeable. When following a guide, confirm both the core supported by the client and the configuration supplied by the server rather than copying instructions solely because they mention “V2Ray.”
For connections involving REALITY, confirm that the selected core supports it and import the parameters supplied by the server. A protocol name does not determine connection speed; network paths, server resources, transport settings, and device conditions can all affect the result. Once the protocol's role is clear, checking configuration compatibility is usually more effective than repeatedly switching clients.
Usage boundaries of the three open-source clients
v2rayN provides a desktop configuration management interface; its specific core and features depend on the distribution and configuration in use. v2rayNG targets Android and uses the Xray core. v2flyNG also targets Android and uses the V2Fly core as an alternative. All three clients are developed as open-source projects. For everyday users, open source means the implementation can be reviewed, changes can be understood, and issues can be reported; it does not mean every subscription source is trustworthy.
Open-source licenses define the conditions for using, modifying, and distributing code, and clients and cores may use different licenses. Everyday installation and use are not the same responsibility as redistributing a modified build. If you plan to redistribute anything, read the applicable project licenses and dependency notices individually. This site is an independent Chinese download and usage guide, not the official website of these open-source projects and not a statement from their maintainers.
Updating the client, core, and rule databases
A client update may change the interface or configuration generation, a core update may change protocol behavior, and GeoIP or GeoSite updates may change the data referenced by rules. These are not different names for one operation, and they do not need to be updated together during troubleshooting. Record the current working configuration, read the change notes, and update only what is necessary. Afterward, retest with the original targets and confirm that subscriptions, system takeover, and LAN access still behave as expected.
Community maintenance usually advances through public code and change records, and release schedules vary by project. This site does not permanently label one download source as the best choice or display version information on the home page that may quickly become outdated. Packages are centralized on the download page, while platform differences and configuration issues are covered in the all-platform guide, so each stage can be found directly instead of piecing together scattered steps across pages.
Background operation, deployment, and rule maintenance
Once the basic connection works, read further based on the issue you encounter. These articles cover Android background battery use, Linux gateway takeover, and routing database maintenance separately rather than treating one setting as a universal answer for every network environment.
Use Android battery statistics and connection logs to distinguish continuous traffic, frequent reconnections, and battery drain caused by background restrictions. Choose a background operation strategy by observing, changing one setting, and testing again.
For pre-deployment planning, explains the roles of the gateway, DNS, forwarding, and core; compares traffic paths through a main router and secondary gateway; and reviews permissions, resource use, and rollback preparation without expanding the client recommendation list.
Distinguishes IP classification databases from domain classification databases, covers client update paths, core compatibility, and rule-tag references, and explains how to identify load failures in logs and restore the previous routing behavior.