先定位失败阶段，不要一上来重装插件

OpenClash 的“内核更新失败”只是结果，前面可能经历了多个不同环节。官方仓库中的 openclash_core.sh 会读取版本信息，按 CPU 型号和内核类型拼出下载地址，把压缩文件保存到临时位置，执行 gzip 完整性检查，解压后赋予执行权限，再运行新文件的版本命令，最后才移动到正式内核路径。任何一步失败，界面上都可能只看到“更新失败”。

先保存一次完整日志，并记下发生时间、OpenClash 版本、当前内核版本、路由器型号、CPU 架构和所选内核类型。不要只截最后一行红字；版本检查失败、下载失败、gzip 校验失败、版本验证失败、文件移动失败，处理方法完全不同。也不要在同一次排查中同时升级 OpenWrt、替换 DNS、重装 OpenClash 和手动上传内核，否则即使恢复也无法知道是哪项变化生效。

日志阶段常见信号优先检查
版本信息无法获取版本、版本文件为空时间、DNS、HTTPS 与更新源可达性
下载curl 返回解析、连接或 HTTP 错误域名解析、网关、证书与上游连通
压缩包校验gzip test failed 或文件过小下载是否完整、返回内容是否其实是错误页
新内核验证无法执行或版本输出为空CPU 架构、文件格式、执行权限
替换或启动move failed、启动后立即退出空间、只读文件系统、进程占用与配置兼容

先看原始错误：网页通知可能被压缩成一句话，系统日志中的 curl、gzip、chmod、版本输出或移动错误才是决定下一步的证据。

确认版本源、DNS 和 HTTPS 下载链路

如果失败发生在版本检查或下载阶段，先从路由器本身测试，而不是从已经开启代理的电脑推断。确认系统时间正确，因为明显错误的时间可能导致 HTTPS 证书验证失败；再确认 WAN 能获得 DNS 和默认路由。解析失败与连接超时不是一回事：前者通常没有把域名解析成地址，后者则可能已经解析但无法建立连接。

问题 #5098 中曾出现 curl: (6) Could not resolve host: fastly.jsdelivr.net，随后才显示 Smart 内核版本检查失败。这只是一个具体的 DNS 解析案例，不能据此断定所有更新失败都由 jsDelivr 或 DNS 引起。你的日志若是 HTTP 404、TLS 错误、空间不足或 gzip 失败，应按自己的错误处理。

  1. 核对路由器日期、时区和 NTP 同步状态。
  2. 在 OpenWrt 上分别检查更新域名能否解析、443 端口能否连接。
  3. 确认当前 DNS 设置不会依赖尚未启动的 OpenClash 内核，避免循环依赖。
  4. 查看下载得到的文件大小与类型，防止把 HTML 错误页当成压缩内核。
  5. 网络恢复后只重试一次更新，并比较新日志停在哪个阶段。

如果旁路由、主路由或上游防火墙做了域名过滤，还应在不改变整个网络策略的前提下临时验证更新域名。不要用“关闭所有安全设置”作为测试。更稳妥的方法是为路由器自身建立一条明确、可撤销的直连路径，完成下载后恢复原策略，并保留前后日志。

v0.47.156 只是发布快照，不代表所有设备都应升级，也不能证明内核适配本机。

核对 CPU 架构、内核类型和下载文件是否对应

网络正常但新内核无法执行时，重点检查架构。OpenClash 更新脚本会根据配置中的 core_version 选择 CPU 型号，并区分不同内核目标。路由器商品名称不能替代架构信息，同系列硬件也可能使用不同指令集。应以 OpenWrt 实际报告的架构、已安装软件包架构和当前可运行内核的文件信息交叉核对。

不要把压缩格式、内核类型和文件名混在一起。下载产物可能先以 gzip 形式进入临时目录，只有通过完整性检查并解压后才是可执行文件。把压缩包直接改名为 clash_meta 不会变成内核；把其他平台的可执行文件赋予权限也无法解决架构不匹配。若日志出现 Exec format error、非法指令或版本命令无输出，优先回看下载资产，而不是继续修改配置。

