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、第一條失敗日誌、剩餘空間與已移除敏感資訊的環境資料。