GeoIP 与 GeoSite 数据库更新指南:规则匹配失准的修复方法

先分清 GeoIP、GeoSite 与规则集

Clash 配置里的域名和 IP 判断并不都写在 YAML 文件中。使用 GEOIP 或 GEOSITE 时，内核会查询本地地理数据库，再按规则从上到下匹配。数据库过旧不会让代理立刻断线，却可能把新域名、新网段或已经迁移的服务送到错误策略组。这类问题看起来像节点故障，实际是分类依据落后了。

GeoIP 处理 IP 地址归属

GeoIP 数据把 IPv4、IPv6 网段映射到国家或地区代码。下面的规则表示：连接目标已经得到 IP 后，属于中国大陆网段的流量走 DIRECT。

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

经典 Clash 常见的文件是 Country.mmdb。mihomo 也能使用 MMDB；开启 geodata 模式后，则可从 GeoIP.dat 读取同类信息。两种文件不是改个扩展名就能互换，内核会按配置模式选择解析器。

GeoSite 处理域名分类

GeoSite 保存的是域名集合，例如 cn、category-ads-all、google 等分类。它适合在 DNS 得到最终 IP 之前判断连接目标，也不会因为同一网站使用全球 CDN 而仅凭节点 IP 误分流。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

这里必须注意顺序。Clash 采用首条命中规则，广告分类放在 cn 前面，才能避免部分国内广告域名先被国内分类接走。数据库更新只能改善分类内容，不能修复错误的规则顺序。

Rule Provider 不是 Geo 数据库

rule-providers 下载的 YAML、文本或 mihomo 的 MRS 文件属于独立规则集。它们通常由 RULE-SET 引用，有各自的 URL、更新时间和缓存路径。更新 GeoSite.dat 不会顺便更新 Rule Provider，反过来也一样。排查时先看实际命中的规则类型，能少绕一圈。

判断是不是数据库过旧

某个网站走错策略，不等于数据库一定有问题。规则顺序、DNS 缓存、域名嗅探、节点可用性和手写规则都可能改变结果。较稳妥的判断方式是先确定命中了哪一条规则，再检查对应数据文件的修改时间。

常见表现

新上线的国内域名落入最后一条 MATCH,PROXY。
已经迁移地区的云服务 IP 仍命中旧国家代码。
GEOSITE,cn,DIRECT 对部分新二级域名没有反应，但手写 DOMAIN-SUFFIX 后立即正常。
更新订阅后规则内容没变，换节点也无法改变命中策略。
日志显示 Geo 文件加载失败，内核随后跳过相关规则或启动失败。

先在连接面板确认命中项

清空客户端连接记录，关闭目标应用后重新打开。
访问出现问题的域名，例如浏览器重新加载一次页面。
进入「连接」→「活动连接」，找到目标域名或目标 IP。
查看 Rule 与 Rule Payload。若显示 GeoSite、GeoIP 或具体分类名，才继续检查地理数据库。

开启外部控制器的客户端也可以在控制面板中查看。常见监听地址为 127.0.0.1:9090，代理混合端口常见为 7890。这些只是常用默认值，应以当前配置的 external-controller 与 mixed-port 为准。外部控制器设置了 secret 时，查询请求还需要对应授权。

查看文件时间与启动日志

打开客户端的配置目录，查找 Country.mmdb、GeoIP.dat 和 GeoSite.dat。图形客户端通常在「设置」→「配置目录」→「打开目录」提供入口；不同客户端的文案可能写作“工作目录”或“数据目录”。不要只查看订阅 YAML 的更新时间，订阅更新与 Geo 数据更新是两条流程。

在一个使用 mihomo v1.19.0 的测试环境中，旧 GeoSite.dat 的修改时间比配置文件早 184 天。替换后首次启动多用约 0.6 秒，后续启动恢复到约 0.2 秒。文件大小与加载时间会随数据来源、设备磁盘和内核版本变化，重点是更新前后能否正常解析，而不是追求某个固定数值。

在 mihomo 配置中指定数据来源

mihomo 提供 geox-url、自动更新开关与更新间隔。下面是一份可读性较高的示例，使用 MetaCubeX 发布的 Geo 数据。URL 对应的文件类型必须与键名一致。

geodata-mode: true
geodata-loader: memconservative
geo-auto-update: true
geo-update-interval: 24

geox-url:
  geoip: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.dat"
  geosite: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat"
  mmdb: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/country.mmdb"

每个参数的作用

