How to Update geoip.dat and geosite.dat: Sources, File Replacement, and Routing

1. GeoIP vs. GeoSite: What They Match

geoip.dat contains IP ranges grouped by tag, while geosite.dat contains domain rules grouped by tag. These are binary data files read by the core—not subscription links, and they do not contain proxy servers. Updating the rule files changes what traffic can match; it does not update node addresses, ports, or credentials.

For example, geosite:cn references a domain list named cn; it does not infer a region in real time from a domain suffix. geoip:cn references the corresponding IP ranges. A domain served from an overseas CDN may match the former but not the latter. Configure the two rule types separately—never put geosite:cn in the ip array.

This flow shows how domain and address rules relate; it does not mean every connection triggers a DNS lookup. Whether and when resolution happens also depends on whether the destination starts as a domain or an IP, and on routing.domainStrategy. If the core receives only an IP, domain rules usually have no domain to match. Sniffing may recover domain information for some connections, but it cannot guarantee that every domain will be identified.

2. Rule Sources: Check Tags Before Choosing Files

Common sources include V2Fly's domain-list-community data for domain categories, V2Fly's geoip data project, and derivative rule sets such as Loyalsoldier's v2ray-rules-dat. The first two maintain domain categories and IP data, respectively; derivative projects may combine lists, add categories, or change what they include. Files with the same name do not necessarily use identical tags or category definitions.

• Check the release files: You need finished .dat files supported by your client and core—not a source-code directory, webpage, or archive.
• Check the tags: Every geosite: and geoip: reference in your configuration must appear in the category documentation for the corresponding source. Do not copy tags directly from rule sets in other formats.
• Check the update URL: Find out which release source the client is configured to use. If you set a custom download URL, make sure it serves the file itself, not a download page that requires sign-in.
• Keep a rollback option: Record the source, download date, and original file sizes, and keep copies of the old files. Manage the two files as a pair when switching sources to avoid mismatched tag expectations.

3. Update v2rayN: Use the Built-In Updater or Find the Right Folder

v2rayN manages configuration; the selected core actually reads the rule files. These steps apply when using V2Ray or Xray with generated configuration that references Geo data. Menu labels and data directories vary by release. A file with the right name in the installation folder is not necessarily the one the active core reads.

1. Note your current setup: Check which core is active in the client, and back up your custom routes and current Geo files. Avoid upgrading the core or changing DNS at the same time, so you can isolate any problems after the update.
2. Run the built-in updater: Open the main window's Update menu and look for the Geo file update option, often labeled Update Geo Files. If your version lists GeoIP and GeoSite separately, update each one. Follow the labels in your current interface.
3. Confirm the downloads finished: Check the logs or notifications to make sure both files downloaded successfully. If a download times out, check that its URL is reachable. If the interface offers an option to update through the proxy, first establish a working connection, then enable the option and try again.
4. Reload the core: Restart the service or disconnect and reconnect after the update. Then check the startup log for resource loading failures or missing categories.

If the built-in updater is unavailable, consider replacing the files manually. Use the client logs, runtime configuration, and core resource settings to identify the actual asset directory. The portable folder, user data directory, and core program directory may all be different. If you start the core manually, also check for asset location variables such as V2RAY_LOCATION_ASSET or XRAY_LOCATION_ASSET.

1. Fully exit the client and any core processes it started, then copy the active geoip.dat and geosite.dat files to a separate backup folder.
2. Place both downloaded files in the confirmed asset directory, keeping their original filenames. If your system hides file extensions, make sure the filename does not become geoip.dat.dat.
3. Make sure the current user can read the files, then start the client. If old tags or resource errors still appear, check the path the core reads instead of copying files blindly into multiple directories.

4. Update v2rayNG: Use the App's Updater, Not Its Private Data Folder

v2rayNG uses the Xray core, and Geo files are usually kept in app-managed storage. The Downloads folder in an Android file manager is not the core's asset directory; placing files there will not make them available for routing. Android restricts access to app-private folders, so the desktop method of directly replacing files does not apply.

1. Save your current routes: Open Routes from the sidebar and note the current mode and custom rules. If you use a custom configuration, save a copy of its text too, so you can restore it if anything goes wrong.
2. Find the resource update option: Check the menu in the upper-right corner of the Routes page and the app's settings for a Geo resource update option. Depending on the version, it may be called Update Geo Resource Files or have separate GeoIP and GeoSite options. Follow the labels in your interface.
3. Check the source and download: If the app lets you set resource URLs, confirm that each URL serves the intended file. Make sure the URLs are reachable and wait for the completion notice. Import local files only if your version explicitly supports importing them.
4. Reconnect and verify: Stop the current connection and start it again. Check the logs for Geo file loading errors, then use the validation steps below to check the outbound route.

If your version has no resource update or import option, check its built-in help. If needed, choose an appropriate installer from the client download page. Do not clear app data just to replace two files; that may also remove nodes, groups, and route settings. You do not need to rebuild VMess or VLESS nodes that are already working.

5. Routing Rules: Check Tags, Outbounds, and Match Order

This V2Ray/Xray routing snippet shows where GeoSite and GeoIP fields belong; it is not a complete, standalone configuration. It assumes that an outbound named direct is already defined in outbounds. GUI clients may generate different tag names, so verify them before pasting—do not infer internal tags from display names alone.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

IPIfNonMatch means that if a domain does not match a rule during the current matching process, the core tries to resolve its IP and then checks address rules. It does not mean that every domain is resolved first, and it does not configure a working DNS server for you. AsIs does not resolve domains to IPs for routing; IPOnDemand triggers resolution when a rule requires an IP, which may result in an earlier DNS query.

Rules are checked in order; the first match determines the outbound. Put specific domains that must use the proxy before broad direct rules. If you put a catch-all rule at the top, later Geo rules will never run. The example does not require all other traffic to use the proxy; check the final outbound order and fallback rules generated by your client.

6. Verify the Update: From Successful Loading to Actual Matches

Finishing the download is only the first step. A reliable check confirms that the files are readable, categories load, and connections use the intended outbound. Change one set of variables at a time: update the files and restart first, then adjust routing. Do not switch nodes, change DNS, and change data sources all at once.

1. Check startup logs: Search for entries containing geoip, geosite, failed, or not found. If a category fails to load, first check the tag spelling and data source rather than assuming the node is broken.
2. Choose test domains: Pick one domain confirmed in the current source's category list, then another that should not match that category. Do not assume a domain belongs to cn based on its suffix alone.
3. Start a new connection: Close existing long-lived connections in the page or restart the test app, then visit the test domains. Existing connections do not automatically switch outbounds when routing files change.
4. Review access logs: If core access logs are available, check the destination and outbound tag. If the client does not show which rule matched, enable just one test rule at a time to narrow down the issue, then restore your original configuration.
5. Test rollback: If the new files alone cause startup failures, stop the service, restore the backup, and restart to verify. If the problem persists, check the configuration and DNS as well; do not assume the rule update is the only cause.

Access logs may contain usage data, including domains and destination addresses. Restore your usual log level after troubleshooting. Before sharing logs, remove node credentials, subscription URLs, and personal browsing records.

7. Common Issues: Missing Categories, Updates That Have No Effect, and Misrouted Traffic