Clash GeoIP 与 GeoSite 数据更新：规则引用、刷新周期和异常处理

先区分 GeoIP、GeoSite 与规则集

结论先行：GeoIP 根据目标 IP 地址归类，GeoSite 根据域名归类，两者不能互相替代。配置中写了 GEOIP 或 GEOSITE，只代表规则引擎会查询对应数据库；最终是否走直连、代理或拒绝，仍由规则末尾指定的策略决定。数据库本身不负责建立代理连接，也不会自动改变当前代理模式。

GeoIP 数据把 IP 网段映射到国家、地区或其他可识别分类。常见规则 GEOIP,CN,DIRECT 的含义是：当连接的目标 IP 被数据库归入 CN 时，交给 DIRECT 策略处理。不同内核可能使用 MMDB、专用 GeoIP 数据文件或经过转换的内部格式，文件名和加载方式并不完全一致，因此不能只看扩展名判断数据库是否已被当前内核使用。

GeoSite 数据保存域名集合及分类标签，例如地区域名、常用服务或广告域名分类。规则 GEOSITE,cn,DIRECT 会对连接中的域名进行集合匹配。它适合在 DNS 解析前完成域名分流，也能避免仅依赖 IP 归属时遇到 CDN、全球调度和共享地址造成的误判。

规则集通常指 rule-providers 提供的外部规则文件。它可以装载域名、IP-CIDR 或经典规则条目，再通过 RULE-SET 引用。规则集与 GeoSite 都能保存域名分类，但它们的下载地址、更新周期、行为类型和配置入口不同。更新了某个规则集，不等于 GeoSite 数据也同步更新；反过来也一样。

配置如何引用 GeoIP 与 GeoSite

规则从上到下检查，命中后停止继续匹配。数据库即使更新成功，如果相关规则排在一个更宽泛的规则之后，流量仍然不会走到新规则。排查“数据库更新了但分流没变化”时，规则顺序通常比重复下载文件更值得优先检查。

下面是一段适用于支持 GEOSITE 的 Mihomo 配置思路。策略组名称必须与本机配置保持一致；示例中的 节点选择 是策略名称，不是固定关键字。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,节点选择

第一条先处理广告域名分类，第二条处理 CN 域名，第三条在已经取得目标 IP 时执行 CN 地址匹配，最后一条接管此前未命中的连接。如果把 MATCH 放到开头，后续数据库规则将永远没有匹配机会。如果在 GEOSITE,cn,DIRECT 前放置了覆盖范围更大的域名规则，也可能提前截获本应直连的域名。

no-resolve 常用于 IP 类规则，作用是避免规则引擎为了执行该条匹配而额外触发域名解析。它不表示跳过已经存在的目标 IP，也不会关闭 DNS 模块。对于直接以 IP 发起的连接，GeoIP 仍然可以匹配；对于当时只有域名、尚未得到真实目标 IP 的连接，该条规则可能无法给出命中结果，流量会继续检查后续规则。

域名规则与 IP 规则应同时保留吗

多数按地区分流的配置会同时保留。GeoSite 在域名仍可见时先做判断，GeoIP 则为直接访问 IP、缺少域名信息或域名规则未覆盖的连接提供补充。由于 CDN 节点可能位于不同地区，域名所属服务与目标 IP 所在地区并不总是一致。需要稳定服务级分流时，应把明确的域名或 GeoSite 分类放在前面，再让 GeoIP 处理剩余连接。

TUN 与 Fake-IP 模式下的判断位置

TUN 模式负责接管更多系统流量，不会自动提升规则数据库的准确度。启用 Fake-IP DNS 后，客户端向应用返回的是内部映射地址，内核会尽量恢复原始域名并执行域名规则；后续建立真实连接时仍可能得到目标 IP。若某个应用直接连接硬编码 IP、使用自身解析机制，或者流量缺少可恢复的域名信息，GeoSite 就未必参与，此时 IP 规则和最终兜底策略更重要。

