本文目錄
先從日誌判斷失敗發生在哪個步驟
OpenClash 顯示「核心不存在」或「核心更新失敗」時，不要先重新安裝外掛。目前官方指令碼會依序讀取遠端版本、依照已選 CPU 架構下載壓縮檔、檢查 gzip、解壓縮到暫存檔、授予執行權限並執行 -v；全部通過後才會替換正式核心。第一條明確錯誤決定下一步該檢查什麼。
Core Version Check Error 表示遠端版本資訊未讀取到；Core Download Failed 表示壓縮檔請求失敗；Core Verification Failed 表示下載內容未通過 gzip 檢查。
Core Update Failed 表示解壓縮、權限或 -v 自我檢查失敗；Core Move Failed 才是把已驗證暫存檔案放到目標路徑時失敗。它們不是同一個問題。
截至 2026 年 9 月 13 日，OpenClash 最新穩定版仍是 v0.47.156。本文說明目前 master 更新指令碼與這個穩定版可用的安全疑難排解流程，不會把單一 issue 中的路由器環境寫成所有裝置都會遇到的故障。
第一條錯誤對應的檢查方向
| 日誌或現象 | 失敗階段 | 優先檢查 |
|---|---|---|
| Core Version Check Error | 版本中繼資料 | 系統時間、CA 憑證、curl 與 GitHub 存取 |
| Core Download Failed | 壓縮檔下載 | 網路、下載逾時與 GitHub 位址代理設定 |
| Core Verification Failed | 壓縮檔驗證 | 是否下載成 HTML 錯誤頁面、截斷檔案或錯誤的映像來源 |
| Core Update Failed | 解壓縮與執行自我檢查 | CPU 架構、壓縮格式、可執行權限與二進位檔是否完整 |
| Core Move Failed | 寫入正式路徑 | 可用空間、唯讀檔案系統與目標目錄 |
| No Compiled Version Selected | 架構未選擇 | 版本更新頁的編譯版本選項 |
- 讀取遠端版本失敗時記錄 Core Version Check Error
- 下載架構套件依照 core_version 請求官方壓縮檔
- 驗證並解壓縮gzip、解包、權限與 -v 依序通過
- 移至目標路徑只有已驗證的暫存檔才能替換舊核心
- 重啟並驗證核對版本、啟動日誌與實際 HTTPS 請求
第一條失敗日誌對應哪一個檢查點，就只修復那一段；不要把下載、架構、空間與設定問題混在一起。
修復前先保留仍可執行的舊核心
如果 OpenClash 目前還能啟動並轉送流量，先不要刪除 /etc/openclash/core，也不要連續點擊更新。官方指令碼把新檔案寫入帶 .new 與處理程序編號的暫存路徑，完成 gzip、解壓縮、chmod 4755 與 -v 自我檢查後才覆蓋正式檔案；自動更新失敗時，舊核心通常仍是最可靠的復原點。
先在 OpenClash 狀態頁記錄目前執行中的核心與版本，再依照站內升級指南備份 UCI 設定、設定檔與覆寫。核心檔案只應作為同一裝置、同一架構的短期復原副本，不能取代設定備份，也不要公開上傳含有訂閱或金鑰的整個目錄。
建立可復原的基準
停止重複更新
等待目前工作結束，只保留一次完整日誌，避免多個下載與重啟同時進行。
記錄目前狀態
記錄 OpenClash 版本、執行核心、核心版本、已選編譯架構與小快閃記憶體模式狀態。
備份設定
匯出目前可用的設定檔與 OpenClash 設定；公開副本必須先移除敏感資訊。
驗證舊核心
固定目前節點完成一次實際 HTTPS 請求，確認故障只發生在更新，不是現有轉送已經中斷。
核對 CPU 架構、目標路徑、空間與時間
目前下載指令碼直接讀取 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 的可用空間。
uci -q get openclash.config.core_version
uci -q get openclash.config.small_flash_memory
df -h /etc/openclash /tmp
date如何判讀檢查結果
| 結果 | 含義 | 處理 |
|---|---|---|
| core_version 為空或為 0 | 沒有可下載的編譯版本 | 回到版本更新頁選擇與裝置相符的架構 |
| 日誌提示處理器不支援 | 二進位檔架構或微架構不相符 | 恢復舊核心並重新選擇較相容的官方建置 |
| /etc 可用空間不足 | 正式檔案可能無法移動 | 只刪除自己確認無用的套件快取或日誌，不刪除設定與舊核心 |
| 小快閃記憶體模式開啟且 /tmp 不足 | RAM 目標無法容納新核心 | 釋放暫存空間或重啟後再試，不改自動目標路徑 |
| 系統日期明顯錯誤 | TLS 憑證驗證可能失敗 | 先恢復 NTP 或手動校準時間，再重試官方位址 |
版本檢查或 TLS 失敗時，先修正系統條件
官方 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 的位址。只選擇介面提供、自己信任的選項，不貼上論壇中的未知映像站。
恢復版本檢查與下載連線
校準系統時間
先讓 NTP 成功同步，重新整理頁面後確認日期、時區與年份正確。
核對官方相依套件
在 OpenWrt 軟體套件頁面確認 curl 與 ca-bundle 已安裝；不要混用來源不明的憑證套件。
單獨重試一次
儲存設定後，只點擊一次版本或核心檢查，並用新日誌確認錯誤是否仍停在同一階段。
必要時更換官方代理選項
只在 OpenClash 內建 GitHub 位址代理設定中更換一次，再比較錯誤與下載進度。
使用官方更新流程完成一次乾淨重試
架構、空間、時間與 CA 憑證都正常後，回到 OpenClash 的版本更新頁重新檢查核心。目前指令碼每次工作最多重試三次，並在每次嘗試前清理本次下載檔案與暫存新核心；不要在它仍執行時再開第二個工作。
下載成功不代表更新完成。日誌還應依序出現下載成功、開始更新與 Core Update Successful。若停在 Verification、Update 或 Move，請繼續依照對應階段處理，不要因為進度曾達 100% 就判斷核心已經替換。
更新成功後指令碼才會安排重啟。重啟前不要改訂閱、DNS 或防火牆，以免同時引入第二個變因。若外掛仍使用舊版本，先完整重新整理狀態頁並核對實際 -v 輸出，不要重複覆蓋。
官方重試成功的最小證據
- 本次日誌只有一個核心更新工作，沒有並行重試
- 下載內容通過 gzip 驗證並完成解壓縮
- 暫存核心已通過 chmod 4755 與 -v 自我檢查
- 日誌出現 Core Update Successful，而不只是下載 100%
- 重新啟動後，狀態頁顯示的核心版本已經變更
自動下載仍失敗時，安全地手動上傳
手動上傳只解決路由器無法穩定下載官方檔案，不會修復架構選錯、空間不足或 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 與空間。
手動上傳的安全順序
確認精確架構
抄下版本更新頁面的 core_version，不要用 CPU 品牌或商品型號代替。
備份可用核心
在上傳前另存目前能執行的 clash_meta，確認副本來自同一裝置與架構。
只取得官方檔案
從 OpenClash 官方 core 分支取得符合指定架構、分支與 Meta 類型的單一 .tar.gz 檔案，不使用第三方重新打包的版本。
透過設定管理上傳
選擇 [Meta] Core File (.tar.gz)，讓目前外掛負責解包、重新命名與權限設定。
先自我檢查再啟動
確認狀態頁能讀取核心版本，再啟動 OpenClash；讀不到版本時立即停下，不改防火牆。
更新後驗證版本、啟動與實際流量
上傳成功提示只表示檔案處理完成。先在狀態頁確認 Meta 核心檔案存在、執行權限正常且能顯示版本，再啟動 OpenClash。若頁面仍快取舊結果，重新整理後再讀取，不要再次上傳來「碰碰運氣」。
接著檢查啟動日誌中的設定測試、核心啟動，以及 DNS、防火牆步驟。最後固定一個已知可用節點，分別完成一次網域名稱解析與一次實際 HTTPS 請求；如果核心能啟動但實際使用仍失敗，應改查設定、DNS、規則或節點，而不是繼續更換二進位檔。
/etc/openclash/core/clash_meta -v完成修復前逐項確認
- 狀態頁的已選架構與下載檔案完全一致
- 核心檔案存在、權限正常並能輸出版本
- 啟動日誌不再出現 Version、Download、Verification、Update 或 Move Failed
- 設定測試通過，OpenClash 服務持續執行
- 網域名稱解析成功，實際 HTTPS 請求可完成
- 舊核心與設定備份仍保留在不公開的位置
仍失敗就恢復舊核心，不刪除設定
如果新核心無法執行、啟動後立即退出或使原本可用的設定失敗，先停止 OpenClash，恢復修復前儲存的同一裝置、同架構舊核心，再讓外掛讀取版本並啟動。不要把不相容的新檔案留在正式路徑上反覆重啟，也不要同時降級外掛、核心與設定。
自動更新會在新檔案通過自我檢查前使用獨立暫存路徑，因此下載、驗證或解壓縮失敗時，最安全的做法通常是停止更新並繼續使用舊核心。若舊核心已被手動覆蓋且沒有備份，請從官方 core 分支重新取得已知可用的同一架構版本；不要從群組聊天或網路硬碟尋找同名的 clash_meta。
復原後再次進行版本輸出、啟動日誌、DNS 與 HTTPS 四項驗證。只有舊核心恢復正常且新版問題能穩定重現，才向 OpenClash issue 提交外掛版本、core_version、第一條失敗日誌、剩餘空間與已移除敏感資訊的環境資料。
舊核心恢復後正常
保留舊版本，等待官方修復或重新核對新檔案架構，不再連續更新。
舊核心也無法執行
檢查目標路徑、權限、檔案系統與備份是否來自同一架構。
核心啟動但設定測試失敗
改查 YAML 與核心欄位相容性，不再依照下載故障處理。
服務啟動但裝置無法上網
恢復系統接管前的網路，再分別檢查 DNS、防火牆、規則與節點。