Configuration Practices · Clash Technical Blog

FlClash ignores geox-url: Geo data fixes

Changed geox-url in a subscription, but FlClash still uses other Geo data? Compare Resources with the final config, set trusted URLs for the right types, sync and test rules. Restore the original URL and working config if needed.

Read the articleBack to blog
  • FlClash
  • geox-url
  • Geo resources
  • Resource updates
  • Profile
On this page
Published
Updated
Estimated reading time
About 9 minutes

Changing a data download address is meant to restore rules, but a correct address in the subscription does not necessarily mean the app uses it. Resource-page settings can affect multiple profiles. Identify the file type, the active address, and the original working copy before making an update you can undo.

Why is other Geo data used after geox-url changes?

When generating the final configuration, v0.8.99 replaces geox-url with the entire set of geoXUrl addresses in the app settings. The four addresses entered in the subscription may therefore not reach the core; editing only the subscription does not guarantee that they take effect. You do not need to install the reporter’s branch for the troubleshooting below, and unmerged changes cannot be treated as an official fix.

Compare the subscription’s geox-url, FlClash resource settings, and the final configuration. If the trusted mirror appears only in the subscription while the preview still shows another set of addresses and resource downloads or rule loading keep failing, record the differences across all three places rather than repeatedly updating the subscription.

Official repository issue #2642 reports this on the v0.8.99 Linux AppImage and says it also reproduces on Android. No maintainer-confirmed fixed version was available at this review. The diagnosis and temporary recovery come from pinned-version source code; not every Geo error has this cause.

If the final addresses are already correct, check download access, data format and the required rule categories instead. This is separate from the resource size and timestamp refresh covered in our v0.8.98 article: refreshed file details do not establish a change in download-source priority.

Which resource needs changing, and will its data support your rules?

Back up the Profile, app settings and working resources, and record each current URL on the Resources page. Identify the Geo file, rule and category named in the error. Record the full FlClash version, operating system and original test request; keep subscription credentials and original backups on your device.

MMDB, ASN, GEOIP and GEOSITE on the Resources page map to different config fields. Change only the item you need, and confirm its content and format using the data maintainer's own documentation. A file being downloadable does not make it suitable for all four slots.

Resource items and config fields

Resources itemgeox-url fieldWhat to check
MMDBmmdbGeoIP data in an MMDB-type format; the v0.8.99 default address names geoip.metadb.
ASNasnASN data; the default file is GeoLite2-ASN.mmdb. A country-category file is not a substitute.
GEOIPgeoipGeoIP data in dat format; the default filename is geoip.dat.
GEOSITEgeositeDomain-category data; the default filename is geosite.dat.

Mihomo uses geodata-mode to select dat or MMDB for GEOIP. Keep the original mode while checking the URL rather than changing it just to get a download to succeed. Custom data must also contain the categories referenced by your rules; otherwise rule loading can fail even after a successful download.

A mirror can change the data itself, not just download speed. Prefer a verified mirror of the same dataset. If the original publisher provides a checksum, verify the matching version. A login page, sharing page or error page with a familiar extension is not Geo data.

Edit the resource address, then wait for sync to finish

v0.8.99 prefills the current URL and updates the app-level geoXUrl on submission. This resource setting is shared across the device and affects other Profile entries. Switching back to the original subscription does not restore the addresses.

The instructions below use the v0.8.99 resource editing and synchronization menus; labels vary by language. Retain original values and enter only complete HTTPS download addresses from trusted sources in the correct format. Avoid unverified mirrors and do not disable certificate verification or security software.

Change only the resource you need to recover

  1. Save the current URL

    Find the resource in the FlClash resource page, open its More menu and choose Edit. Copy the original address from the edit box into a local record and check that the item matches the corresponding geox-url field. Preserve the complete address even if it was already customized.

  2. Submit the new trusted address

    Enter the target address in the same item's edit dialog and submit. Wait for the app to update its configuration, then reopen the dialog and final config preview to confirm the value changed.

  3. Sync that resource

    Choose Sync from this item's more menu and start one update. Wait until the updating state ends, then check any error or skipped-update notice and the file details.

  4. Reload and check the rules

    Reapply the current configuration through the app's normal controls. If necessary, stop and restart the proxy normally. Use the original request to check the relevant rule match and actual outbound, then test your other usual Profile entries.

The sync call returning means only that the core accepted the request; later events report completion or failure. Do not declare success immediately after clicking. Size and timestamps are supporting evidence and may stay unchanged when the content is identical or an update is skipped. Check completion, rule loading and real requests as well.

If the edited value will not save, stop repeatedly syncing and retain the error. If the address saves but the download fails, check access to that source on the current network, whether redirects still lead to a data file, and whether logs report a format or category error. Leave unrelated resources alone.

Check the resource URL and rules; restore the original resource settings if recovery fails

Recovery verification checklist

  • The matching URL agrees between Resources and the final config, beyond the subscription text
  • Sync has finished with no unresolved download or parsing errors
  • The data contains the categories your rules need, and those rules load
  • The same real request matches the expected rule and uses the expected outbound
  • The URL remains correct after a normal quit and restart, and other usual Profile entries still work

If recovery fails, enter the saved original URL in the same resource's edit dialog, sync again and reapply the previously working config. Reset in the dialog restores the app default. If your original address was customized, resetting does not restore your original setting.

Reverting a URL does not retrieve a data file that has already been replaced. If the original source is reachable, sync the original data again. Otherwise, retain existing files and local backups and pause further updates. Check what a backup contains before restoring app settings; do not assume it includes Geo files. Avoid assembling incompatible files or clearing all configuration.

If rules still will not load, stop using the affected config and choose a verified working Profile. App resources remain shared, so verify it after switching too. If no config works, stop the proxy normally and check ordinary networking. Pause any activity that must use a proxy.

For an upstream report, provide the full version, system, redacted original and final geox-url, resource item, update status, first error and rule matches after restart. Retain category names and field structure, while hiding subscription tokens, private mirror credentials and personal addresses.

References