geoip.dat and geosite.dat Updates: Manual Replacement and Automatic Setup for v2rayN Routing Databases

What geoip.dat and geosite.dat each handle

geoip.dat groups IP address ranges. Routing rules such as geoip:cn and geoip:private read from this file. When the destination is already an IP address, or a DNS result must be matched against IP ranges, the core queries GeoIP data.

geosite.dat groups domains. Common entries include geosite:cn, geosite:category-ads-all, and geosite:geolocation-!cn. It stores domain rule sets; it does not perform DNS resolution or directly determine an IP address's region.

Both files are read by the running Xray or V2Fly core. v2rayN only generates the configuration, launches the core, and performs updates. Updating the files does not reorder rules. If a broader rule matches first, later GeoIP or GeoSite rules still will not run.

Check the core, directories, and existing rules before updating

Start by checking the core used by the active configuration on the v2rayN main screen. VLESS, XTLS, or REALITY configurations typically use Xray; standard VMess configurations may also use Xray. If you have switched core types, replacing files only in the old directory is not enough.

Open “Settings” → “Parameter Settings” and note the local listening ports, core type, and update options. Common local SOCKS and HTTP ports are 10808 and 10809. If you customized the ports, follow the current settings; updating resource files does not require changing them.

Export or view the current routing configuration and confirm that it actually references GeoIP or GeoSite. Replacing the data files alone changes nothing if the configuration contains no geoip: or geosite: entries. Before updating, copy the old files to a separate backup directory and add the date to the filenames if needed.

Update Geo files from v2rayN's built-in updater

Use the built-in updater first. The usual path is the main menu: “Check for Updates” → “Update Geo files.” Some v2rayN 7.x interfaces place this item in an update submenu, where it may appear as “Update Geo Files” or “Update Geo Resources.” Select a reachable server configuration before starting.

1. Launch v2rayN and confirm that the core runs normally and that the system time and network connection are working.
2. Open the “Check for Updates” menu and select the Geo file update option.
3. Wait for the status bar or log to show that downloading and writing are complete. Do not close the program while files are being written.
4. Stop the current core and start it again; toggling the system proxy alone may not release the old resources.
5. Open the log and confirm there are no errors about missing categories, unreadable resource files, or failed configuration loading.

Avoid combining automatic updates with frequent core switching. Different cores in v2rayN may use different directories, so one successful download only confirms that the target directory was updated; it does not mean another core's directory was updated too. If you consistently use Xray, focus on the current Xray directory and startup log.

After an update, do not judge routing only by a “download succeeded” message. Restart the core, then visit one domain that should connect directly and one that should use the proxy. Check the destination and outbound tag in the logs for both. The update is complete only when the matches are correct.

Manually replace the files when the built-in updater fails

Stop the core completely before replacing files. If xray.exe or v2ray.exe is still running, the files may be locked and the copy operation may replace only one of them. Use the stop control in the “Servers” area of v2rayN, then confirm that the log has stopped producing output.

The download source must provide a resource format supported by the current core. After obtaining new geoip.dat and geosite.dat files, keep their filenames unchanged. Do not rename an archive with a .dat extension, and do not place either file in an extra nested directory.

v2rayN\
├─ v2rayN.exe
└─ bin\
   └─ Xray\
      ├─ xray.exe
      ├─ geoip.dat
      └─ geosite.dat

1. Exit the running core and note the core executable path shown in the log.
2. Open the directory containing that executable and confirm that the two old .dat files are in the same directory.
3. Copy the old files to a backup directory, such as backup\2026-08-26\.
4. Copy the new files over the files with the same names and confirm that no duplicate extension was added.
5. Start the core and watch for resource-loading errors during configuration startup.
6. Test one direct, one proxied, and one blocked rule, then verify the actual outbound path.

When a portable installation has been moved, multiple bin\Xray\ directories may exist. Searching by modification time can help locate them, but does not prove which one is in use. The most reliable evidence is the executable path in the current startup log and the core process actually running in Task Manager.

How to write common GeoIP and GeoSite category names

In v2rayN routing settings, put domain rules and IP rules in their respective fields. Enter geosite:cn in the domain-matching section and geoip:cn in the IP-matching section. Outbound tags are usually direct, proxy, or block; use the labels in the final generated configuration as the authority.

A common baseline order is: send private addresses directly, block selected ad domains, send mainland China domains directly, send mainland China IPs directly, and route everything else through the proxy outbound. If a global proxy rule comes first, later direct categories never get a chance to match.

{
  "type": "field",
  "domain": [
    "geosite:cn"
  ],
  "outboundTag": "direct"
},
{
  "type": "field",
  "ip": [
    "geoip:private",
    "geoip:cn"
  ],
  "outboundTag": "direct"
},
{
  "type": "field",
  "domain": [
    "geosite:category-ads-all"
  ],
  "outboundTag": "block"
}

• geoip:private: Matches common private and local address ranges and is usually routed directly.
• geoip:cn: Classifies the destination IP and works well as a supplement after domain rules.
• geosite:cn: Matches entries included in the mainland China domain category.
• geosite:category-ads-all: Matches ad-related domain sets. Confirm that required service domains are not being blocked before enabling it.
• geosite:geolocation-!cn: Matches non-mainland-China domains organized by geographic attributes. This broad category should come after precise rules.

A category must exist in the current geosite.dat or geoip.dat. Writing a plausible-looking name does not create a category automatically. If the core reports an error such as “geosite entry not found,” check the spelling, prefix, and data source first instead of repeatedly changing the local listening ports.

Troubleshooting order when routing rules stop working after an update

If the core will not start after an update, check the first error in the log. A wrong resource path, a missing category, and invalid JSON configuration syntax are three different problems. Do not delete all routing rules first, or you will lose the context needed to locate the fault.

If the core starts but routing is wrong, first confirm whether the request includes a domain name. Some applications connect directly to an IP address, leaving GeoSite with no domain to match and making GeoIP the only option. Enabling DNS rewriting, remote resolution, or TUN mode can also change how target information is formed, so check the final configuration.

Also check the currently selected routing mode. After switching v2rayN to global proxy, global direct, or another preset mode, custom rules may no longer be part of the final active configuration. Inspect the generated routing section after startup rather than relying only on what is saved in the editor.

If only a few domains behave incorrectly, add a precise rule for comparison. If the precise rule matches but the category rule does not, the issue is likely the category name, data file, or rule field. If neither matches, continue checking rule order, target type, and outbound tag.

Build an update cycle with a reliable rollback path

There is no need to force a Geo data download at every startup. For normal use, check once a week; if you rely on fine-grained categories or frequently encounter new domain classifications, check every 24 hours. Update frequency affects only how current the category data is, not node throughput.

Keep one recent working backup after each update. Include geoip.dat, geosite.dat, and the current routing configuration. If categories are missing or matching incorrectly, restore the previous batch first, then review rule changes separately instead of changing files, DNS, and outbound settings at the same time.

• Before updating: record the core type, executable path, routing mode, and file modification dates.
• During the update: handle both resource files as one batch and do not replace only one.
• After the update: stop and restart the core, then check the startup log and three outbound results.
• If something goes wrong: restore the latest backup, then check category names, fields, order, and directories one by one.

After maintenance, keep a fixed set of test targets: a local network address to verify direct access to private addresses, a known mainland China domain to verify GeoSite, a direct IP request to verify GeoIP, and a domain that should use the proxy to verify the fallback rule. Fixed targets make changes before and after an update easier to compare than randomly opening webpages.