geoip.dat and geosite.dat Update Guide: What v2rayN Routing Databases Do and How to Replace Them Manually

What the two databases match

geosite.dat stores domain groups organized by purpose or region. In routing rules, entries such as geosite:cn and geosite:category-ads-all are not individual domains; they tell the core to read a set of domains under the corresponding tag. While the destination is still a domain, the core can use these rules to choose a direct, proxy, or blocked outbound.

geoip.dat maps IP address ranges to tags. The geoip:cn rule matches the range containing the destination IP, while geoip:private identifies LAN and other non-public ranges. GeoIP rules are the main basis for routing once the destination has resolved to an IP address or the connection uses an IP directly.

These files handle route matching only. They do not provide subscription nodes or change VLESS, VMess, or transport-layer parameters. When the databases are outdated, new domains may be missing from existing tags, newly assigned ranges may go to the wrong outbound, or a rule may reference a new tag that the old file does not contain.

Common tags and match order

geosite:cn generally matches domains associated primarily with services in mainland China and is commonly routed directly. It relies on a maintained domain list; it does not mean every domain with a particular suffix, nor does it guarantee that every server is physically in the same region.

geoip:private mainly covers private or reserved addresses. Common private IPv4 ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. LAN printers, router admin pages, and home storage devices should normally match this tag and go direct before proxy rules.

geosite:geolocation-!cn represents domains that the database maintainers place in the corresponding outside-mainland-China geographic set, but it is not a complete list of every overseas domain. Targets that match no tag still fall through to the final rule, so the routing configuration must keep an explicit fallback outbound.

Confirm the Core type and runtime directory before updating

On the v2rayN main screen, record the current version and active configuration, then open “Settings” → “Parameter settings” → “Core type.” VLESS and VMess nodes may use different cores depending on their configuration. Geo files must be placed in the directory of the core that actually starts, not simply wherever the v2rayN executable is located.

Using the portable directory of v2rayN 7.12.3 as an example, the Xray core is commonly found at bin/Xray/, alongside the core executable, geoip.dat, and geosite.dat. Directory names, capitalization, and nesting can vary between packages; follow the startup path shown in the logs.

Exit the running core before updating. Closing only the main window may leave a tray process running, so use “Exit” from the tray menu and confirm in Task Manager that the relevant core process has ended. Overwriting files while they are in use can cause access-denied errors, replace only one file, or leave the old data loaded at the next startup.

1. Record the version

   Open “Help” or “About” and record the v2rayN version; the example environment uses v2rayN 7.12.3.

2. Confirm the core

   Go to “Settings” → “Parameter settings” → “Core type” and confirm whether the current node actually uses Xray or the v2fly core.

3. Locate the directory

   Start a node once, inspect the runtime log, and use the core startup path to find the corresponding bin/Xray/ or actual Core directory.

4. Exit the process

   Exit v2rayN from the tray menu and confirm that the core process no longer has either .dat file open.

5. Back up the old files

   Copy the original files and name them geoip.dat.bak-20260730 and geosite.dat.bak-20260730 for quick rollback.

Use the v2rayN built-in updater

For routine maintenance, use v2rayN’s built-in updater first. Open the top “Check for updates” menu and select “Update Geo files”; some 7.x interfaces show it as “Update Geo files.” This downloads the Geo data to the relevant directory. Restart the core afterward so it reloads the data.

Do not switch nodes, change the Core type, or launch a second v2rayN instance during the update. If the interface reports a successful download but the file timestamps do not change, check write permissions and your security software’s quarantine records, then confirm that the runtime directory matches the directory you inspected.

1. Stop the core

   Stop the current server from the main window so the updater and core do not access the Geo files at the same time.

2. Run the update

   Open “Check for updates” → “Update Geo files” and wait for the status bar or log to report completion.

3. Check the timestamps

   In the actual Core directory, check the modification times of both files and confirm that geoip.dat and geosite.dat were updated.

4. Restart the core

   Select the active server again and start it. Watch the first 30 seconds of logs for file-read or missing-tag errors.

5. Test routing

   Visit one LAN address, one domain that should go direct, and one domain that should use the proxy, then check the outbound markers in the routing log.

Manually replace geoip.dat and geosite.dat

When the built-in updater is affected by network access, permissions, or the download source, you can replace the files manually. Obtain complete geoip.dat and geosite.dat files from an official release source compatible with the current core. Do not rename a web response, archive itself, or similarly named documentation file and use it as Geo data.

Keep the filenames exactly unchanged during replacement. Windows may hide known extensions by default, so a file displayed as geoip.dat may actually be geoip.dat.dat. In File Explorer, enable “View” → “Show” → “File name extensions,” then verify the names.

