目次
コアの更新に失敗しても、ルーターは古いファイルで通信を転送している場合があります。コアのディレクトリを削除すると、この復旧手段を失います。ファイル取得前、自己チェック中、ディレクトリへの書き込み中のどこで失敗したかを確認し、使えるサービスを残したうえで、再ダウンロードするか、アーキテクチャ・空き容量・システム時刻を調べるか判断します。
コア更新の失敗：バージョン確認、取得、検証、書き込みのどこで止まった？
最後の表示だけでOpenClashを再インストールせず、「コアが存在しない」「コア更新失敗」からログをさかのぼって最初のエラーを探してください。コアは接続を処理するプログラムです。公式スクリプトはリモートのバージョンを取得し、CPUアーキテクチャに合わせてダウンロード、展開した後、権限と-vの自己検査を通過してから正式なファイルを置き換えます。
最初のエラーに対応する確認項目
| ログまたは症状 | 失敗した段階 | 優先して確認すること |
|---|---|---|
| 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 | アーキテクチャが未選択 | バージョン更新ページのビルド版選択 |
- 対象となるスクリプトとバージョン
- 2026年9月13日時点で、OpenClash の最新安定版は v0.47.156 です。この記事では、現在の master 更新スクリプトと同安定版で利用できる安全な切り分け手順を扱います。単一の issue に記載されたルーター環境を、すべての端末で起こる不具合としては扱いません。
- リモート版を取得失敗時は 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 を復旧するか時刻を手動で合わせてから、公式アドレスを再試行 |
GitHub のバージョン照会や TLS リクエストに失敗したら、時刻・curl・ca-bundle を確認する
公式の 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 のアドレスを組み立てます。画面に用意された信頼できる選択肢だけを使い、フォーラムに掲載された不明なミラーを貼り付けないでください。
ログの Core Update Successful で更新完了を確認する
アーキテクチャ、容量、時刻、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、ルール、ノードを調べてください。
/etc/openclash/core/clash_meta -v新しいコアが起動できない、または設定を読み込めない場合は、設定を残して旧コアを復元する
新しいコアを実行できない、起動直後に終了する、または動作していた設定が失敗する場合は、まず OpenClash を停止します。修復前に保存した同じ端末・同じアーキテクチャの旧コアを戻し、プラグインにバージョンを読み取らせてから起動してください。互換性のない新ファイルを正式パスに残して再起動を繰り返したり、プラグイン、コア、設定を同時にダウングレードしたりしないでください。
自動更新は、新しいファイルが自己検査に合格するまで独立した一時パスを使います。そのため、ダウンロード、検証、展開に失敗した場合は、更新を止めて旧コアを使い続けるのが通常もっとも安全です。旧コアを手動で上書きし、バックアップもない場合は、公式 core ブランチから既知の動作する同一アーキテクチャ版を取得してください。チャットグループやオンラインストレージで同名の clash_meta を探さないでください。
切り戻し後に、バージョン出力、起動ログ、DNS、HTTPS の四項目をもう一度確認します。旧コアが正常に戻り、新版の問題を安定して再現できる場合に限り、OpenClash の issue へプラグイン版、core_version、最初の失敗ログ、空き容量、機密情報を除いた環境情報を提出します。
旧コアへ戻すと正常
旧版を維持し、公式修正を待つか新ファイルのアーキテクチャを再確認します。更新を連打しないでください。
旧コアも実行できない
保存先、権限、ファイルシステム、バックアップが同じアーキテクチャのものか確認します。
コアは起動するが設定テストに失敗
YAML とコアのフィールド互換性を調べ、ダウンロード障害としては扱いません。
サービスは起動するが端末が通信できない
プロキシを有効にする前のネットワーク状態に戻してから、DNS、ファイアウォール、ルール、ノードをそれぞれ確認してください。