GeoSite matches domain sets; GeoIP matches IP address ranges. This guide explains how to update the databases, use Xray and V2Ray routing fields, order rules, and check logs when configuring routing in v2rayN on a Mac. First confirm that traffic reaches the core, then check the databases and rules. Updating subscriptions does not update these files.
What GeoSite and GeoIP Match
geosite.dat contains domain rule sets organized by tag. Entries can be full domains, domain suffixes, or other supported match types. geoip.dat contains IP ranges organized by tag, typically including country or region groups and address categories for specific purposes. Both are binary databases; renaming a plain-text list of domains will not make it usable.
GeoSite: Domain Sets
- Common file
geosite.dat- Routing field
domain- Example
geosite:cn- What it matches
- The destination domain in a request
Available tags depend on the source and contents of the database in use.
GeoIP: Address Sets
- Common file
geoip.dat- Routing field
ip- Example
geoip:private- What it matches
- The destination IP, or an IP resolved during routing
An address category is not a website category and does not guarantee that a connection is reachable.
geosite:cn does not mean “all domains ending in .cn.” It refers to the set named cn in the database. That set may include domains with other suffixes, and newly launched sites may not be listed yet. geoip:cn matches address ranges in the database; it does not tell you a website’s ownership or where its users are located.
geoip:private is commonly used in direct-routing rules for private and special-use addresses, but it is not a complete list of local network domains. For example, 192.168.1.1 is an IP destination, while printer.local is a domain destination and also depends on name resolution. Check the current database to see whether a particular address is included.
Check the System Proxy Before Choosing an Update Method
Routing rules only apply to connections that reach the proxy core. The macOS system proxy mainly affects apps that honor system proxy settings. If an app bypasses the system proxy, changing GeoSite rules usually will not change its connection route. TUN can handle more traffic, but routing, DNS, and exclusions still need to be checked. An enabled toggle alone does not prove that every request reaches the core.
Updating databases, subscriptions, and the core are three separate tasks. A subscription provides server parameters; databases provide reusable routing sets; the core executes the configuration. Switching to a VMess or VLESS node will not fix an invalid database tag, and updating a database will not fix expired node credentials.
Update in the Client
RecommendedUse the Geo file update option in v2rayN and let the client download and place the files. Check the results when it finishes, then restart the core to verify that the files load.
Best for: Everyday users who rely on built-in routing and want to avoid managing files manually.
Replace Files Manually
Only do this when you know the database source, available tags, and the core’s resource directory. Keep the old files before replacing them. Do not edit files inside the app bundle or change system directory permissions.
Best for: Advanced users with a custom database or a failed built-in update.
How to Update Geo Files in v2rayN
Menu labels in v2rayN vary by version and interface language. In many desktop versions, the path is “Check for Updates” → “Update Geo files.” If GeoIP and GeoSite are listed separately, update each one. These steps describe a common menu path, not a fixed layout for every platform or version.
-
Check the Active Core
Check the active node on the main screen and find the core name in the runtime log. The examples in this guide are for Xray or V2Ray configurations that read DAT databases. Do not use them as-is if your configuration uses another rule format.
-
Keep a Copy of Your Existing Rules
Open “Settings” → “Routing,” then note the active routing preset, rule order, and domain strategy. If you use custom rules, save a copy first so you can restore them if something goes wrong.
-
Update the Files
Open “Check for Updates” → “Update Geo files.” If the menu has separate “Update GeoIP” and “Update GeoSite” options, run both and wait for the client to report each result.
-
Reload the Core
Once the download is complete, use the client’s core restart option. If you cannot find it, quit the client normally and reopen it. Reloading the databases is more relevant here than simply refreshing your subscription.
-
Check the Load Logs
Look for errors such as database read failures, missing sets, or invalid routing configuration. Then test one known direct connection and one known proxy connection to make sure each uses the expected outbound.
Before replacing files manually, stop the core and confirm the actual file location from the client log or resource directory settings. The app installation directory and user data directory may differ; on macOS, do not assume the databases belong inside the app bundle. If tags are missing after replacement, restoring the original files is often the quickest way to identify the problem.
How to Use geosite:cn and geoip:private Correctly
The following is an Xray/V2Ray-style routing configuration snippet, not a complete, standalone configuration. The direct and proxy values must match outbound tags already defined in the full configuration. v2rayN generates the runtime configuration, so make changes in the client’s routing editor rather than editing temporary files that may soon be overwritten.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": [
"full:example.com"
],
"outboundTag": "proxy"
},
{
"type": "field",
"domain": [
"geosite:cn"
],
"outboundTag": "direct"
},
{
"type": "field",
"ip": [
"geoip:private",
"geoip:cn"
],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}- Put domain sets in domain:
geosite:cnreferences a domain set;full:example.commatches only that exact domain and does not automatically include its subdomains. - Put IP sets in ip: Add
geoip:privateandgeoip:cnto the same array to match a destination IP in either set. - Different fields usually have to match together: Adding both
domainandipto one rule does not mean “match either the domain or the IP.” Use two separate rules when either match should qualify. - UI fields are not JSON: A client’s domain list field usually needs only
geosite:cn, not the surrounding JSON. First check whether the field is for domain lists, IP lists, or a full configuration.
example.com in this example is just an exact-domain match; replace it with the domain you actually want to route through a specific outbound. The final rule is an explicit TCP/UDP catch-all, not the default behavior for every client. Without a catch-all, unmatched traffic usually uses the default outbound, which is not necessarily the proxy.
How Rule Order and DNS Strategy Work Together
Rules are checked in order. Once a rule matches, its outbound is used and the core does not continue looking for a “more specific” rule. A common order is explicit exceptions first, then domain sets, IP sets, and finally a catch-all. If a rule covering all TCP/UDP traffic comes first, later GeoSite and GeoIP rules will never handle those connections.
| domainStrategy | Routing behavior | What to check |
|---|---|---|
AsIs | Does not resolve domains just for routing; IP rules can still match when the destination is already an IP. | Do not expect GeoIP rules alone to handle all domain-based routing. |
IPIfNonMatch | If a domain does not match, try resolving it to an IP and check the rules again. | Whether an earlier domain rule or catch-all has already matched. |
IPOnDemand | Resolve the destination domain as needed when a rule requires an IP match. | An earlier IP rule may match before a later domain exception. |
Note that the example above uses IPIfNonMatch and includes a catch-all at the end. Even if a domain does not match geosite:cn, it may match the catch-all first, so a GeoSite miss does not necessarily trigger an additional IP lookup. The example prioritizes domain-based routing; its IP rules can still handle connections whose destination is already an IP.
If you need to resolve uncategorized domains and then route them using GeoIP, redesign the catch-all and default outbound or consider IPOnDemand, while checking the rule order as well. Changing only the strategy name does not guarantee the intended behavior. With on-demand resolution, put domain exceptions that should use a proxy before broad IP rules to reduce the chance that they are overridden.
Still Not Working After an Update? Troubleshoot by Symptom
Do not change your subscription, DNS, routing, and database all at once. Change one thing at a time and note the destination domain, destination IP, matched rule, and outbound tag. This helps distinguish traffic that never reached the core from a database load failure or a rule that matched incorrectly.
| Symptom | Check first | What to do |
|---|---|---|
| Core will not start after an update | File path, database format, and set tags | Check the startup log, restore the old files, then confirm that the sets referenced in the configuration exist. |
| A website in mainland China still goes through the proxy | Whether the domain is in the database and whether an earlier rule overrides it | Test with an explicit domain rule first, then decide whether to change the set or database source. |
| Cannot reach a device on the local network | Whether the destination is a domain or IP, the resolution result, and TUN exclusions | First test the device’s actual local IP, then troubleshoot name resolution and routing separately. |
| Changing the rules has no effect | The active routing preset and existing long-lived connections | Confirm the preset is active, start a new test connection, and restart the core if needed. |
| Only one app is affected | Whether the app honors the system proxy or uses its own DNS | First confirm how the traffic enters the core; adding more GeoSite entries alone will not fix it. |
The same routing concepts can be used with v2rayNG on Android, but it uses the Xray core, so its menus and resource directories differ from the desktop client. v2flyNG uses the v2fly core; check the supported configuration features and database loading behavior for the version in use. Being able to import a subscription does not mean that every client shares the same routing database.
- Check the input first: Confirm in the logs whether the core sees a domain or an IP. If it sees only an IP, domain sets may not be involved in matching at all.
- Then check the sets: Confirm that the current database contains the tags you reference. Do not copy tag names from another database source without checking them.
- Finally, check the outbound: If a connection fails after matching a direct rule, the problem may be DNS or the destination network, not an incorrect GeoIP category.
Routine maintenance comes down to three steps: update the files and confirm they load, check the rule order and domain strategy, then test the outbound with a new connection. The databases provide the sets, the configuration determines where traffic goes, and the system proxy or TUN sends traffic to the core. Keeping these layers separate makes routing issues easier to troubleshoot.