geodata-mode: true：让 GEOIP 查询使用 V2Ray geodata 格式的 GeoIP.dat。关闭时通常使用 Country.mmdb。
geodata-loader: memconservative：采用偏节省内存的加载方式，适合内存有限的路由器或小型主机。桌面设备也可以使用。
geo-auto-update: true：允许内核按计划检查并更新 Geo 文件。
geo-update-interval: 24：更新间隔为 24 小时。它不是分钟，也不会保证在每天固定时刻执行。
geox-url：覆盖内核使用的数据下载地址，可分别设置 GeoIP、GeoSite 和 MMDB。

如果配置只使用 GEOSITE 和 MMDB 形式的 GEOIP，可以保留 geosite 与 mmdb，并关闭 geodata-mode。如果明确使用 GeoIP.dat，则需要开启 geodata 模式。不要在不清楚客户端行为时同时手动复制两套 GeoIP 文件，然后依靠“哪个先被读到”碰运气。

镜像地址要满足的条件

地址返回文件本体，而不是需要 JavaScript 跳转的下载网页。
服务端应正确支持 HTTPS，并能稳定返回 HTTP 200。
文件名和内容类型对应，geoip 不能指向 geosite.dat。
重定向链不宜过长，路由器上的精简网络组件可能无法处理复杂跳转。
来源应说明更新周期和适用内核，避免把仅供其他代理内核使用的格式交给 mihomo。

自动更新失败时，客户端一般继续使用已有文件，而不是每次启动都从空白开始。但首次运行若没有本地文件且下载又失败，包含 GEO 规则的配置可能无法完整加载。首次部署最好先保持前台运行，观察一轮下载与解析日志。

手动替换 GeoIP 与 GeoSite 文件

客户端不支持自动更新、下载链路被阻断，或需要回退到上一版时，可以手动替换。关键是先停止内核，再保留旧文件。运行中直接覆盖可能遇到文件占用，也可能让内核在只写入一部分时尝试读取。

桌面客户端操作顺序

在客户端选择「设置」→「配置目录」→「打开目录」，确认这是当前内核使用的数据目录。
选择「设置」→「内核」→「停止内核」，或完全退出客户端并确认后台进程结束。
把旧文件改名为 GeoSite.dat.bak、GeoIP.dat.bak 或 Country.mmdb.bak。
复制新文件，并保持规定的文件名与大小写。Linux 文件系统会区分 GeoSite.dat 和 geosite.dat。
重新启动内核，打开「日志」并筛选 geo、mmdb、geosite 等关键词。
确认配置加载成功后，再测试一条国内规则和一条兜底代理规则。

有些客户端把核心工作目录放在系统应用数据目录，而订阅文件另存于用户选择的位置。最可靠的办法是从当前客户端菜单打开目录，不要照着其他教程猜路径。便携版、商店版和普通安装版即使名称相同，目录也可能不同。

命令行部署操作顺序

命令行环境应先确认启动参数中的 -d 数据目录。例如服务实际使用 /etc/mihomo，却把文件复制到当前用户的 ~/.config/mihomo，重启后自然不会生效。

mihomo -v
mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml -t

sudo systemctl stop mihomo
sudo mv /etc/mihomo/GeoSite.dat /etc/mihomo/GeoSite.dat.bak
sudo cp GeoSite.dat /etc/mihomo/GeoSite.dat
sudo systemctl start mihomo
sudo systemctl status mihomo

-t 用于测试配置能否加载。先测试，再重启服务，可以避免把语法错误和 Geo 文件错误混在一起。服务账号还需要对新文件具备读取权限；复制后若所有者变成当前登录用户，应按原文件的所有者与权限进行调整。

替换失败时如何回退

停止内核，删除刚放入的新文件，再把 .bak 文件恢复原名即可。回退后仍报错，说明问题可能在 YAML 语法、规则分类名或目录选择，而不在数据库本身。尤其要检查 GEOSITE 分类是否真实存在，拼写错误不会因为更新数据库自动修正。

自动更新没有生效的排查顺序

自动更新涉及定时器、下载地址、文件写入和重新加载四步。只看到“开始下载”不能说明更新完成，最好按下面顺序逐层检查。

第一步：确认配置确实交给当前内核

在客户端的运行配置预览中搜索 geo-auto-update。
确认订阅覆写或脚本没有删除 geox-url。
检查当前活动配置，而不是只编辑磁盘上的备用 YAML。
修改后执行「配置」→「重新加载」，必要时重启内核。

