V2Ray Custom Routing Rules: domain, ip, and geosite Syntax and Match Priority
A practical guide to domain, full, regexp, ip, geosite, and geoip rules, including top-to-bottom matching, common conflicts, and ready-to-use examples.
Read article →Choose an open-source client for your device, then configure subscription imports and routing to complete your local proxy setup.
Illustrative client interface · Menus and default ports may vary by client settings
Choose by operating system
V2Ray client downloads
Choose v2rayN for desktop and v2rayNG for Android. Before installing, check your operating system and processor architecture. Download packages, compatibility details, and update information are on the downloads page.
Windowsv2rayN · Desktop / WPF
The desktop edition uses a cross-platform interface, while the classic WPF edition retains its familiar window layout. Both require an imported configuration and system proxy setup.
Go to downloads →
macOSv2rayN · Apple Silicon / Intel
Check your chip under About This Mac first. Apple Silicon and Intel require different installers. After installation, check system proxy permissions.
Go to downloads →
Androidv2rayNG / v2flyNG
Most devices use arm64. If you’re unsure which architecture you have, check the universal build. On first connection, approve the system VPN prompt and review background activity restrictions.
Go to downloads →
Linuxv2rayN · deb / rpm
Choose a deb or rpm package for your distribution, then select x64 or arm64. Check proxy settings in both your desktop environment and the application.
Go to downloads →
The client manages configurations, starts the core, and provides a local entry point. You’ll need to obtain the server address, authentication details, and subscription URL separately. An empty server list after installation usually means no configuration has been imported—it doesn’t indicate an installation failure. A subscription may contain multiple servers; select one as the active configuration before testing the connection.
The same subscription may import differently in different clients due to differences in protocol support, transport settings, and subscription formats. Keep your original configuration when switching clients. Test one server first, then import the full subscription. Device architecture determines whether an installer can run; protocol compatibility determines whether a configuration can connect. Check these separately.
Client setup
Subscriptions, proxy, and routing
First check whether requests are reaching the client, then decide how they should be routed. The settings below follow a typical setup sequence, one step at a time.
Subscription groups and server updates
Subscription groups keep servers from the same source together, making them easier to update, filter, and remove independently. Open “Subscription Group Settings,” enter a label and the full subscription URL, then select “Update All Subscriptions (without proxy).” If your current network can’t reach the URL, check whether you need to update through an existing proxy. A successful update doesn’t guarantee that a server is reachable: select an active server and test a real request. Groups are easier to maintain than pasting configurations one by one, but subscription URLs grant access and shouldn’t appear in screenshots or public logs.
Subscription Groups → Subscription Group Settings
Subscription Groups → Update All Subscriptions (without proxy)System proxy and local listeners
The system proxy directs apps that follow system settings to the client’s local listening port. Select a working server, choose “Set system proxy,” then open a target site in your browser to test it. This doesn’t capture traffic from every app; programs with their own network settings may still connect directly. System proxy is easier to monitor than TUN, making it a good starting point. If another client is using the local port, exit the duplicate process first. Clear the system proxy before closing the client normally to avoid leaving apps pointed at an unavailable endpoint.
System Proxy → Set System Proxy
Settings → Parameter Settings → Local Listening Port
System Proxy → Clear System ProxyRouting modes and rule order
Routing determines whether requests that have reached the core are proxied, sent directly, or blocked. It operates separately from the system proxy, which controls the traffic entry point. For everyday use, start with “Bypass mainland China,” then route traffic by domain and address. To troubleshoot a single site, temporarily switch to “Global” and compare. Global mode only changes how traffic entering the core is handled; it doesn’t capture apps that ignore the system proxy. Rules can express more specific needs than entering a single proxy address in an app. Keep custom rules as specific as possible, and remember that an earlier match may override later rules.
Routing → Bypass mainland China / Global
Settings → Routing Settings
Check rules: destination domain → matching rule → outboundTUN mode and traffic coverage
TUN uses a virtual network interface to capture traffic from apps that don’t follow the system proxy. Before enabling it, use the system proxy to confirm the server works, grant the permissions requested by the client, and check that required components are installed. TUN affects more system routing and DNS behavior than the system proxy, and can conflict with other VPNs, virtual adapters, or network management software. If local network access fails after enabling it, turn TUN off and retest before changing multiple routing rules. Desktop and Android clients use different VPN mechanisms, so their settings and permission steps aren’t interchangeable.
Main Window → Enable TUN
Check in order: working server → permissions → DNS → routing
Compare results: turn off TUN and test againCore selection and configuration compatibility
The graphical client provides the interface; the core parses configurations and establishes connections. v2rayN can use different cores depending on the configuration type, and available options depend on what’s installed. Before switching, check the server’s protocol, transport, and security settings rather than judging compatibility by name alone. Startup logs can reveal unsupported fields or configuration parsing errors faster than repeatedly switching clients. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. They are different implementations, so support for an extension in one doesn’t guarantee the other accepts the same configuration.
Settings → Parameter Settings → Core Type
Check for Updates → Check for Client and Core Updates
Runtime Logs → Configuration Parsing / Core Startup DetailsMove between devices and verify independently
Using clients across platforms usually means importing a subscription again or exporting and importing a configuration—not relying on built-in cloud sync. When moving, separate reusable server settings from device-specific options: re-enter the subscription URL if authorized, and configure local ports, system proxy, and TUN permissions on the new device. This makes differences in paths and architecture easier to spot than copying the entire application folder. Routing rules can be reused only if both clients support the same syntax. After importing, test one server, check DNS and routing, and store exported files securely.
Old device: Export configuration / Save subscription URL
New device: Import configuration → Select server → Test connection
Configure separately: local port / system proxy / TUN permissionsTreat “Connected” as a series of checkpoints. A running core means the configuration has started processing. A listening local port means the app has an available entry point. Only access to the target site confirms that the full path used by that request works. Startup logs alone don’t prove that every server or app is working.
Change one setting at a time and keep track of the previous state. If a browser works but another app doesn’t, first check whether that app follows the system proxy. If no apps work, check the active server, port, and core logs. Separating entry-point issues from forwarding issues makes troubleshooting easier than changing protocols, DNS, and routing all at once. For platform-specific checks, see the cross-platform installation and setup guide.
First-time setup
V2Ray setup in three steps
Import a configuration, set the traffic entry point, then test the connection. Get one connection working with minimal changes before adding routing rules or TUN.
-
Import a subscription and select an active server
Get a working subscription URL. In v2rayN, save it under “Subscription Group Settings,” then update the subscription. Once the server list appears, select an entry and set it as the active server. On Android, use the v2rayNG add menu to import a configuration or manage subscriptions, then update the subscription. QR codes, the clipboard, and subscription URLs are different import methods—use the one that matches what you have.
If the list is empty, check that the URL is complete and hasn’t expired, and look for fetch errors in the update log. Don’t import the same URL repeatedly and create duplicate groups; duplicates don’t improve availability and can make test results harder to interpret. Treat subscription URLs as credentials.
-
Enable the proxy and confirm the traffic entry point
On desktop, first select “Set system proxy” and start with “Bypass mainland China” for routing. On Android, tap Connect and approve the system VPN prompt. If another VPN is already running, check which app currently controls the connection. These steps let the client receive requests from the relevant apps.
You don’t need to enable every option during initial setup. If system proxy works for your browser, stick with it for now; investigate TUN only if you need to capture apps that ignore the system proxy. Multiple proxy clients on one device may compete for local ports or overwrite system settings. Keeping just one client active makes test results easier to interpret.
-
Test access and use logs to find issues
Open a target site, then check the client logs for the corresponding connection. Latency tests help compare response times on your current network, but a failed test doesn’t necessarily mean the server is unusable, and a successful test doesn’t prove every site will open. Test with the apps you actually use and confirm that routing behaves as expected.
For a timeout, check the server address, port, and network first. For a handshake failure, check the clock, TLS, and configuration parameters. If a port is in use, exit duplicate processes. Record the configuration that worked. After an update or migration, restore that known-good setup first, then make changes one at a time.
Open-source ecosystem and client roles
Project V, V2Fly, and Xray
V2Ray is often used as an umbrella term for the ecosystem. When downloading, distinguish the graphical client, proxy core, and server configuration: each has a different role.
Project background and core families
Project V built a technology ecosystem around modular network proxy tools, with V2Ray as one widely used implementation. The V2Fly community continues to maintain V2Ray-related implementations and documentation, while Xray developed from the same technical roots into a separate core project. They share some concepts and configuration conventions, but their features, transport support, and configuration details differ. They aren’t interchangeable versions of the same program.
For users of graphical clients, core differences mainly affect whether a protocol or extension is recognized and whether generated configurations meet the core’s requirements. Server parameters must match the core used by the client. If you encounter an unfamiliar transport, check its support before updating the client or changing cores; repeatedly reinstalling the same package won’t help.
Open-source roles of the three clients
v2rayN is an open-source graphical client for desktop, handling server management, subscription updates, system proxy, and routing. It’s suited to managing connections from a computer. v2rayNG is for Android and uses the Xray core; it’s commonly used to import configurations and connect through the Android VPN service. v2flyNG is also for Android and uses the V2Fly core, making it an alternative when an existing configuration is compatible with that core.
These three clients aren’t server services and don’t provide connection details automatically after installation. They help you create and manage local configurations; the imported data determines the remote connection. The same client name doesn’t mean the subscription sources are the same, and a protocol listed in a subscription doesn’t guarantee that every client supports all its extensions.
Open-source licenses and community maintenance
Open source means source code is available under applicable licenses; use, modification, and redistribution must still follow each project’s terms. The V2Ray and Xray cores use the MPL-2.0 license. Check the license notices included with each client and its dependencies. Open-source licenses govern how code may be used; they don’t replace your own judgment about subscription sources, server permissions, or local privacy settings.
Communities typically maintain the interface, core, and documentation separately. A feature may appear in a core before the client adds a setting for it, or may require a newer configuration format. When reading release notes, check which layer has changed. If the interface has no matching option, that doesn’t necessarily mean the protocol is unsupported. Don’t copy fields from another core into your current configuration without checking compatibility.
Keep a verification path before and after updates
Updating the client, updating the core, and updating a subscription are three different actions. A client update changes the interface and management logic; a core update affects connection capabilities and configuration parsing; a subscription update changes the server list or its parameters. When troubleshooting, noting which update you just performed helps narrow down the cause. Don’t replace the application, subscription, and routing rules in the same test cycle.
Before updating, save essential configurations and custom rules. Afterward, test a server that worked before, then check commonly used sites, local network access, and app proxy behavior. If only one app fails, check its traffic entry point first. If a configuration error appears on startup, check core compatibility. This site brings together client downloads and graphical interface instructions; connection services still depend on the configuration source you choose.
Configuration notes and troubleshooting
V2Ray guides
Once your basic connection works, browse articles for specific issues. Routing guides explain where requests go, log guides help identify failures, and beginner FAQs review the setup steps.
How to Read v2rayN Runtime Logs: Common Errors and Troubleshooting
Understand the structure of Xray core logs and learn how to interpret common errors such as port conflicts, handshake failures, and timeouts to distinguish configuration, network, and server issues.
Read article →10 v2rayN Questions for Beginners: Subscriptions, System Proxy, and Connection Problems
Answers to 10 common questions about getting started with v2rayN, including where to enter a subscription URL, which system proxy option to choose, and what to check when a browser can’t connect.
Read article →