Mihomo 提示 Can't find MMDB：GEO 数据下载失败别先重置订阅
Mihomo 缺少 MMDB 后会尝试取得 GEO 数据；后续的超时、DNS 解析失败或 permission denied 分别指向下载路径和写入权限，不等于机场订阅失效。
先看重点保留当前订阅。`Can't find MMDB, start download` 只说明本地缺少 GEO 数据并准备下载；继续看后面的错误：`context deadline exceeded` 或 `lookup ... timeout` 指向 GEO 下载地址与 DNS，`permission denied` 指向工作目录写入权限。订阅更新接口本身没有报错时，不要先重置 token。
客户端刚载入配置，日志先出现 Can't find MMDB, start download，界面却迟迟没有进入可用状态。这个时候删除订阅、重置 token，通常碰不到真正出错的地方。
这行日志说的是本地 GEO 数据，不是节点订阅。 关键证据在它后面：下载是否完成，还是卡在域名解析、网络连接或文件写入。
Can't find MMDB 本身还不是失败结论
Mihomo 找不到需要的 MMDB 文件时，会记录这行信息并尝试下载。官方仓库 Issue #474 的日志样本在出现它之后仍完成了初始配置，说明单独看到 Can't find MMDB，不能直接判断内核启动失败。
真正需要分流的是紧随其后的内容：
| 后续日志 | 能确认的故障层 | 不应直接归因于 |
|---|---|---|
随后出现 Initial configuration complete |
本次初始化继续完成 | 订阅损坏 |
context deadline exceeded |
GEO 数据下载在时限内没有完成 | 节点全部失效 |
lookup ... i/o timeout |
下载地址的域名解析失败 | 机场 token 过期 |
permission denied |
运行 Mihomo 的进程无法写入目标位置 | 订阅格式错误 |
rules[...] [GEOIP,...] error 并带有下载错误 |
配置解析依赖 GEO 数据，但初始化没有完成 | 该节点测速失败 |
Issue #1495 给出的完整日志是 GEO 下载域名解析超时；Issue #1915 则是写入 geoip.metadb 时被系统拒绝。两条日志都以 MMDB 初始化失败结束，根因却完全不同，因此只截取第一行没有诊断价值。
GEO 数据和订阅是两条维护路径
官方 API 文档把 GEO 数据更新列为 /configs/geo、/upgrade/geo，代理提供者则有单独的 /providers/proxies/... 更新入口。由这个接口划分可以判断，两者是不同的维护对象；具体图形客户端怎样调用这些接口，仍以该客户端实现为准。
订阅负责提供节点或完整配置，GEO 文件用于 GEOIP、GEOSITE 等匹配。重置订阅 token 不会自动修复工作目录权限，也不会让一个无法解析的 GEO 下载域名突然可访问。反过来，GEO 更新失败也不能证明账户到期、流量用完或机场节点停运。
这和远程 rule-provider 更新失败也不是同一层。后者下载的是配置指定的规则集，影响范围可对照规则集更新失败会不会影响当前上网；不要把两个带有“规则”字样的错误混成一次订阅故障。
文件名为什么有时不是 MMDB
Mihomo 官方文档说明，geodata-mode 决定 GeoIP 数据使用哪种格式：默认的 false 选择 MMDB，true 选择 DAT。geox-url 又分别提供 geoip、geosite、mmdb 和 asn 的下载地址；geo-auto-update 默认关闭，更新间隔以小时设置。
因此，别人配置里出现 geoip.dat，你的日志却在找 MMDB，并不一定是谁写错了文件名。两份配置可能选择了不同模式。更值得核对的是客户端实际交给内核运行的配置、日志显示的目标文件，以及当前下载地址是否和该模式对应。
不明模板和陌生镜像会同时改变文件格式、下载域名与信任边界。没有确认维护者和文件来源时，不要为了绕过一次超时就替换 geox-url；下载成功也不能证明拿到的是预期数据。
按完整错误处理，不靠反复重导
看到 context deadline exceeded 或域名解析超时，保留日志里的下载主机与具体错误。Issue #1495 的样本存在 DNS 依赖环：下载域名交给尚未成功启动的 Mihomo 解析，结果彼此等待。它能说明这种故障确实可能发生，不能证明每次超时都是同一个原因。当前 DNS 路径、下载地址和网络可达性需要分别核对。
出现 permission denied 时，问题落在运行身份、工作目录或服务约束。应让 Mihomo 对自己的数据目录拥有必要写入权限，而不是把整个目录改成任何用户都能写，也不必为了省事长期用管理员身份运行图形客户端。
如果日志只出现一次缺少文件提示，随后配置加载完成、规则可正常匹配，就没有理由仅为消除这行信息而删除缓存。频繁清空数据反而会让下一次启动重新触发下载。
订阅本身出现 401、403、YAML 解析错误或提供者更新失败时，才转到订阅更新报错的分层判断。分享日志求助前，保留错误类型、文件名和时间，遮住订阅 URL、token、节点凭据与本机用户名；具体边界见Clash 日志脱敏清单。
能帮助定位的不是“MMDB 报错”四个字，而是从 Can't find 到最终 ERROR 或 FATAL 的完整一段。它会直接告诉你该检查下载路径、DNS，还是文件权限。
资料来源
以下来源于 2026/8/30 复核。版本、支持平台和发布状态以后续官方页面为准。
持续更新
收到新教程，也欢迎纠错
想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。
读者互动
这篇内容对你有帮助吗？
最新评论
- 正在加载评论……