CLIENT / ROUTING / DNS
A central starting point for installing v2rayN, v2rayNG, and v2flyNG, with coverage of subscription imports, routing, and DNS setup for desktop and Android clients.
CLIENT OPERATIONS
Client setup is more than pasting in a single link. Subscription updates, server filtering, route matching, DNS egress, and TUN capture all affect the connection result.
MODULE / 01
A subscription URL retrieves server configurations in bulk. After importing one, run an update, then organize servers by protocol, region, or custom notes instead of searching through a long list. v2rayN supports subscription groups and filters, while v2rayNG is better suited to maintaining a small set of frequently used groups on Android. If an update fails, distinguish an expired link, a request that needs a proxy, an incompatible response format, or a client permission issue before deleting existing settings. Once the update completes, select a server and make it active; having a subscription does not mean a server is in use.
View the subscription import steps →MODULE / 02
Routing rules determine where traffic goes based on domains, IPs, ports, network types, and process information. A common approach is to define LAN and required direct connections first, then proxy rules, and finally keep one explicit default outbound. Rule order matters: earlier matches are usually applied first, so narrower rules should come before broader groups. GeoIP and GeoSite provide matching data, not connection protocols; after updating the data, confirm that the rule names are recognized by the client core. Export the current configuration before editing, then verify each change with specific domains.
Read the practical routing guide →MODULE / 03
DNS settings determine how domains are resolved and also affect domain-based routing rules. Clients can usually specify local DNS, remote DNS, query strategies, and DNS outbounds separately. If system resolution differs from the resolution used for proxy connections, domain rules may match unexpectedly, connection targets may change, or applications may retry repeatedly. Make clear which queries use the local connection and which are handled through the proxy, and check whether the IPv4 and IPv6 policies fit the current network. Before enabling FakeDNS, confirm application compatibility and the scope of TUN capture.
View the DNS configuration guide →MODULE / 04
TUN mode captures more system traffic through a virtual network interface. It suits applications that cannot read system proxy settings and scenarios that require routing rules to be applied consistently. Its coverage differs from a standard system proxy; enabling it often requires extra permissions and may conflict with network filters, virtual adapters, or security policies. For the first setup, keep the rules simple. Confirm that websites, command-line tools, and common applications connect normally before adding process rules, DNS hijacking, or FakeDNS. Restore related network settings before stopping the client to reduce troubleshooting work at the next startup.
Continue reading about TUN mode →MODULE / 05
When connections fail, subscriptions stop updating, or rules have no effect, break the problem into six layers: client, subscription, server, core, DNS, and local network. Timestamps, outbound tags, domains, and error types in the logs are more useful for diagnosis than a single speed test. Export subscription groups, routing, and DNS settings before updating the client. Afterward, test the original configuration first, then decide whether to enable new options. If only one application fails, compare system-proxy and TUN capture behavior; if every server fails at once, check the local network, subscription status, and core startup logs first.
Open the advanced troubleshooting guide →PLATFORM DOWNLOADS
v2rayN is the main desktop option, while Android users can choose between v2rayNG and v2flyNG based on core requirements. Download packages, CPU architectures, and system requirements are grouped on the download page.
DESKTOP / WPF
Windows users can choose the next-generation v2rayN desktop interface or the classic WPF interface. Both support subscription management, system proxy settings, routing rules, and core control. New installations can start with the desktop version, while users with a stable setup can continue with the familiar WPF workflow.
Go to downloadsDESKTOP / DMG
On macOS, use the v2rayN desktop client and choose an Apple Silicon or Intel package according to the device processor. After installation, import subscriptions, switch the system proxy, and edit routes. If macOS blocks the first launch, confirm the application permission in Security settings.
Go to downloadsMOBILE / APK
v2rayNG is the first choice for Android, using the Xray core for common protocols and routing settings; choose v2flyNG when the V2Fly core is required. Most modern devices use arm64 packages. If the processor architecture is unknown, choose a universal package to avoid downloading a file that does not match the device.
Go to downloadsDESKTOP / DEB · RPM
On Linux desktops, use v2rayN and choose a deb or rpm package according to the distribution, then select the x64 or arm64 architecture. After installation, pay attention to the desktop environment, how system proxy settings are written, and TUN permissions. On servers, focus on configuration and service management rather than copying desktop steps.
Go to downloadsQUICK START
For the first setup, complete the shortest connection path before handling routing, DNS, and TUN. This confirms whether the basic connection works and avoids making several changes at once, which makes diagnosis harder.
View the complete guide →Copy the complete subscription URL, add a record in the client's subscription group, and run one manual update. When it finishes, check that servers appear, notes are readable, and protocol fields are recognized correctly. If the list is empty, troubleshoot the subscription response before changing system proxy settings.
Select a configuration from the server list and make it active, then choose system proxy or TUN mode based on your needs. For the first connection, keep routing rules simple and test a browser and common applications. Once the basic connection works, switch routing modes and add custom direct or proxy conditions.
After starting the connection, check the client status and core logs to confirm that local listening ports are established. Then test domain access and applications that require a proxy separately. If the connection toggle is on but an application remains inaccessible, check whether it reads system proxy settings, whether DNS uses the expected outbound, and whether the rules send the traffic to the correct outbound.
PROJECT V / CORE FAMILY
The client provides the graphical interface and system integration; the core handles protocols, transports, routing, and outbound processing. Understanding this division makes client release notes and configuration compatibility easier to interpret.
Project V is an open-source technology ecosystem built around proxy protocols, transport layers, routing, and network tools. It is not the same as any one graphical client. Desktop and mobile clients provide subscription management, connection controls, system proxy settings, log viewing, and configuration editing; the core called by the client performs the actual network processing. Servers, routing rules, and DNS options shown in the interface are ultimately assembled into configuration that the core can read.
V2Fly continues the core capabilities of the V2Ray family, emphasizing open protocol combinations, transport settings, and routing. Xray developed from the same technical family into an independent core, with its own direction in areas such as VLESS, XTLS, and REALITY. The two cores share many basic configuration concepts, but their feature support, field details, and release schedules are not identical, so compatibility cannot be judged from the appearance of a configuration file alone.
v2rayN is a desktop graphical client that can manage multiple cores and subscription groups; v2rayNG is mainly used on Android with the Xray core; v2flyNG targets the V2Fly core. All three clients are maintained as open-source projects, with client and core projects releasing updates independently. When a protocol is not recognized or a new field cannot be saved, check both the client's supported range and the selected core's capabilities.
v2rayN, v2rayNG, v2flyNG, and their commonly used cores have clearly defined open-source licenses. These licenses set the terms for using, modifying, and redistributing code, while source code, commit history, and release notes allow the technical community to review changes. This site relies on actual client features and public documentation rather than substituting download counts, ratings, or unverifiable test figures for technical information.
Client updates commonly affect the interface, subscription management, system proxy integration, and configuration generation. Core updates may add protocol capabilities, change configuration fields, or fix network-processing issues. Their release cycles differ. When diagnosing connection problems, record the client name, core family, operating mode, and log errors instead of describing only whether the connection button is enabled.
VMess, VLESS, Trojan, WebSocket, gRPC, TLS, and REALITY belong to different protocol, transport, and security layers and cannot replace one another. When converting subscriptions or migrating between clients, confirm that the target client recognizes every field. If flow control, transport parameters, or the server name are lost during conversion, the connection may behave differently from the original client.
COMMON QUESTIONS
These questions cover four common points of failure: the first import, client selection, failed updates, and no traffic after connecting. Complete procedures are available in the user guide and advanced manual.
First confirm that you added a subscription group rather than a single server, then run a manual update. If the update reports an empty or unrecognized response, check that the URL is complete, the link still works, and whether updates through a proxy are required. Do not keep changing routing rules before the subscription has returned content.
View the import steps →Choose v2rayNG when you need capabilities associated with the Xray core; choose v2flyNG when you specifically need the V2Fly core or already have matching configuration. Their interfaces are similar, but core support and some fields differ. After migrating a subscription, check that protocol, transport, security, and routing settings were preserved completely.
View the Android clients →First check whether the application reads system proxy settings; if it does not, consider TUN mode. Then check the active server, the default routing outbound, DNS resolution, and local listener status. If only one application fails, focus on its proxy support and network permissions instead of rebuilding every subscription.
Troubleshoot by layer →Check the rule order, domain matching type, outbound tags, and whether GeoIP and GeoSite data are consistent. Existing connections may continue using the old path, so reconnect before testing. If the logs show the target domain and matched outbound, you can determine whether the problem is in the rule conditions or the subsequent connection stage.
Read the routing guide →TECH NOTES
Further coverage of FakeDNS, DNS leaks, and core differences, including use cases, configuration steps, and a structured troubleshooting order.
Breaks down virtual IP mapping, domain restoration, and routing decisions, including application compatibility limits when used with TUN mode.
Read the full article →Starts with interpreting test results, then adjusts remote DNS, DNS outbounds, and TUN capture scope before retesting the resolution path.
Read the full article →Compares the focus of the two core families, their common configuration areas, and how the three graphical clients select a core.
Read the full article →