OpenClash のコアをダウンロードできない場合の対処方法

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 に記載されたルーター環境を、すべての端末で起こる不具合としては扱いません。

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 のバージョン更新ページへ戻ってコアを再確認します。現行スクリプトは一つの処理につき最大三回再試行し、各試行前に今回のダウンロードファイルと新しい一時コアを削除します。実行中に二つ目の処理を開始しないでください。

ダウンロード成功は更新完了を意味しません。ログには、ダウンロード成功、更新開始、Core Update Successful が順に表示される必要があります。Verification、Update、Move のいずれかで止まった場合は対応する段階を処理し、進捗が一度 100% になっただけでコアが置き換わったと判断しないでください。

スクリプトが再起動を予定するのは更新成功後です。二つ目の変化を持ち込まないよう、再起動前にサブスクリプション、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、最初の失敗ログ、空き容量、機密情報を除いた環境情報を提出します。