不要凭文件名猜架构：手动下载时只使用项目指向的一手发布源，并确认目标架构、内核类型与压缩方式。第三方重命名文件失去了最重要的核对线索。

可把当前工作的旧内核复制到受控备份目录，记录其版本输出和文件大小，再在临时目录验证新内核。验证至少包括：文件类型与设备架构相符、gzip 校验通过、解压后的文件非空、拥有执行权限、运行版本参数能正常返回。只有这五项均通过，才考虑替换正式路径。

如果界面同时提供 Meta、Smart 或其他选项，先确认当前 OpenClash 版本支持该类型以及现有配置是否需要它。内核更新和插件更新有关联，但不是同一个操作。为了消除一个内核错误而盲目升级插件、依赖包和固件，会扩大变更范围并降低回退能力。

检查临时空间、闪存模式、权限与文件占用

下载成功并不代表能够落盘。脚本会先写临时文件，再验证并移动到正式位置；因此临时文件系统和目标文件系统都要有足够空间。官方脚本还包含 small_flash_memory 分支：普通模式的目标位于持久配置目录，小闪存模式可能把内核放到 /tmp 下。后者会受内存文件系统容量和重启后清空的特性影响，不能按普通闪存路径排查。

检查磁盘和 inode 使用量，区分“可用空间很少”与“文件系统只读”。Overlay 损坏、挂载只读、目标目录不存在、权限不足、旧进程仍占用文件，都可能在最后移动或启动时失败。不要为了省空间直接删除当前唯一可运行的内核。先确认备份可读，再清理明确属于缓存或失败下载的临时文件；不确定用途的系统文件不要动。

  • 空间：临时区需容纳压缩包和解压后的文件，目标区还需容纳最终内核。
  • 权限：目录可写，新文件需具备执行权限，所有者与现有文件保持一致。
  • 进程：按界面流程停止或重启服务，不强制覆盖正在写入的文件。
  • 持久性：小闪存模式放在临时区的内核需要由正常启动流程重新准备。
  • 完整性：文件大小合理仍不足够，还要通过压缩校验和版本执行。

若更新在文件移动阶段失败，先比较临时文件和目标文件是否都存在，切勿马上重启路由器。目标仍是旧内核时，可以维持现状并继续诊断；目标文件已被替换但新内核无法执行时，应在服务停止状态恢复备份。每次只做一次可记录的变化。

手动恢复只走最小路径，并验证更新后的完整链路

自动流程反复失败、但已明确确认下载与架构时，才考虑手动恢复。先保留旧内核，不要覆盖唯一副本；从 OpenClash 一手来源取得与设备匹配的文件，在临时目录完成解压、权限和版本验证。停止 OpenClash 服务后备份正式目标，再执行一次原子式替换。路径和文件名应以你当前版本的脚本与界面为准，不照抄其他固件的教程。

  1. 导出配置并备份当前可运行内核，记录版本与文件大小。
  2. 确认新文件来源、目标架构、内核类型和压缩格式。
  3. 在临时目录完成 gzip 检查、解压、执行权限及版本输出验证。
  4. 停止服务，保存正式目标，再把已验证文件放到正确位置。
  5. 启动后检查内核版本、配置加载、代理组、DNS 和一条实际连接。
  6. 若失败，停止服务并恢复旧内核，再用脱敏日志定位具体阶段。

更新成功的标准不只是界面显示新版本。还要确认进程保持运行、配置能解析、策略组可加载、路由器自身 DNS 不依赖失效链路、客户端请求能按预期通过。观察几分钟日志，确认没有崩溃重启循环。随后删除的只能是已经辨认为失败下载的临时副本；旧内核至少保留到一次重启和实际网络验证完成。

最有效的顺序：日志阶段 → 网络与版本源 → 架构与类型 → 压缩校验 → 空间权限 → 替换启动。顺序固定后，每个结果都能缩小范围，也能随时回到上一状态。

报告时附版本、CPU、核心类型与脱敏日志，并隐藏公网地址、订阅 URL、凭据和管理地址。

官方来源与版本边界

版本号、文件名和界面文字可能随项目更新而变化，操作前请以链接中的项目文档为准。