先找出失敗階段，不要直接重裝外掛

OpenClash 顯示「核心更新失敗」時，真正的錯誤可能發生在多個環節。官方儲存庫的 openclash_core.sh 會先取得版本資訊，再依 CPU 型號與核心類型組成下載位址，把壓縮檔寫到暫存位置，執行 gzip 完整性檢查，解壓縮並設定執行權限，執行新版的版本參數後，最後才移到正式核心路徑。每一步都可能被介面濃縮成相同提示。

先保存完整日誌，記下失敗時間、OpenClash 與目前核心版本、路由器型號、實際 CPU 架構和選擇的核心類型。不要只截取最後一行。無法取得版本、curl 下載錯誤、gzip 驗證失敗、新檔無法執行、移動失敗或啟動立即退出，分別需要不同處理。

階段日誌訊號優先檢查
版本資訊版本檔空白或無法取得時間、DNS、HTTPS、來源可達性
下載curl 解析、連線或 HTTP 錯誤路由器本身的解析與上游網路
壓縮驗證gzip test failed檔案是否完整或其實是錯誤頁
執行驗證版本沒有輸出、格式錯誤CPU 架構、檔案類型、權限
替換啟動move failed 或立即退出空間、唯讀掛載、占用和設定相容

一次只改一個條件：同時升級 OpenWrt、換 DNS、重裝外掛與手動上傳核心，會讓成功或失敗都無法歸因。

確認版本來源、DNS 與 HTTPS 下載鏈路

若錯誤停在版本檢查或下載，測試應從路由器本身進行。先確認日期、時區與 NTP 正常，嚴重錯誤的系統時間會影響 HTTPS 憑證驗證。再確認 WAN 有 DNS 與預設路由。解析失敗表示名稱沒有轉成位址；連線逾時則可能已解析，但到目的地的連線未完成，兩者不要混為一談。

Issue #5098 曾記錄 curl: (6) Could not resolve host: fastly.jsdelivr.net，其後才出現 Smart 核心版本檢查失敗。這是一個具體的 DNS 解析案例，不是所有更新失敗的通用原因。自己的日誌若顯示 404、TLS、空間或 gzip 問題，就應遵循那個證據。

  1. 核對路由器時間、時區和 NTP 同步。
  2. 分別確認更新網域可解析、TCP 443 可連線。
  3. 避免路由器 DNS 必須經過尚未啟動的 OpenClash，排除循環依賴。
  4. 檢查下載檔大小與類型，確定不是 HTML 錯誤頁。
  5. 修復網路後只重試一次，查看日誌是否進到下一階段。

上游路由、防火牆或自訂 DNS 可能攔截更新網域。測試時建立明確且可撤回的路由器直連，不要關閉所有安全功能。完成後恢復原策略並比較前後日誌。

v0.47.156 Release 只能作為某個外掛版本的發布快照。它不代表每一台設備都必須升級，也不能替代 CPU 架構和核心資產的核對。

比對 CPU 架構、核心類型與實際下載資產

下載成功但新版無法執行時，先查架構。更新腳本會使用設定中的 core_version 選擇 CPU 型號，並依核心類型處理不同目標。商品名稱不是架構，同系列路由器也可能採用不同指令集。應交叉比對 OpenWrt 實際回報、套件管理器架構與目前可執行舊核心的檔案資訊。

壓縮檔和執行檔也不能混用。下載檔可能先以 gzip 形式寫入暫存區，通過檢查並解壓後才是核心。把壓縮檔改名成 clash_meta 或只設定執行權限，都無法修復格式與架構不符。若看到 Exec format error、illegal instruction 或版本命令空白，應回頭核對資產。

不要依二次改名猜架構：手動檔案只從專案指向的一手來源取得，保留原檔名與發布資訊。第三方轉存會移除最重要的判斷線索。

在暫存目錄驗證新核心：確認檔案類型吻合本機架構、gzip 測試通過、解壓後不是空檔、具執行權限、版本參數能正常輸出。五項都成立後才考慮替換正式路徑。若介面有 Meta、Smart 或其他選項，也要先確認目前外掛支援，且設定確實需要該類型。

外掛版本和核心版本彼此相關，但不是同一項更新。為了排除單一核心錯誤而同時升級固件、外掛與依賴，會擴大風險；更好的做法是保留可運作的現況，先證明新核心檔案本身可執行。

檢查暫存空間、小閃存模式、權限與占用

下載完成仍可能無法落盤。腳本需要先保存壓縮檔，再解壓並移到正式位置，因此暫存區與目標區都要有空間。官方腳本還處理 small_flash_memory：一般模式使用持久設定目錄，小閃存模式可能把核心放到 /tmp。這個位置受記憶體檔案系統容量限制，重開機也會清空，不能照一般閃存路徑推斷。

檢查儲存容量與 inode，並確認檔案系統沒有因錯誤變成唯讀。目錄不存在、權限不足、舊程序仍占用檔案，也可能在最後一步失敗。不要為了清空間先刪除唯一可執行的舊核心。先確認備份，再只處理可辨識的失敗下載與暫存檔。

  • 容量：暫存區同時要容納壓縮檔與解壓檔。
  • 權限：目錄可寫，新核心可執行，所有者與舊檔一致。
  • 程序：依正常服務流程停止，不強制覆蓋使用中的檔案。
  • 持久性：小閃存模式重啟後需由啟動流程重新準備核心。
  • 完整性：合理大小之外，還要有 gzip 與版本執行結果。

若移動失敗，先查暫存檔與正式檔各自狀態，不要立刻重開機。正式位置仍是舊核心時可維持服務並繼續診斷；若已換成無法執行的檔案，停止服務後恢復備份。每次動作都要能明確回復。

手動復原採最小變更，更新後驗證完整鏈路

只有在自動流程反覆失敗，而且來源、下載和架構都已確認時，才考慮手動處理。先複製目前可運作核心，不覆蓋唯一副本；從 OpenClash 一手來源取得相符資產，在暫存目錄完成解壓、權限和版本測試。停止服務後保存正式目標，再放入已驗證的新檔。實際路徑以目前版本腳本和介面為準，不照抄其他固件。

  1. 匯出設定，備份舊核心，記錄版本和檔案大小。
  2. 核對來源、CPU 架構、核心類型與壓縮格式。
  3. 在暫存區驗證 gzip、解壓結果、權限與版本輸出。
  4. 停止服務，保留正式舊檔，再進行一次替換。
  5. 啟動後檢查版本、設定載入、策略群組、DNS 和一筆實際連線。
  6. 失敗時停止服務並復原舊核心，再分析脫敏日誌。

介面顯示新版本並不是完整成功。程序應持續執行，設定能解析，群組能載入，路由器 DNS 不依賴失效鏈路，客戶端流量也按預期處理。觀察日誌以排除崩潰循環，至少通過一次重啟與實際網路測試後再清除舊核心。

固定排查順序：日誌階段、網路與版本源、架構與類型、壓縮驗證、空間權限、替換啟動。每一步都有結果，範圍才會逐漸縮小。

回報問題時附上 OpenClash、OpenWrt、CPU 架構、核心類型、失敗時間和完整更新日誌，並移除公網位址、訂閱 URL、節點憑證和管理入口。這比一句「重裝過仍失敗」更能協助維護者重現。

官方來源與版本邊界

版本號、檔案名稱與介面文字可能隨專案更新而變動，操作前請以連結中的專案文件為準。