Subscription Groups & Server Filtering
Subscription groups are the basic way to manage multiple provider subscriptions or self-hosted servers in v2rayN. Many users start by adding just one subscription and mixing all servers together. Once the number of servers exceeds a few dozen, finding a server in a specific region becomes a hassle. Subscription groups solve this problem: they put servers from different sources into separate groups, and each group is independent - updates, filtering, and latency tests are all done per group.
In the v2rayN main window, open the "Subscription Groups" menu and go to "Subscription Group Settings". Here you can create new groups and name them, such as "Primary Provider", "Backup Self-hosted", or "Work Only". Each group can be bound to one or more subscription URLs. Once bound, v2rayN will place the servers fetched from that subscription into the group. The server list in the main window will display as a tree structure by group; expand a group to see all servers under it.
Another useful feature of groups is independent auto-update intervals. In Subscription Group Settings, you can configure a separate update interval for each group - for example, the primary provider updates every 12 hours, while the backup self-hosted group updates every 24 hours. v2rayN will automatically fetch the subscription in the background according to this interval, so you don't need to manually click refresh. Even if one subscription temporarily fails, it won't affect the normal updates of other groups.
Server filtering is a natural extension of subscription groups. When you have many servers, the filter box above the server list can filter by protocol type (VMess / VLESS / Trojan / Shadowsocks), and also sort by latency, region, or group. After filtering, you can select all at once and run a batch latency test. When testing latency, it's recommended to change the test URL in "Settings - Parameter Settings" to an address you actually visit, such as a common webpage or a 204 page. This way the measured latency is closer to real-world experience. Some servers handle the default test URL specially; changing the target address can help avoid false judgments.
Combining subscription groups with server filtering creates a very practical workflow: first group by subscription source, then filter within the group by protocol or latency, and finally lock in the filtered results using "Server Sorting" in Settings. For daily use, you just expand the relevant group and pick the server with the lowest latency.
If you want to understand subscription groups at the config file level, v2rayN's guiConfig.json has a subItem array, where each element represents a subscription item. Below is a simplified example showing the basic fields of a subscription item:
{
"subItem": [
{
"id": "a1b2c3d4",
"remarks": "Primary Provider",
"url": "https://example.com/subscribe?token=xxxx",
"enabled": true,
"autoUpdateInterval": 12
},
{
"id": "e5f6g7h8",
"remarks": "Backup Self-hosted",
"url": "https://home.example.net/sub",
"enabled": true,
"autoUpdateInterval": 24
}
]
}The url field is the subscription link, remarks is the display name, enabled controls whether the subscription participates in updates, and autoUpdateInterval is the auto-update interval in hours. Before manually editing this file, it's recommended to close v2rayN first, then reopen it after editing, to prevent the GUI from overwriting your changes.
Practical Routing Rules
Routing rules determine where traffic goes: direct, through the proxy, or blocked. For most users, the default "Bypass Mainland" rule is sufficient. But if you need finer-grained splitting - for example, forcing certain domains through the proxy or forcing certain IP ranges to go direct - you'll need to edit the routing rules manually.
Routing rules rely on two data sets: geosite is a domain set, and geoip is an IP set. For example, geosite:cn contains common domains in mainland China, and geoip:cn contains IP ranges in mainland China. v2rayN's built-in rule templates are assembled from these two sets. In "Settings - Routing Settings", you can directly choose a built-in template, such as "Global Proxy", "Bypass LAN", "Bypass Mainland", etc.
If the built-in templates don't meet your needs, you can edit the routing section of config.json. Routing rules are an array that is matched one by one from top to bottom. The first matching rule takes effect, and subsequent rules are not executed. Therefore, the order of rules is very important: usually put direct rules at the top, and proxy rules at the bottom as a fallback.
Below is a typical rule set for "mainland China direct, outside China through proxy":
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{ "type": "field", "domain": ["geosite:cn"], "outboundTag": "direct" },
{ "type": "field", "ip": ["geoip:cn"], "outboundTag": "direct" },
{ "type": "field", "domain": ["geolocation-!cn"], "outboundTag": "proxy" }
]
}
}domainStrategy controls the order of domain matching. The default value is AsIs, which only matches by domain. If you change it to IPIfNonMatch, when a domain doesn't match any domain rule, v2ray will first resolve the domain's IP, then use the IP to match geoip rules. This covers domains not included in geosite, at the cost of one extra DNS resolution on first access.
The logic of the three rules is: first match mainland China domains and go direct; then match mainland China IPs and go direct; finally match "domains not in mainland China geographic locations" and go through the proxy. Here geolocation-!cn is a special domain set built into v2ray, equivalent to "domains covered by geographic locations outside China".
When rules don't take effect, troubleshoot in this order: First, confirm that the value of outboundTag exists. v2rayN's default proxy outbound tag is proxy, and the direct outbound is direct. If you changed the tag when creating a custom outbound, you must update the routing rules accordingly. Second, check the rule order. If a rule is placed after a broader rule, it may never be matched. Third, check domainStrategy. If a domain doesn't match any domain rule and IPIfNonMatch is not enabled, the domain won't go through geoip matching and may be missed. Fourth, confirm whether the domain is actually in geosite. Some obscure domains are not included; you need to manually add the domain to the rules, such as "domain": ["example.com", "geosite:cn"].
Routing rules combined with subscription groups can achieve very fine-grained traffic scheduling: use the nodes of a certain group as "Work Only", and in the routing rules point work-related domains to that group's proxy outbound. This is more stable than manually switching nodes.
For a more complete configuration example of mainland China vs. outside China routing, refer to our blog post "v2rayN Routing Rules in Practice: A Complete Split-Traffic Solution for Mainland China Direct and Outside China Through Proxy".
DNS Configuration Optimization
DNS resolution is the first step of network access. In a proxy scenario, DNS results can affect traffic direction: if DNS is polluted, even if the proxy node is working normally, you may experience "connected but can't open websites". Therefore, DNS configuration optimization is a very critical part of advanced setup.
v2rayN's DNS settings are located in "Settings - Parameter Settings". The interface usually has two input fields: "Remote DNS" and "Local DNS". Remote DNS goes through the proxy network and is used to resolve domains outside China; local DNS goes through the direct network and is used to resolve domains in mainland China. Common remote DNS servers include 1.1.1.1 and 8.8.8.8; common local DNS servers include 223.5.5.5 (Alibaba) and 119.29.29.29 (Tencent).
If you want more fine-grained control over DNS queries, you can edit the dns section of config.json. Below is an example of routing DNS queries by domain:
{
"dns": {
"servers": [
{ "address": "1.1.1.1", "domains": ["geosite:geolocation-!cn"] },
{ "address": "223.5.5.5", "domains": ["geosite:cn"] },
{ "address": "8.8.8.8" }
]
}
}This configuration means: domains outside mainland China (geosite:geolocation-!cn) are resolved using 1.1.1.1; mainland China domains (geosite:cn) are resolved using 223.5.5.5; other unmatched domains use 8.8.8.8 as a fallback. Here the domains field is optional; if omitted, that server acts as the default fallback.
DNS leak prevention is another important topic. If the system proxy doesn't take over all traffic, some browser extensions or background apps may bypass the proxy and send DNS queries directly to the system DNS, resulting in polluted resolution. There are two solutions: one is to use TUN mode (covered in the next chapter) to take over all traffic; the other is to check the "Prevent DNS Leak" related option in v2rayN's DNS settings, which routes DNS queries through the proxy channel as well.
When configuring DNS, note that the remote DNS itself must go through the proxy, otherwise it will be polluted too. v2rayN by default sends remote DNS traffic to the proxy outbound, which relies on the DNS routing logic in the routing rules. If you manually edit the routing rules, make sure to keep a rule that directs DNS traffic to the proxy; otherwise the remote DNS may fail to resolve domains outside China.
TUN Mode
TUN mode is an advanced feature of v2ray clients: it creates a virtual network interface and takes over all system network traffic, including apps that don't respect the system proxy settings, UDP traffic, and command-line tools. For ordinary users, TUN mode means "once enabled, all programs go through the proxy" without needing to configure a proxy for each app individually.
The main use cases fall into three categories: first, scenarios that require a global proxy, such as certain apps that only respect the system proxy but the system proxy can't cover them; second, UDP traffic, such as games and voice calls, which the system proxy usually doesn't forward; third, command-line tools like git and curl, which by default don't read Windows system proxy settings.
Enabling TUN mode in v2rayN is simple: open "Settings - Parameter Settings", find the "Enable TUN Mode" toggle, and check it. On first enable, Windows will show a UAC prompt because creating a virtual network interface requires administrator privileges. On macOS, you'll need to enter the admin password or authorize a kernel extension. After enabling, v2rayN will create a virtual network interface and automatically point the system default route to it.
The difference between TUN mode and system proxy needs to be clarified. The system proxy only works for apps that actively read proxy settings; browsers and some download tools do, but many apps don't. TUN mode takes over at the network interface level, so all traffic goes through the virtual interface, giving broader coverage. But TUN mode has a cost: performance overhead is slightly higher than system proxy because all traffic passes through a virtual interface; and if misconfigured, it may affect LAN access.
After enabling TUN mode, routing rules still apply. In other words, you can continue to do split routing in TUN mode: mainland China traffic goes direct, outside China traffic goes through the proxy. TUN mode just provides the "traffic entry point"; the actual direction is still determined by the routing rules.
Below is an example of the TUN section in v2rayN's config.json:
{
"tun": {
"enable": true,
"stack": "system",
"dns": "1.1.1.1"
}
}stack is the implementation of the network stack. On Windows, system is recommended because it uses the system's built-in network stack and has the best compatibility. On macOS, gvisor is recommended to avoid some kernel extension conflicts. If the network becomes unstable after enabling TUN mode, try switching the stack parameter. The dns field specifies the DNS server used in TUN mode; here 1.1.1.1 is a remote DNS that goes through the proxy, but you can also write 223.5.5.5 to go direct, depending on your split-routing needs.
There is a common misconception when using TUN mode: after enabling TUN, if DNS is misconfigured, all domain resolution will fail, manifesting as "connected but nothing can open". In this case, first turn off TUN mode, check the DNS configuration, then re-enable it. Additionally, TUN mode may conflict with certain VPN software or game accelerators; if used simultaneously, routing tables may overwrite each other. It's recommended to keep only one global traffic takeover tool.
TUN mode and FakeDNS (covered in the next chapter) are a perfect match: TUN takes over all traffic, and FakeDNS takes over DNS resolution. Together they enable a truly "leak-free proxy" environment.
FakeDNS
FakeDNS is a feature of the v2ray core's DNS module: it intercepts all DNS queries, doesn't request from real DNS servers, and instead returns a fake internal IP (usually in a reserved range). The real domain resolution is deferred until the traffic actually needs to connect, at which point v2ray decides whether to go through the proxy or direct based on the routing rules.
FakeDNS has three core benefits: First, DNS queries don't leak to the outside. Because all queries are intercepted locally, the external network can't see which domains you queried. Second, domain resolution is faster. There's no need to wait for a DNS server response; a fake IP is returned locally, and subsequent connections are handled by v2ray's proxy channel. Third, it can avoid DNS pollution. Since no real DNS server is queried, pollution is impossible.
To enable FakeDNS in v2rayN, you usually need to manually edit the dns section of config.json. v2rayN's GUI doesn't necessarily expose all FakeDNS options, so advanced users tend to edit the config file directly. Below is an example of enabling FakeDNS:
{
"dns": {
"servers": ["1.1.1.1"],
"queryStrategy": "UseIP",
"fakeDns": {
"enabled": true
}
}
}After setting fakeDns.enabled to true, v2ray will intercept all DNS queries. queryStrategy controls the query strategy; UseIP means only query IP records, avoiding unnecessary AAAA queries. Note that FakeDNS is incompatible with some applications that need real IPs, such as P2P download software and LAN device discovery. If these apps behave abnormally, you need to exclude the relevant domains in the FakeDNS configuration, or turn off FakeDNS.
FakeDNS works best when combined with TUN mode. TUN mode takes over all traffic, and FakeDNS takes over all DNS queries. Together they form a complete "transparent proxy" environment. In this combination, any app on the system doesn't need separate proxy configuration; browsers, chat tools, and games will automatically go through the proxy, and DNS queries won't leak.
However, there's one thing to note about FakeDNS: since it returns fake IPs, some apps may cache the fake IP, causing subsequent connection failures. For example, an app resolves a domain and gets a fake IP, then v2ray exits, and the app tries to connect using the fake IP and fails. Therefore, when switching configurations or closing v2ray, it's best to restart the affected apps to clear their DNS cache.
If you only use the proxy lightly and don't pursue "leak-free", you can skip FakeDNS. It's more suitable for users who care about privacy or frequently encounter DNS pollution.
Multi-Subscription Management
Multi-subscription management is a basic but easily underestimated capability of v2rayN. A single v2rayN instance can be configured with multiple subscription groups, each updating independently, enabling independently, and named independently. This provides great convenience for "multiple providers" and "self-hosted + provider" mixed use.
The most common scenario is "primary provider + backup provider". The primary provider's subscription handles daily use, and the backup provider is only switched to when all primary nodes fail. If you only use one subscription, when the primary provider has issues, you can only wait. After configuring multiple subscription groups, the backup provider's nodes are always in the list, and switching is just a click away.
Another scenario is "self-hosted nodes + paid provider". Self-hosted nodes are stable but few in number; paid provider nodes are many but of varying quality. By putting them in different groups, you can make self-hosted nodes take priority in the routing rules, with provider nodes as a fallback. This way, even if a self-hosted node is temporarily unavailable, traffic can automatically switch to a provider node.
In Subscription Group Settings, you can set the "Enabled" status for each group. Disabled groups won't auto-update, but already-fetched nodes will remain in the server list. If you don't want to use a group for a while but don't want to delete it, you can temporarily turn off its update toggle.
Subscription update failures are a common issue. Troubleshoot in this order: First, confirm that the network can access the subscription link. Some providers' subscription domains are blocked by ISPs, so you need to go through the proxy first to fetch the subscription. Second, confirm whether the subscription link has expired. Many provider subscription links are time-limited and need to be regenerated after expiration. Third, confirm whether a custom User-Agent is required. Some providers have requirements for the User-Agent of subscription requests; v2rayN supports specifying a User-Agent for each subscription in Subscription Group Settings. Fourth, confirm whether the subscription format is compatible. Some subscriptions are in Clash format; v2rayN has a built-in converter that can automatically convert them during fetching. But if conversion fails, you need to check whether the subscription content is complete.
Subscription deduplication is also a practical feature of multi-subscription management. Duplicate nodes often appear across multiple subscriptions. v2rayN can deduplicate by node ID or address. After checking the "Deduplicate" related option in Subscription Group Settings, duplicate nodes will only keep one, preventing the server list from being flooded.
If a subscription link contains too many nodes, you can combine it with the "Server Filtering" feature to filter by protocol, region, or latency, hiding rarely used nodes. This preserves the flexibility of multiple subscriptions without making the list hard to manage.
Multi-subscription management combined with routing rules can achieve more advanced usage: for example, use the nodes of a "Work Group" as the default proxy, use a "Home Group" as backup, and then specify different outbounds by domain or IP in the routing rules. This kind of configuration suits users who have a clear plan for their network environment.
Custom Outbounds
An outbound is the target that a v2ray client connects to. v2rayN has two built-in outbounds by default: one is "Proxy", which points to the currently selected node; the other is "Direct", which uses the freedom protocol and goes through no proxy. These two outbounds cover the vast majority of use cases.
But in some advanced scenarios, you need custom outbounds. For example, you want one app to go through a Shadowsocks outbound, another app to go through a SOCKS outbound, or you want to forward traffic of a specific protocol (like HTTP) to another proxy. All of these can be achieved by editing the outbounds array in config.json.
Below is an example of adding a Shadowsocks outbound:
{
"outbounds": [
{
"tag": "proxy",
"protocol": "shadowsocks",
"settings": {
"servers": [
{
"address": "1.2.3.4",
"port": 8388,
"method": "aes-256-gcm",
"password": "your-password"
}
]
}
},
{
"tag": "direct",
"protocol": "freedom"
}
]
}This configuration defines two outbounds: proxy uses the Shadowsocks protocol and connects to a server at 1.2.3.4 port 8388; direct uses the freedom protocol, meaning direct connection. Note that the tag field is very important; the outboundTag in routing rules references this tag. If you change the tag to something else, you must update the routing rules accordingly.
The combination of custom outbounds and routing rules is the core use case. For example, you can write a rule in the routing rules like this:
{
"type": "field",
"domain": ["example.com"],
"outboundTag": "proxy"
}In this way, traffic to example.com will go through the proxy outbound. If you have multiple custom outbounds, such as one Shadowsocks outbound and one HTTP outbound, you can distribute traffic to different exits by domain, achieving a "multi-line" effect.
In v2rayN, manually editing config.json is the only way to add custom outbounds. Before editing, it's recommended to close v2rayN, back up the original config file, and then edit. After editing, reopen v2rayN. If the config has syntax errors, v2rayN will show a load failure; at that point, restore from the backup. Note that v2rayN's GUI may overwrite config.json when saving other settings, so if you manually edited the config, it's best to turn off v2rayN's "Auto Save" related option, or restart immediately after editing to prevent the GUI from overwriting.
For the differences between VMess and VLESS protocols, and how to choose the protocol that suits your node, refer to our blog post "VMess vs VLESS: What's the Difference? Understanding the Use Cases of Both Protocols in One Minute".
Advanced Tuning & Troubleshooting
After configuration is complete, unstable connections or inability to access the internet are common issues. This chapter organizes common fault scenarios and tuning directions for easy reference.
Troubleshooting Steps for Unstable Connections
First, check node latency. In the server list, right-click a node and select "Test Real Connection Latency". If latency is very high or times out, try switching to another node. Second, check for local port conflicts. v2rayN uses 10808 and 10809 as the local SOCKS/HTTP ports by default. If they are occupied by other programs, connections will fail. You can use the command netstat -ano | findstr 10808 to see the occupying process, then change the local ports in "Settings - Parameter Settings". For more detailed steps, refer to the blog post "Port 10808 Already in Use: How to Identify the Conflicting Process and Change v2rayN's Local Port". Third, check the system proxy settings. If the port the system proxy points to doesn't match the port v2rayN is actually listening on, the browser won't connect. Fourth, check the routing rules. If the routing rules direct all traffic to direct, the proxy naturally won't work.
Startup Crashes and Immediate Exits
v2rayN exiting immediately on startup is usually related to missing runtime libraries or security software blocking. On Windows, first confirm whether the .NET runtime is fully installed. If it's installed but still crashes, check whether security software (such as Windows Defender or third-party antivirus) has quarantined v2rayN or the v2ray core files as threats. Add the v2rayN installation directory to the whitelist, or re-extract it to a non-system drive path. For more detailed troubleshooting steps, refer to the blog post "v2rayN Won't Open: Runtime, Permission, and Crash Troubleshooting Steps".
Connected but Cannot Access the Internet
This is the most confusing issue: the client shows connected, but web pages won't open. Troubleshoot step by step in this order: First, confirm whether the node is actually usable - test latency and try accessing a domestic website that doesn't need a proxy. If that works, the network is basically fine. Second, check the system time. Proxy protocols are sensitive to time synchronization; a time offset of more than 90 seconds will cause connections to be rejected. Third, check DNS. If DNS is misconfigured, domain resolution will fail, manifesting as "can ping the IP but can't open the domain". Fourth, check the system proxy settings. Some apps force the use of the system proxy; if the system proxy points to the wrong port, the network will break. Fifth, check the routing rules. If the rules direct the domain you're visiting to direct, and the direct network itself can't access that domain, you'll also get "connected but can't open". For a complete troubleshooting checklist, refer to the blog post "V2Ray Connected but Can't Access the Internet? Check Nodes, DNS, and System Proxy with This Checklist".
Performance Tuning Directions
If the connection is stable but speed is not ideal, you can try the following tuning: enable Mux (multiplexing). Mux multiplexes multiple TCP connections into one connection, reducing handshake times and lowering latency, but it adds a bit of CPU usage. For mobile networks or high-latency lines, Mux is usually helpful. The choice of transport layer protocol is also important: WebSocket has good compatibility but slightly higher overhead, while gRPC performs better in long-connection scenarios. All of these can be adjusted in v2rayN's node configuration.
Log Troubleshooting
v2rayN's log window ("View Logs") records error messages during the connection process. If a connection fails, the log usually contains a clear error reason, such as "connection refused", "timeout", "certificate verify failed", etc. Learning to read logs can greatly shorten troubleshooting time. The log level can be adjusted in "Settings - Parameter Settings". Set it to "Debug" to see more detailed information; after troubleshooting, remember to set it back to "Info" or "Warning" to avoid the log file growing too large.
The above tuning and troubleshooting methods apply to both v2rayN desktop and v2rayNG Android. When encountering issues on Android, first check whether the subscription is updated, whether the node is usable, and whether the system's battery-saving policy is restricting it.
If you're not familiar with the basics, it's recommended to go back to the Quick Start tutorial first, walk through the subscription import and node selection process, and then come back to read the chapters on this page. Each chapter here is an independent topic and can be consulted as needed.