OpenClash 内核下载失败怎么修？

不要仅凭末尾提示重装 OpenClash，先从“内核不存在”或“内核更新失败”向前查第一条错误。内核是处理连接的程序；官方脚本先读远端版本，按 CPU 架构下载、解压，通过权限与 -v 自检才替换正式文件。

如果 OpenClash 目前还能启动并转发流量，先不要删除 /etc/openclash/core，也不要连续点击更新。官方脚本把新文件写入带 .new 和进程号的临时路径，完成 gzip、解压、chmod 4755 与 -v 自检后才覆盖正式文件；自动更新失败时，旧内核通常仍是最可靠的回退点。

先在 OpenClash 状态页记录当前运行内核和版本，再按站内升级指南备份 UCI 设置、配置文件与覆写。内核文件只应作为同设备、同架构的短期回退副本，不能代替配置备份，也不要把包含订阅或密钥的整个目录公开上传。

当前下载脚本直接读取 UCI 的 core_version，并把它拼入 clash-${core_version}.tar.gz。这里需要的是 OpenClash 版本更新页提供的编译架构，不是凭路由器商品名猜一个相近值。选错后即使下载完整，也可能在执行 -v 时失败。

Issue #4758 的日志同时出现下载超时和“只能在支持 v3 微架构的 AMD64 处理器上运行”。它只能证明那台设备至少存在网络与架构两条问题，不能证明所有手动上传失败都由 amd64-v3 引起。

当前官方编译流程中的 amd64 与 amd64-v3 都要求 GOAMD64 v3；x86_64 不等于 CPU 支持 v3。遇到 v3 unsupported 时应在更新页选择 amd64-compatible 或 amd64-v1，不能把 plain amd64 当兼容版。

普通模式的正式目标是 /etc/openclash/core/clash_meta；小闪存模式的自动更新目标改为 /tmp/etc/openclash/core/clash_meta。不要绕过界面把文件硬复制到猜测的目录。先核对设置，再检查对应挂载点与 /tmp 的可用空间。

官方 v0.47.156 安装说明把 curl 与 ca-bundle 列为依赖。Issue #5114 的一台设备在下载 openclash_last_version 和 clash_last_version 时分别记录 curl 35 TLS connect error 与 curl 60 certificate has expired。

该 issue 是没有维护者根因结论的单机报告，只能说明版本文件也可能遇到 TLS 类错误；它不能证明内核压缩包缺失，也不能证明重装 ca-bundle 必然有效。

校准路由器日期、时区和年份，在软件包页面确认 curl 与 ca-bundle 已安装且没有损坏。不要给 curl 增加 -k、关闭 TLS 校验或把版本地址改成 HTTP，否则无法可靠核对下载来源。保存设置后只重试一次，用新日志查看是否仍停在同一错误。

若直连 GitHub 不稳定，可使用 OpenClash“覆写设置 > 常规设置”里的 GitHub 地址代理选项。当前脚本会根据该设置构造官方 OpenClash core 分支或受支持 CDN 的地址。只选择界面提供、自己信任的选项，不粘贴论坛中的未知镜像。

架构、空间、时间与 CA 证书都正常后，回到 OpenClash 的版本更新页重新检查内核。当前脚本每次任务最多重试三次，并在每次尝试前清理本次下载文件与临时新内核；不要在它仍运行时再开第二个任务。

下载后仍需通过 gzip 校验、解压、chmod 4755 和 -v 自检。日志应出现 Core Update Successful；进度到过 100% 不能证明内核已替换。停在 Verification、Update 或 Move 时，按对应错误继续检查。

更新成功后脚本才会安排重启。重启前不要改订阅、DNS 或防火墙，以免同时引入第二个变量。若插件仍使用旧版本，先完整刷新状态页并核对实际 -v 输出，不要重复覆盖。

手动上传只解决路由器无法稳定下载官方文件，不会修复架构选错、空间不足或 TLS 来源不可信。先在另一台可信设备从 vernesong/OpenClash 的 core 分支取得与当前 release branch、Meta 类型和 core_version 完全一致的官方文件。

文件名应与自动脚本构造的 clash-${core_version}.tar.gz 对应。上传控件明确标注 [Meta] Core File (.tar.gz)；不要改名上传 ZIP、自制多文件包或把这一步套用到 Smart、Oix。

进入 OpenClash 的配置管理上传区，选择 [Meta] Core File (.tar.gz)。当前 config.lua 会在临时子目录解包，把第一个普通文件移动为 /etc/openclash/core/clash_meta，设置 4755 权限并清理上传临时目录。

手动入口不会执行 -v，也没有哈希或签名核验，并会直接替换旧文件。上传前另存可运行的旧内核；File saved 仅表示文件处理完成。状态页能读取版本后再启动，读不到时停下检查，不改防火墙。

小闪存模式、定制固件或后续版本可能通过链接或运行目录处理内核，所以最终必须以当前界面的保存提示、状态页和 -v 输出为准。若上传后仍显示内核不存在，不要反复上传不同架构；回到前一节重新核对 core_version 和空间。

上传成功提示只说明文件处理完成。先在状态页确认 Meta 内核文件存在、运行权限正常且能显示版本，再启动 OpenClash。若页面仍缓存旧结果，刷新后重新读取，不用再次上传来“碰碰运气”。

随后检查启动日志中的配置测试、内核启动和 DNS、防火墙步骤。最后固定一条已知可用节点，分别完成一个域名解析和一个真实 HTTPS 请求；如果内核能启动但业务失败，应转查配置、DNS、规则或节点，而不是继续更换二进制。

如果新内核无法执行、启动后立即退出或使原本可用的配置失败，先停止 OpenClash，恢复修复前保存的同设备、同架构旧内核，再让插件读取版本并启动。不要把不兼容的新文件留在正式路径上反复重启，也不要同时降级插件、内核和配置。

自动更新在新文件通过自检前使用独立临时路径，因此下载、校验或解压失败时，最安全的动作通常是停止更新并继续使用旧内核。若旧内核已经被手动覆盖且没有备份，从官方 core 分支重新取得已知可用的同架构版本；不要从群聊或网盘找一个同名 clash_meta。

回退后再次做版本输出、启动日志、DNS 与 HTTPS 四项验证。只有旧内核恢复正常且新版本问题能稳定复现，才向 OpenClash issue 提交插件版本、core_version、第一条失败日志、剩余空间和脱敏环境信息。