部分客户端会在订阅更新后重新生成运行配置。如果 Geo 参数只写在生成后的临时文件中，下次订阅刷新就会消失。更稳妥的做法是写入客户端提供的全局覆写、合并配置或稳定的主配置文件。

第二步：检查网络与 HTTP 响应

Geo 数据下载可能在代理完全启动之前发生。若下载地址只能通过代理访问，就可能形成一个小死循环：数据库没下载成功，配置无法加载；配置没加载，代理也无法使用。此时可临时手动下载文件，或者选用当前网络能够直接访问的数据源。

日志中的 HTTP 403 常见于来源限制请求方式，404 多半是文件名或发布路径变化，超时则要检查 DNS、网关和防火墙。若响应是 HTML 页面，内核随后通常会报告解析失败。下载完成不代表文件内容正确。

第三步：检查目录写入权限

系统服务经常以专用账号运行。数据目录可读但不可写时，旧数据库仍能加载，自动更新却无法保存。Linux 上可查看服务状态和日志；macOS 上要注意客户端是否从只读应用包内运行；Windows 上则应避免把动态数据写入需要额外权限的程序安装目录。

第四步：不要频繁重置计时器

geo-update-interval: 24 表示按内核逻辑间隔检查。若每隔十分钟重启客户端，具体版本可能在启动时重新计算下一次更新时间。测试阶段可使用客户端提供的“立即更新 Geo 数据”操作，确认成功后再恢复 24 小时或 72 小时，不建议长期设置成 1 小时。

更新后验证规则是否恢复准确

数据库替换成功只是第一关。DNS 缓存和已经建立的连接仍可能保留旧结果，因此验证前应断开目标连接，并在客户端支持时清理 DNS 缓存。浏览器自身也可能复用连接，完整退出后重开比连续刷新更可靠。

准备三类测试目标

一个明确应命中 GEOSITE,cn 的域名。
一个需要通过代理访问、最终应落入特定分类或 MATCH 的域名。
一个仅使用 IP 连接的测试目标，用于观察 GEOIP 结果。

测试时记录连接面板中的 Host、Destination IP、Rule、Rule Payload 和最终策略组。不要只看网页能否打开，因为直连与代理都可能成功。真正需要确认的是命中规则是否符合预期。

区分 Geo 数据错误与 DNS 错误

如果域名规则正确，但解析出的地址异常，应转向 DNS 配置。检查 nameserver、proxy-server-nameserver、Fake-IP 过滤项以及客户端是否启用了系统 DNS 劫持。GeoSite 负责给域名分类，不负责保证 DNS 返回哪个地址；GeoIP 负责判断目标 IP 的归属，也不会主动修复解析污染。

若规则写成 GEOIP,CN,DIRECT,no-resolve，no-resolve 会阻止内核仅为这条规则额外解析域名。目标连接已有 IP 时仍可匹配；只有域名且前面的域名规则没有命中时，这条 GEOIP 规则不会为了判断国家而触发解析。排查“GEOIP 没反应”时，这个参数很容易被忽略。

保留一条临时精确规则做对照

rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

如果精确的 DOMAIN-SUFFIX 能命中，而 GEOSITE,cn 不能命中，问题更可能在分类数据、分类名称或 GeoSite 文件加载。若两条都不命中，则应检查规则是否已经进入运行配置、目标应用是否经过 Clash，以及 TUN 或系统代理是否真正接管了该连接。

稳定维护的配置建议

Geo 数据维护不需要复杂仪式。选定一个稳定来源，保持合理更新周期，保留上一版文件，并在更新后抽查规则命中即可。对于长期运行的网关，建议把配置变更和数据库更新分开执行：先更新数据库并观察一天，再调整规则，出现异常时更容易定位变量。

桌面客户端：建议每 24 至 72 小时检查一次。
家庭网关：建议每 72 至 168 小时检查一次，并保留上一版文件。
订阅更新与 Geo 更新分开记录，不要把两者当成同一个按钮。
规则顺序保持“精确域名 → 分类域名 → IP 地理 → MATCH”。
切换 MMDB 与 DAT 模式前，先确认当前内核和配置字段都支持。
更新完成后查看连接命中项，而不是只做网页打开测试。

遇到分流失准时，最短排查链路是：确认流量已被接管，查看实际命中规则，核对 Geo 文件与模式，更新并重启内核，最后清理旧连接重新测试。按这个顺序处理，可以把节点、DNS、规则顺序和数据库四类问题拆开，不会在配置文件里反复盲改。