遇到开启 TUN 后规则表现不同，不应直接认定数据库损坏。先比较该连接在普通系统代理和 TUN 下是否保留域名，再检查 DNS 模式、嗅探设置、Fake-IP 过滤项与规则顺序。数据库只提供匹配数据，连接上下文由内核接管方式决定。

选择可回退的数据更新方式

更新方式大致分为客户端托管、内核自动更新和手动替换三类。优先使用客户端或内核已经提供的更新入口，因为它们通常知道数据目录、文件命名和重载流程。手动下载适合需要固定版本、内网分发或定位更新故障的场景，但替换前必须确认文件格式与当前内核兼容。

客户端托管更新

部分桌面和移动客户端会在设置页提供 GeoIP、GeoSite 或规则数据更新按钮。点击后，客户端负责下载并放入自己的运行目录，有些实现会自动重启内核，有些只在下一次加载配置时生效。操作后应查看更新结果、文件日期和内核日志，不要只根据按钮状态判断成功。

Mihomo 内核自动更新

支持 Geo 数据自动更新的 Mihomo 版本可通过配置控制是否刷新以及刷新间隔。不同版本对字段、数据格式和默认地址的处理可能调整，因此应以当前内核文档和客户端生成的配置为准。常见配置结构如下：

geo-auto-update: true
geo-update-interval: 24

geo-update-interval 通常按小时理解。24 小时适合一般使用，不需要把刷新间隔压缩到几分钟。Geo 数据并不是实时路由表，过于频繁地请求只会增加启动失败、网络超时和文件写入冲突的机会。对稳定性要求较高的设备，可以采用一周一次或随客户端维护窗口更新，再通过日志确认结果。

如果配置还定义了 geox-url，内核会按相应地址获取 GeoIP、GeoSite 或 MMDB 数据。此处的数据源必须提供当前内核能够识别的内容；把网页地址、压缩包下载页或另一种格式的文件填进去，即使请求返回成功，也可能在加载阶段失败。由订阅转换服务生成配置时，还要确认远端更新不会覆盖本地的自动更新字段。

手动替换数据库

1. 在客户端中停止内核，避免数据库正在读取时被覆盖。
2. 找到客户端实际使用的数据目录，而不是安装包解压目录或浏览器下载目录。
3. 备份当前可用文件，并记录内核版本与原文件修改时间。
4. 放入格式匹配的新文件，保持客户端要求的文件名和访问权限。
5. 重新启动内核并加载配置，检查日志中是否出现解析、打开或权限错误。
6. 使用具体域名和 IP 测试规则命中，不以“文件变大了”作为更新成功依据。

更新失败或规则未生效时逐层检查

排查应把“下载失败”“文件加载失败”“规则没有引用”和“规则命中但策略结果不符合预期”分开。它们在界面上都可能表现为网站走错线路，但处理方法完全不同。建议按数据下载、内核加载、配置解析、规则命中、策略执行五层检查。

第一层：数据是否完成下载

• 查看日志中的请求状态、超时、DNS 解析和连接错误。
• 确认更新流量本身能访问数据源；启动阶段尚未建立代理时，下载可能只能使用直连网络。
• 检查系统时间。时间明显错误可能导致 TLS 连接无法建立。
• 确认存储空间和目录写入权限，移动端还要注意系统是否回收了应用数据或限制后台网络。
• 检查客户端是否把下载结果写入另一个配置实例的数据目录。

第二层：内核是否成功加载文件

下载完成不等于可加载。日志若出现数据库格式无效、标签不存在、文件打开失败或解析异常，应先回退到之前可用的数据文件。常见原因包括文件内容实际是错误页面、数据格式与内核不兼容、下载中断留下不完整文件，以及文件名或目录与客户端约定不一致。

如果更换内核后才开始报错，要同时检查客户端是否仍保留旧内核的数据选项。例如某个客户端允许在 MMDB 与其他 Geo 数据加载方式之间切换，切换内核但没有同步调整模式，就可能出现文件存在却没有被读取的情况。