Replace both files together as one batch whenever possible. Updating only one may not cause an immediate error, but domain and IP rules will reflect different update times, making it harder to determine whether incorrect routing comes from rule order, resolution results, or data differences.

1. Obtain the files

   Download the two official Geo data files compatible with the current core. After extracting them, confirm that their filenames are geoip.dat and geosite.dat.

2. Exit completely

   Stop the server, exit v2rayN from the tray, and confirm that the Xray or v2fly core process has ended.

3. Keep a backup

   Copy the old files from the Core directory to a separate backup directory; do not rely only on the system overwrite prompt.

4. Overwrite the matching files

   Copy the new files into the Core directory confirmed by the logs, allow the old files to be overwritten, and confirm that both files were written successfully.

5. Start and verify

   Start v2rayN and the current node, then check the logs for errors such as failure to load Geo data, missing tags, or an invalid file format.

6. Roll back if needed

   If the core will not start, exit the program, restore both backup files, and recheck the downloaded files and Core type.

v2rayN/
├─ v2rayN.exe
├─ guiConfigs/
└─ bin/
   └─ Xray/
      ├─ Xray.exe
      ├─ geoip.dat
      ├─ geosite.dat
      └─ Other core runtime files

Verify that the update actually took effect

The files being present does not mean the rules are active. The core reads the data at startup, so switching servers without restarting the core may leave the old process using its in-memory data. The safest approach is to exit v2rayN, start it again, and run three routing tests with distinct expected results.

For the first test, use a LAN address such as the router admin address 192.168.1.1; it should match geoip:private and go direct. For the second, choose a domain explicitly assigned to geosite:cn in the routing configuration. For the third, choose a domain that should be handled by the final proxy rule, then compare the target, matched rule, and outbound name in the routing log.

If you use a local SOCKS inbound for testing, enter the port actually shown in the v2rayN interface in your browser or test tool; 127.0.0.1:10808 is a common example in older versions. Use the current client setting as the authority. A wrong port causes a connection failure unrelated to the Geo data.

Common errors and troubleshooting order

When the logs show an error such as “geosite tag not found,” first check the tag spelling and prefix, then confirm that the current geosite.dat contains the tag. Tag names in custom rules must match the database definitions exactly. Do not use the geoip: prefix for domain tags or the geosite: prefix for IP address sets.

When file access is denied, fully exit the tray process first, then confirm that the v2rayN directory is writable by the current user. If the program is in a protected directory, copy the new files to a regular directory first, exit the client, and complete the replacement with the required permissions.

If the update succeeds but routing does not change, troubleshoot in this order: actual Core path, whether the core restarted, rule order, DNS resolution results, and final outbound. Do not repeatedly overwrite the same file instead of checking the logs. If the target was already accepted by an earlier full-domain rule, updating GeoIP data will not change that match.

• Core will not start: Restore both backup files from the same batch, confirm that the service is working again, then obtain compatible files once more.
• Only one file was updated: Stop the core, run the update again, and check whether the other file is locked or lacks write permission.
• LAN traffic uses the proxy: Place geoip:private and the corresponding direct outbound before broad proxy rules.
• Unexpected domain match: Check the DNS response, domain sniffing settings, and whether a full-domain rule matched first.
• Tag not recognized: Check the tag spelling, database batch, and current core; do not mix domain tags with IP tags.
• Old files are still loaded after restart: Check the core path in the logs and rule out an old shortcut or a second v2rayN instance.

Maintaining routes after an update

Updating Geo data changes tag contents only; it does not automatically fix custom routing. After an update, keep a small set of clearly scoped rules: direct access for private networks, required domain rules, mainland-China resource rules, specified proxy rules, and a final fallback. The more rules overlap, the harder they are to troubleshoot.

For business domains that must always route consistently, place full-domain or suffix rules before Geo tags. For broader groups of ordinary sites, let geosite and geoip tags handle them. This keeps critical targets under explicit control even when the database contents change.

Save a test record after every update, including the v2rayN version, Core type, modification dates of both files, three test targets, and their actual outbounds. When incorrect routing occurs again, you can compare whether the change came from the client, core, Geo data, or DNS results.

1. Keep a backup of the latest pair of Geo files that started successfully.
2. Before updating, record the current value under “Settings” → “Parameter settings” → “Core type.”
3. Fully restart the core after updating; do not merely refresh the subscription or switch nodes.
4. Run three checks using a private address, a direct domain, and a proxied domain.
5. When something goes wrong, restore the files first, then re-enable custom routing rules one by one.