Routing Rules in Practice: Direct Connect for Local Traffic, Proxy Only What You Need

Plenty of beginners run into an awkward situation after connecting successfully: every single request gets routed through the proxy server, and suddenly sites and services you never needed to unblock in the first place — your bank, a local shopping site, a nearby streaming service — feel noticeably slower. This happens because routing rules haven't been set up properly — without any distinction, the client sends all traffic through the proxy node. The sites you actually wanted unblocked work fine, of course, but everything else now takes an unnecessary detour too, which not only slows things down but also eats into your node's data allowance for no good reason. What routing rules solve is exactly this: letting the client automatically judge the destination of each request and decide whether it should connect directly or go through the proxy. This article walks through the minimum configuration needed to get it right.

Enable the Built-in Rule Set to Handle Most Scenarios First

v2rayN ships with a community-maintained rule set built on the GeoSite:cn and GeoIP:cn databases — a preset specifically aimed at domains and IP ranges tied to mainland China. Turning it on takes zero manual configuration: open the top menu "Settings" → "Routing Settings," select "Bypass Mainland China" from the presets, save, and reconnect your node — no client restart needed. This preset is genuinely useful if you specifically want mainland Chinese sites and services kept on a direct connection while everything else goes through the proxy. If that split doesn't match what you're trying to do — say you'd rather send all traffic through the proxy with no exceptions, or you need to keep a different region's sites on a direct connection instead — skip this preset entirely and either switch the routing mode to a fully global proxy, or write your own custom rules targeting the domains and IP ranges that actually matter to you. Either way, no built-in rule set can realistically cover every website, so if you notice a specific site isn't being routed the way you expect, you'll need to add a custom rule of your own. There are three common syntax patterns: domain:example.com matches that exact domain and all its subdomains; domain:keyword:cdn matches requests where the domain contains the keyword cdn, handy for multiple domains under the same CDN provider; and geoip:private matches local/internal network address ranges, which should generally always connect directly to avoid internal requests being routed through the proxy by mistake. Here's an easily overlooked but crucial point: routing rules are matched top to bottom, and the first match wins — matching stops there — so custom rules always need to be placed before the built-in rule set, or they may never get matched at all.

Block Ads While You're At It, Plus a Few Common Scenarios

If you'd also like to block ads and tracking requests, you can load an additional community-maintained ad-filtering rule set, which marks matching domain requests as "blocked" instead of routing them directly or through the proxy — cutting down on ad loading without using up extra proxy bandwidth. Combined with the rules above, a few common scenarios can be handled directly: if you only want to proxy a handful of sites, switch the routing mode to "global direct connect" and add a "proxy" rule specifically for those target domains. If you want to make sure your company's or school's internal services aren't affected, ensure the geoip:private rule is always kept and given top priority. If a specific site is being misrouted through the proxy when it should connect directly, add a direct-connect rule for that domain before the built-in rule set to override the default behavior. After configuring everything, open the log window and visit one site that should stay on a direct connection and one that should go through the proxy, checking whether the log shows each request as "direct" or "proxy." If the result doesn't match what you expect, go back to the routing settings and check the rule order and syntax — for more basic connection verification steps, see the quick start guide.

Why Some Apps Ignore Your Routing Rules No Matter What

One important thing to keep in mind: routing rules only apply to traffic the client can actually see. If certain apps (command-line tools, some games, etc.) don't follow the system proxy setting, routing rules simply can't apply to them — that traffic bypasses the proxy entirely, along with any carefully configured routing rules. If you find that an app never seems to respond to any rule changes, this is very likely why. In that case, you'll need to enable TUN mode, which takes over all traffic at the network adapter level so routing rules can finally cover these "uncooperative" apps too. See the complete guide to TUN mode for the details and setup steps.

Rule Sets Need Updates, and Configs Are Worth Revisiting Occasionally

The built-in rule set isn't something you set once and forget forever — the community-maintained GeoIP and GeoSite databases are continuously updated, and new domains and IP ranges need the rule set files to be refreshed to stay in sync. It's best to keep auto-update enabled, or check manually on a regular basis, to avoid new domains being routed incorrectly due to an outdated rule set. If you've added a lot of custom rules, it's also worth reviewing the list periodically — remove anything no longer in use, merge redundant entries, and keep the matching process simpler and easier to debug when something goes wrong. Finally, a few common beginner mistakes worth flagging: placing a custom rule after the built-in rule set by mistake, so it never gets matched; enabling multiple rule sets with a confusing priority order, causing results opposite to what you expect; and forgetting to reconnect the node or restart the client after changing rules, since changes don't apply retroactively to an existing connection. If your routing results aren't matching expectations, these three points are a good place to start checking.