第三层：当前配置是否真的引用数据库

在实际运行配置中搜索 GEOIP、GEOSITE 或相关 RULE-SET。订阅页面显示的原始 YAML 不一定等于内核最终加载的配置，客户端可能合并覆写规则、脚本或本地补丁。应优先查看客户端导出的运行配置，确认规则名称、策略组名称和缩进都正确。

GeoSite 分类名称必须存在于当前数据中。更新数据源后，分类可能增加、拆分或调整；如果配置引用了数据中不存在的标签，内核可能在加载时直接报错，也可能使该规则无法达到预期。分类名称应与数据源说明一致，不能根据显示文案自行推测。

第四层：规则是否有机会命中

打开连接日志或客户端的连接详情，观察目标主机、规则类型、规则载荷和最终策略。若显示命中 MATCH，通常说明前面的 Geo 规则没有匹配或根本没有执行。若显示命中另一条 DOMAIN-SUFFIX、IP-CIDR 或 RULE-SET，则应调整规则顺序，而不是继续更换数据库。

对 GeoIP 测试还要确认目标地址。一个域名可能返回多个 IPv4 或 IPv6 地址，并根据地区、网络和时间发生变化。浏览器已有连接、DNS 缓存和 QUIC 会话也可能让测试继续使用旧地址。修改配置后，可重启对应应用或清理连接，再做一次新的访问测试。

第五层：命中后策略是否可用

规则命中只决定把连接交给哪个策略。若策略组当前选择了不可用节点、延迟测试尚未完成，或者直连网络本身无法到达目标，最终连接仍会失败。此时日志可能明确显示规则已正确命中。应继续检查策略组当前选择、节点状态、DNS 结果和系统代理接管范围，而不是把故障归因于 Geo 数据。

用规则命中记录验证更新结果

可靠的验证至少包含配置加载、典型域名、目标 IP 和兜底流量四项。先确认内核启动日志没有 Geo 数据错误，再选择一个明确属于目标分类的域名观察是否命中 GEOSITE；随后选择一个已知 IP，确认 GEOIP 的分类结果；最后测试不属于前述分类的连接，确保它落到预期的 MATCH 或其他兜底规则。

如果客户端支持规则测试或连接详情，应记录“目标、命中规则、策略组、实际出口”四个字段。仅看到网页能够打开，无法证明分流正确，因为直连和代理都可能访问成功。相反，网页打不开也不一定说明规则错误，策略节点、DNS、IPv6 和应用缓存都可能影响结果。

建议的更新周期

• 普通个人设备：每周或每月检查一次即可，出现明显归属变化时再手动刷新。
• 经常切换配置的设备：让客户端托管更新，并在每次内核升级后检查数据加载日志。
• 长期运行的路由设备：设置稳定的自动更新窗口，保留上一个可用文件，并避免更新与设备重启同时发生。
• 固定规则环境：锁定经过验证的数据版本，在计划维护时统一更新，减少分类变化带来的分流波动。

更新后的最小检查清单

1. 当前内核支持配置中使用的 Geo 规则类型。
2. 数据文件位于实际运行实例读取的目录。
3. 启动日志没有下载、解析、权限或分类名称错误。
4. 运行配置包含预期的 GEOIP 与 GEOSITE 规则。
5. 规则顺序中不存在提前接管全部流量的宽泛条目。
6. 连接详情显示命中了预期规则和策略。
7. 修改后重新建立连接，避免旧 DNS 与会话缓存干扰判断。

GeoIP 与 GeoSite 的维护重点不是追求最高刷新频率，而是确保数据格式、内核能力、配置引用和规则顺序保持一致。更新动作完成后，只要沿着“文件已下载、内核已加载、规则已引用、连接已命中、策略可执行”的链路逐项确认，就能把大多数异常定位到明确层级。