On this page
You updated GeoData in service mode and the client reported success, but a configuration using a new GEO category still fails to activate. First identify which data copy was updated and which copy validation reads. Keep the rules and app data while investigating.
Why do new categories fail validation after GEO updates?
The Clash Verge Rev v2.5.10 release notes confirm that GEO databases updated by the service core were not synchronized back to the app directory, preventing rules using new categories from passing validation. This is one cause of a category-not-found error; it does not establish that your data source contains the category you need.
This guide applies when the updated database from the same source contains the category and the service update succeeds, but validation still reads the app's older copy. If you only have an update notification and have not confirmed the source or file contents, preserve the failing rule and first error before attributing it to synchronization.
Start with the actual symptom
| What you observe | Next step |
|---|---|
| A service-mode update succeeded and the new database contains the category, but the original configuration still reports a category error | Check the application update and synchronization before validation |
| The update reports a download failure, timeout or file error | Resolve that update error first; a new database is not yet confirmed |
| The actual source lacks the category, or the rule misspells its name | Check that source's category list against the rule name |
| The failure concerns a rule-providers file or rule syntax | Check the relevant file, format and first error; this is a separate problem |
Service runtime data and app data can differ
The service core updates data in its own runtime directory, while app-side prevalidation reads the app's configuration directory. A new database working in the service does not mean the app has the same copy when you activate a configuration again. Repeating the original action may keep producing the same old-category error.
The official fix tries to read the service databases back before file prevalidation and validation of a generated configuration. The validation cache also accounts for GEO file sizes and modification times. Updating only the Mihomo core or changing rule order cannot replace this Clash Verge Rev application update.
Automatic synchronization has conditions: the current service session must support reading GEO files back, the target file must already exist in the app directory, and the service file's modification time must be strictly later than the app copy's. Missing capabilities, sessions or local files can cause a skip. An older service copy will not overwrite a newer local app file.
The fixed implementation handles Country.mmdb, ASN.mmdb, geoip.dat, geosite.dat, geoip.metadb and GeoSite.dat. This is the synchronization file list, not a requirement to use every file on every device or a promise to synchronize arbitrary custom filenames.
Mihomo's geodata-mode determines whether GeoIP uses mmdb or dat; geox-url specifies the corresponding data sources. Record the actual format and source first. Renaming another format's extension or switching to a database with different categories is not a reliable way to make validation pass.
Keep a working configuration, then update the app and original data source
Save the current Profile, persistent overrides, original mode and node selections, with a separate recoverable copy. Record the complete failing rule, category name, data source and format. Preserve originals of manually maintained databases too. Use a separate redacted copy for public support; do not upload subscription tokens or a complete configuration archive.
The verified stable application release containing this fix is v2.5.10. There is no need to downgrade from a later stable release with evidence of the same fix. Update from the official release linked in the references, matching your system, architecture and existing installation method. This website maintenance run does not replace hosted installers.
Use consistent data for updating and validation
Quit normally, then update the complete application
Save your work. When you can interrupt networking, record and stop the current traffic capture, quit the app fully from the tray, then complete the official application update. Keep the data directory; do not replace service files manually or delete databases.
Reopen and check the app and service state
Confirm that the actual app contains the v2.5.10 fix and that the original configuration and overrides remain. Activate a known working configuration first so the service core runs, then update the data. If the service is incompatible or cannot start, address that error before repeating GEO updates.
Update GeoData from the original source
Open Settings → Clash Setting → Update GeoData. Keep the original database source, format and required proxy route, then wait for the update result. Preserve the first log error if downloading or reading fails; dismissing a notification does not establish success.
Reactivate the configuration that originally failed
Save the source configuration you maintain, then activate the same problem Profile again so the app validates it anew. The GeoData Updated notification alone is not enough. Do not edit the generated runtime YAML directly.
If synchronization still fails, stop adding changes
If the log says failed to sync geo database, record the specific file and subsequent validation result. An update notification concerns the core's update operation; it cannot alone prove that the app copy, required category and configuration validation are all correct.
After the same rule passes validation, check its actual matches
Confirm that the previously failing configuration can be saved and activated, that the first category error no longer appears and that the rule retains its original meaning. Deleting GEO rules, routing everything directly or removing the problem category would make a passing result an invalid comparison.
Using the system proxy or TUN you originally needed, make a new real request that should match that rule. On the client's Connections page, inspect the new connection's matched rule and actual exit, and confirm that the task succeeds. An old persistent connection, node latency or update notification cannot replace this check.
Reopen the app normally, activate the same configuration and check again. If it fails after restarting, preserve the new first error. Distinguish data overwritten by another source, unavailable service readback and a genuinely missing category. One update notification does not establish lasting recovery.
Verify this repair
- The actual Clash Verge Rev app contains this synchronization fix, and the original service mode works normally.
- The actual data source and format are known, and the database in use contains the required category.
- The original problem Profile validates and activates again, with the rule's meaning preserved.
- A new real request matches the intended rule and exit, and the everyday task works.
- The same configuration still activates after reopening normally; any synchronization warning has been investigated.
We have not installed or tested a real client to reproduce this issue. This guide is based on official release notes, fixed-version source code and Mihomo documentation. Website multilingual, source-level and browser checks cannot replace database and real routing verification on your device.
If it still fails, recover according to the file or category error
The GeoData update itself fails
Check whether the original source is reachable, the proxy route in use and the first download or file error. Keep the working originals. Do not fetch replacement databases from unknown sources or change whole-disk permissions or the system clock to force success.
A synchronization warning appears, or the app directory lacks the target file
Keep the specific filename and service state. Follow the project's supported process to check the matching service component and local app data. This fix does not automatically restore every missing file; do not manually place files in the service runtime directory.
The update and synchronization completed, but a category is still missing
Recheck the data source's actual category list, spelling and format. Categories from different sources are not interchangeable. Do not continue treating this result as the old-database synchronization issue.
The previously working configuration also fails after updating
Save the current state separately. First restore the configuration verified before upgrading, its original source and a matching database copy; leave new categories unused for now. If you need to roll back the app, use the project's supported method and avoid old and new programs contending for the only data directory.
If you cannot update the app or confirm the data yet, continue with an older configuration you have verified works, keeping the pending rules. This restores work without fixing the old version's synchronization defect. It does not require permanently disabling all GEO rules.
For support, provide the operating system, full app version, service mode, a redacted copy of the failing rule, database source and format, and the separate results of updating, synchronization and validation. Do not provide only the final error or publish sensitive destinations or a complete log archive.
References
- Clash Verge Revv2.5.10 stable release: service-mode GEO update synchronization fix
- Clash Verge RevFix 726b2b3: read service-updated GEO databases back before validation
- Clash Verge Revv2.5.10 service code: readback conditions, timestamps and complete writes
- Clash Verge Revv2.5.10 validation code: synchronization calls and GEO cache inputs
- Clash Verge Revv2.5.10 settings: the GeoData update control
- MihomoOfficial Mihomo general configuration: GEO formats, sources and automatic updates