11"flow": "xtls-rprx-vision"flow applies only to VLESS with TLS or REALITYoutbounds → users → flow
12 }]
13 }]},
14"streamSettings": {
15"security": "reality",
16"realitySettings": {
17"serverName": "example.com"
18 }
19 }
20 }, {"tag": "direct",
21"protocol": "freedom"}],
22"routing": {
23"domainStrategy": "IPIfNonMatch",IPIfNonMatch matches the domain first, then resolves its IP if there's no matchrouting → domainStrategy
24"rules": [{
25"type": "field",
26"domain": ["geosite:cn"],geosite:cn comes from the client's bundled geosite.datrouting → rules → domain
27"outboundTag": "direct"
28 }]
29 }
30}
Excerpt: outbounds handle connections; routing selects an outbound. Connection parameters must come from your service provider.
JSON · UTF-8 · Xray-core configurationExcerpt · Not ready to connect
Start here / CONFIG
The client manages profiles, the core handles connections, the system proxy routes traffic in, and routing rules decide where it goes.
V2Ray Official Download organizes downloads and guides around this workflow. Choose a client for your device, import a subscription or server profile from your service provider, then confirm that app traffic is actually passing through the proxy. Installing the software does not provide working connection details, and seeing the client running does not mean every app is using the proxy.
The editor above shows an excerpt of an Xray configuration to illustrate outbounds, transport security, and routing rules. The example domains and identifiers are for explaining fields only; other parameters required by REALITY are omitted. With a graphical client, the core configuration is usually generated by the interface, so you typically don't need to copy this example into a configuration file.
Explore six common settings in this order: configuration sources → traffic entry points → matching rules → connection diagnostics. Menu labels may vary slightly between layouts. Configuration fields illustrate the concepts; they don't imply that every core uses the same syntax.
Subscription group → Subscription group settings
Manage server profiles by source
A subscription URL points to a remote configuration list; it isn't an individual server address. Add a group, enter the subscription link, save it, and refresh the list. Then select an active server. Groups help distinguish configuration sources and set separate refresh intervals. Unlike pasting shared links one at a time, a subscription can sync additions and removals from the server list, but updates may overwrite local edits to subscribed entries. If an update fails, check that the URL is valid, then compare direct updates with updates through the proxy. Don't rely on a server that isn't working yet.
Subscription URLAuto-refresh intervalGroup notes
Main window or tray menu → System proxy
First check whether apps use system proxy settings
When you set a system proxy, the client writes its local listening address to the operating system's proxy settings. Apps that read those settings, such as browsers, can then send requests to the local proxy. This is separate from global proxy mode in the core's routing settings, and it won't automatically cover every program. For your first connection, test with a browser using the system proxy. Clear the system proxy before exiting the client. If the client is closed but the browser still points to a local port, regular websites may stop loading; restore the system network settings first.
Local listening addressHTTP / SOCKSSystem proxy status
Main window → Enable TUN mode
Route traffic through a virtual network interface
TUN handles IP traffic through a virtual network interface, making it useful for apps that don't use the system proxy. Desktop platforms typically require additional permissions, and the traffic it captures depends on routing, exclusions, and DNS settings. TUN isn't a system-proxy accelerator, and it doesn't guarantee that all connections use a remote server. First confirm that the regular proxy works, then check the logs and local network access. If TUN conflicts with another virtual adapter, a corporate network tool, or an existing VPN, disable one at a time to compare results. Changing multiple network entry points at once makes problems harder to diagnose.
Routing rules match domains, IPs, or ports and send traffic to an outbound such as a proxy or direct connection. Most rules are checked in order, so put specific exceptions before broad rules. GeoSite provides domain collections; GeoIP provides IP collections. They serve different purposes. After selecting a preset rule set, check where LAN traffic, internal domains, and target sites actually go instead of relying on the mode name. Routing can preserve direct access to local services, but missing rule files or incorrect tags need to be fixed at the database reference.
domainStrategygeosite:cnoutboundTag
Settings → DNS
Separate DNS queries from application connections
DNS resolves domain names to IP addresses, but DNS queries don't necessarily take the same network path as website connections. Browser Secure DNS, the operating system cache, and core-level DNS can all affect the same request. If a domain won't load but its IP address works, first find out which resolver is being used, then check whether its upstream is reachable. Domain resolution strategies in routing can also affect whether IP rules match. Don't assume changing one DNS server fixed the problem: retest the same domain and distinguish cached results from a fresh query.
dns.serversqueryStrategydomainStrategy
Main window → Logs; Settings → Parameters → Log level
Pinpoint the stage where the error occurs
Logs help distinguish core startup, DNS resolution, server connection, and protocol handshake issues. Note when a test fails, then inspect nearby log entries; that's more useful than searching the entire page for “failed.” Connection refused, connection timed out, and certificate name mismatch are different problems with different fixes. Temporarily increase log detail for diagnosis, then restore the usual level. Before sharing logs, remove subscription URLs, identifiers, and private server details. Treat logs as clues and cross-check them against browser tests and the active server status.
loglevelaccesserror
The order of setup matters more than the number of switches
For your first setup, keep the default routing and DNS settings. Import a subscription and select an active server. Use the real-connection test to confirm that the client can complete a request through that server, then set the system proxy and open a known-accessible page in a browser. Only after this shortest path works should you enable TUN, add custom routing rules, or adjust DNS resolution. Otherwise, several unverified settings make it difficult to tell whether a problem comes from the server or your local network.
“Global proxy” means different things depending on where you see it. In system settings, it usually describes how apps send traffic to a local proxy. In the client's routing settings, global mode determines which outbound handles traffic after it enters the core. If an app doesn't send traffic to the client, global routing won't capture it. Conversely, traffic entering through TUN may still match a direct rule. To check whether the proxy is working, verify both the entry point and the outbound, not just a status icon.
If only one site or app is having trouble, there's no need to reinstall the client right away. Try other pages through the same server, then test a different server profile for comparison. Next, check the domain's routing match and DNS result. Change one thing at a time and keep the logs from before and after the failure. This helps distinguish a total connection failure from a rule affecting only certain traffic. See troubleshooting for detailed steps, or check the glossary for field definitions.
Client downloads by platform
For desktop, choose v2rayN. On Android, start with v2rayNG; consider v2flyNG if you already have V2Fly-specific configuration. The links below show download options for each platform. Package architectures, system requirements, and file details are on the download page.
v2rayN is available as a desktop edition and a classic WPF edition. The desktop edition uses a cross-platform interface, while the WPF edition keeps its familiar window and menu layout. Both manage profiles and launch the core. Choose based on your workflow and system requirements; you don't need to run both clients for the same subscription.
Before installation, check your processor architecture in the system's About settings. On first launch, check the local listening port and system proxy status. If you already use another proxy app, quit it before testing to avoid port conflicts or overlapping system settings. Handle permissions and the virtual network adapter separately if you need TUN.
v2rayN's macOS packages are available for Apple Silicon and Intel. Check your chip in About This Mac and choose the matching architecture. Configuration sources work the same way as on other desktop platforms, but system network settings, launch permissions, and menu locations depend on your macOS version.
After importing a subscription, check the active server and the proxy settings for your current network service. If a browser works but terminal commands still connect directly, they are probably using different proxy entry points; that doesn't necessarily mean the server is down. After switching Wi-Fi networks, check whether your network environment has changed.
v2rayNG uses the Xray core and is the recommended starting point on Android. v2flyNG uses the V2Fly core and suits users with existing V2Fly configurations. Most current devices use arm64; if you're unsure of your architecture, check the notes for the universal package. Protocol support depends on the client and core, so don't judge compatibility by the name of a shared link alone.
For your first connection, approve the system VPN permission. If the connection drops when the screen locks, check battery optimization, background activity, and network switching before troubleshooting the server. App-level routing can change which traffic is captured. Make sure your browser isn't on an exclusion list, and don't run another VPN service at the same time.
v2rayN offers deb and rpm packages for x64 and arm64. Check your distribution's package format and processor architecture before choosing a file. The graphical client is intended for desktop sessions. Whether apps can use the system proxy also depends on the desktop environment and each app's implementation.
Desktop browsers, command-line tools, and background services may use different proxy settings. A successful browser test doesn't prove that every process is covered. When enabling TUN, check permissions, system routes, and other virtual network interfaces. If LAN access is affected, review excluded subnets instead of repeatedly switching servers.
The client manages local profiles, handles protocols, and forwards traffic; it doesn't create a remote service. Your service provider must supply the server address, port, identity parameters, and transport settings needed to connect. Subscription URLs may contain access credentials, so treat them as private configuration. Don't paste them into public screenshots or third-party online converters. When moving to another device, distinguish a single server profile, a subscription URL, and the client's full settings export.
If you already have a working configuration, note the active server, routing mode, and local port before upgrading the client or switching platforms. Keeping a restorable copy makes it easier to identify differences in the new environment. If a protocol field isn't recognized, compare core capabilities and configuration formats. Being part of the Project V ecosystem doesn't mean every client can read another client's complete settings file.
Project V, V2Fly, and Xray
Understand the open-source ecosystem in layers. Projects, execution cores, graphical clients, and remote services each have distinct roles. Confusing these names can lead to mistakes when choosing software or configuring a connection.
Configuration interface → Core execution → Remote service
One ecosystem, distinct roles
Project V provides background for understanding V2Ray-related tools. V2Fly continues V2Ray's community development, while Xray has developed its own core based on related technology. v2rayN, v2rayNG, and v2flyNG are graphical clients that turn subscriptions, server parameters, and mode selections into configurations the core can run. The server-side protocol must still be supported by the client’s core.
The core handles inbound traffic, matches routing rules, and connects according to outbound settings. V2Fly and Xray share some history and configuration concepts, but each maintains its own features and configuration formats; their files aren't interchangeable at will. For combinations such as VLESS, REALITY, and Vision, confirm which core is running rather than checking only the client name.
Protocols, transports, and security layers aren't interchangeable terms. VLESS is a proxy protocol, REALITY is a transport security mechanism, and Vision is a flow-control mode used under specific conditions. Match the full combination provided by the server to the client settings. Selecting VLESS but missing the security layer or flow-control requirements can still cause a handshake failure; changing the port alone won't fix a mismatch.
Open-source licensing of the three clients
v2rayN, v2rayNG, and v2flyNG are open-source clients, with their main client code licensed under GPL-family terms. The V2Fly and Xray cores are primarily licensed under MPL 2.0. The client interface, core, and bundled components may each have separate license terms. Free use, source access, and redistribution are distinct rights. For modifications, redistribution, or integration, consult the relevant project's license.
Choose based on your device and configuration. On desktop, v2rayN manages servers, subscriptions, and routing. On Android, v2rayNG focuses on the Xray ecosystem, while v2flyNG follows the V2Fly path. “Recommended” and “alternative” describe the order of options in these guides; they don't mean the other client is unmaintained or that one core is faster on every network.
Subscriptions, clients, and rule updates
Client upgrades, subscription refreshes, and Geo database updates are three separate maintenance tasks. A client upgrade changes the interface or bundled components. A subscription refresh retrieves the server list from your service provider. A Geo database update changes the domain and IP collections. A successful subscription refresh doesn't prove that routing files are up to date, and updating rule files won't fix an expired subscription URL.
Keep test conditions consistent before and after an update, such as the same active server, routing mode, and test domain. If something breaks, check the startup logs and actual configuration before deciding whether to revert. Don't set automatic refresh too frequently; choose an interval that suits the configuration source. Excessive requests may trigger server-side limits and interfere with normal updates.
What these download and setup guides cover
This site collects client download links and setup guides. The brand name identifies the site; it doesn't mean the site operates Project V, V2Fly, Xray, or any client development project. Software features and licensing are determined by each project, while subscription services and server availability are determined by service providers. These guides explain local settings and network paths; they don't replace server-side configuration instructions.
When reading configuration examples, distinguish instructional fields from actual connection details. Domains, identifiers, and security parameters must match the server; don't guess based on field names. If an imported configuration fails, first determine whether the format is unrecognized, the core failed to start, or the remote connection failed. Then follow the relevant troubleshooting steps. For more on project names and protocol layers, see the glossary; for symptom-based help, see the troubleshooting guide.
Setup guides and technical articles
The latest three articles tackle practical issues in order: confirm subscription requests are working, check the rule databases, then verify the selected server and system proxy. Setup steps and configuration explanations are kept separate so you can find what you need for the issue at hand.
Covers four common causes of failed subscription updates—expired links, network problems, proxy loops, and invalid response formats—and explains how to set an auto-refresh interval for a subscription group.
For cases where your servers are still listed but refreshes fail. First check whether the request returned valid configuration data, then review the update method and interval. Don't import an error page returned by the server as a subscription.
Learn how GeoIP and GeoSite databases support routing, how to update rule files in the client, and how to use common tags such as geosite:cn and geoip:private in rules.
For cases where the client connects but some traffic takes the wrong route. First confirm the tag type and database are available, then check rule order. Domain and IP collections aren't interchangeable just because their names look similar.
After importing a subscription, test real connections to find a working server, switch to system proxy mode, then use a browser and command line to confirm that traffic is actually using the proxy.
For anyone who can see a server list but isn't sure what to do next. Test results reflect the connection at that moment and don't replace testing in your actual apps. After choosing a server, make sure the traffic entry point is configured correctly.