まず、失敗した段階がダウンロード・解析・適用のどこかを確認
Clashのモバイル版で表示される「更新失敗」は、原因が一つとは限りません。サブスクリプションの更新では通常、URLへのリクエスト、レスポンスのダウンロード、設定の解析と保存、設定の適用という段階を経ます。ノードに接続できても、サブスクリプションURLが有効とは限りません。また、ダウンロードに成功しても、新しい設定を現在のコアが読み込めるとは限りません。まず失敗した段階を特定し、リンクの変更、ネットワークの調整、設定の互換性確認のどれが必要か判断しましょう。
- 現在使える設定を残す。設定名、最終更新時刻、クライアント名を記録します。エクスポート機能があれば、先に端末内へバックアップを保存してください。バックアップにはノードのパスワードが含まれる場合があるため、安全な場所に保管しましょう。
- 手動で一度更新する。サブスクリプションまたは設定の一覧から対象を選び、「更新」を実行してエラーメッセージをすべて記録します。すべてのサブスクリプションを何度も連続更新するのは避けてください。
- 同じ時刻のログを確認する。失敗した時刻を分単位で記録し、HTTPステータスコード、接続タイムアウト、TLS証明書エラー、YAML解析エラーを見分けます。
- 変更する条件は一度に一つだけ。たとえば、Wi-Fiとモバイル回線を切り替えるか、更新リクエストのプロキシ設定だけを変更して、結果を比べます。
| メッセージ・症状 | まず確認する項目 | 次の手順 |
|---|---|---|
401 / 403 | トークン、アカウントの状態、アクセス制限 | サブスクリプションサービスの管理画面でURLと認証状態を確認 |
404 / 410 | APIのURLが移転または停止していないか | 管理画面に表示されるサブスクリプションURLをコピーし直す |
429 | 短時間にリクエストが集中 | 連続更新をやめ、サーバーが指定する待ち時間に従う |
5xx | サーバーまたは上流サービスの障害 | 古い設定を残し、時間をおいて再試行する |
timeout / lookup | 接続経路またはドメインの名前解決 | ネットワークを切り替え、リクエストがプロキシ経由か確認する |
yaml / unmarshal | レスポンスの内容と設定形式 | ダウンロードしたものがWebページや別クライアント用の形式ではないか確認する |
ステータスコードは手がかりであり、最終的な原因とは限りません。たとえば 403 はサイトのセキュリティ対策によって返される場合もあり、必ずしもサブスクリプションの期限切れを意味しません。管理画面、クライアントのログ、サービス提供元のお知らせをあわせて確認してください。
サブスクリプションURLが無効：トークン・有効期限・レスポンスを確認
サービスの管理画面からコピーし直し、チャット履歴からつなぎ合わせない
サブスクリプションURLには、アカウント固有のトークンが含まれていることがあります。URLの再発行、セキュリティ設定の変更、サービスの移転などにより、以前のURLが使えなくなる場合があります。コピー時はクエリパラメーターをすべて含め、末尾の空白や改行、日本語の句読点が混入していないか、チャットアプリ上でURLが途中までしか表示されていないか確認してください。URL内の & はパラメーターの区切りです。入力欄にHTMLエンティティとして誤って入力しないでください。
まずサービスの管理画面でプランの有効期限、残りの通信量、サブスクリプションの状態を確認し、現在表示されているURLで既存の項目を更新します。クライアントでURLを編集できない場合は、新しいサブスクリプション項目を作成してテストしてください。成功を確認してから古い項目を整理すれば、唯一使える設定を先に削除せずに済みます。
HTTP 200でもエラー内容が返ることがある
サーバーから 200 が返っても、リクエストにレスポンスがあったというだけです。内容はログインページ、認証ページ、プランの期限切れ通知、または短いエラーメッセージの可能性があります。解析エラーの箇所に <html> や <!DOCTYPE がある場合は、YAMLのインデントを調整する前にURLとアクセス制限を確認してください。
形式の互換性：フル設定とノードサブスクリプションを区別する
「サブスクリプション対応」と記載されていても、すべてのクライアントが同じ形式のレスポンスを読み込めるわけではありません。一般的な形式には、ClashのフルYAML設定、プロキシプロバイダーファイル、URIのリスト、Base64エンコードされたノード一覧があります。フル設定には通常 proxies、proxy-groups、rules などのフィールドが含まれます。一方、ノードプロバイダーファイルはノードのみを提供し、プロキシグループやルールを含まないことがあります。
- 設定ファイル全体をインポートする場合：サービスの管理画面で、Clashまたは現在のコアに対応すると明記された形式を選びます。他のクライアント専用のサブスクリプションURLを、そのままフル設定として読み込まないでください。
- ノードプロバイダーを読み込む場合：
proxy-providersがダウンロードするのはプロバイダー用の内容で、フル設定とは構造が異なります。読み込み先を間違えると、フィールド不足や解析エラーが発生することがあります。 - Meta / mihomoの機能：一部のプロトコル、ルール用フィールド、DNSオプションには、対応するコアが必要です。オリジナル版Clash、Clash Meta / mihomo、各種GUIクライアントで、対応範囲は完全には一致しません。
クライアントの「バージョン情報」またはコア情報の画面で、実際に使われているコアを確認し、設定の提供元の説明と照らし合わせてください。アプリ名にClashと付いていても、新しいフィールドに対応しているとは限りません。ログに未対応のプロトコルやフィールドが明記されている場合は、提供元が用意する互換形式に切り替えるか、その機能に対応したクライアントを使いましょう。設定を行ごとに削除して試すのは避けてください。
エラー行番号は位置の目安であり、根本原因とは限らない
YAMLではインデントが重要です。空白の代わりにTabを使わないでください。エラーの原因はログに示された行だけでなく、その前の行で閉じられていない引用符や括弧にあることもあります。リモートサブスクリプションの場合は、まず提供元に元の内容を確認してください。スマートフォンでダウンロード済みファイルを直接編集しても、次回の更新で上書きされることがあります。ローカル設定を追加する場合は、クライアントが対応するオーバーライドまたはマージ機能を使ってください。関連する概念は技術リファレンスをご覧ください。
更新リクエストがプロキシを経由しない：ノードの接続とサブスクリプションへのアクセスは別
モバイルクライアントは、アプリ自体がリモート設定全体をダウンロードする場合と、コアがリモートプロバイダーをダウンロードする場合があります。この2種類のリクエストは、同じネットワーク経路を使うとは限りません。ブラウザーでサービスの管理画面を開けても、それはブラウザーの経路でアクセスできることを示すだけです。クライアントのサブスクリプションリクエストも同じ経路を使っているとは限りません。
2種類のネットワーク経路を比較する
- 古い設定を残し、選択中のノードで実際にインターネットへアクセスできるか確認します。VPNアイコンが点灯しているかどうかだけで判断しないでください。
- サブスクリプションの編集画面や更新設定で、「プロキシ経由で更新」「更新プロキシ」などの項目を探します。項目名はクライアントによって異なるため、特定のクライアントのメニュー手順をすべてのモバイル版に当てはめないでください。
- その項目がある場合は、直結とプロキシ経由で手動更新を一度ずつ行い、結果を記録します。プロキシ経由でのみ成功する場合は、そのサブスクリプションの更新方式をプロキシ経由に設定してください。
- どちらも失敗する場合は、Wi-Fiとモバイル回線を切り替えて再テストします。DNS、ノード、サブスクリプション形式を同時に変更すると、どの変更が有効だったのか判断しにくくなります。
グローバルモードに切り替えても、サブスクリプションのダウンロード経路が変わるとは限りません。ダウンロード処理がコアを経由せず、アプリから直接実行される場合があるためです。一方、対応するフィールドを備えたmihomoでは、設定内の proxy-providers にダウンロード用の proxy を指定できます。この設定が適用されるのは該当プロバイダーのみで、クライアントが設定ファイル全体を更新する方式は自動的に変わりません。
スマートフォンのVPN権限、TUNによる通信の捕捉、アプリの除外リストもリクエスト経路に影響することがあります。特にクライアント自身を除外している場合や、アプリごとのプロキシ設定を有効にしている場合は、他のアプリがネットにつながるからといってネットワークの問題を除外しないでください。ログが no such host の場合は、まずドメインの名前解決を確認します。接続タイムアウトの場合は、接続経路、プロキシの出口、サーバーへの到達性を確認してください。
証明書の検証に失敗する：まず時刻を合わせ、次にネットワーク環境を確認
x509: certificate has expired or is not yet valid、ホスト名の不一致、信頼されていない証明書チェーンは、いずれもTLS検証エラーです。YAMLの解析エラーとは発生段階が異なり、ノードのパスワードを変更しても解決しません。
- システムの日付と時刻を自動設定にする。Androidでは通常、システム設定の「日付と時刻」で自動設定を有効にします。iOSでは「設定」→「一般」→「日付と時刻」で「自動設定」を確認してください。時刻がずれていると、有効な証明書が期限切れまたは有効期間前と判定されることがあります。
- 公衆Wi-Fiのログインを確認する。ホテルや学校のネットワークでは、先にWeb認証が必要な場合があります。ネットワークの正規のログインを済ませてから、サブスクリプションを再度取得してください。
- ネットワークを切り替えて再テストする。特定のWi-Fiだけで失敗する場合は、そのネットワークでHTTPS通信の検査やドメインのリダイレクトが行われていないか確認してください。出所不明のルート証明書を安易にインストールしないでください。
- サービス提供元にドメイン証明書を確認してもらう。複数のネットワークで同じ期限切れやホスト名エラーが発生する場合は、証明書の設定をサービス提供元に修正してもらうか、正しく設定されたサブスクリプションURLを案内してもらってください。
設定の skip-cert-verify は通常、ノード接続時の証明書検証に関する項目です。サブスクリプションのダウンロードに使うTLS設定とは異なります。エラーメッセージを消すためにノードの設定を一括変更しないでください。また、サブスクリプションのレスポンス自体に認証情報が含まれる可能性があるため、HTTPの平文URLを長期的な代替手段にしないでください。
自動更新間隔：まず2種類のタイマーを区別する
クライアントの「サブスクリプション自動更新」は、通常リモート設定全体を更新します。一方、コアの proxy-providers にある interval は、特定のノードプロバイダーの更新間隔を指定します。両方を併用できますが、互いの代わりにはなりません。混同しやすい項目に health-check.interval があります。これはヘルスチェックの頻度を設定するもので、ノード一覧の再ダウンロードには使われません。
| 更新対象 | 設定場所 | 設定の目安 |
|---|---|---|
| リモート設定全体 | クライアントのサブスクリプション編集・更新設定 | 24時間を目安に、サービス提供元の指定に合わせて調整 |
| HTTPノードプロバイダー | proxy-providers 内の該当項目 | interval: 86400 |
| HTTPルールプロバイダー | rule-providers 内の該当項目 | ルールソースの更新頻度に合わせて設定 |
| ノードのヘルスチェック | health-check 関連の設定 | 個別に設定し、サブスクリプションの更新間隔とは分ける |
設定全体は1日1回から
ノードの変更が少ないサブスクリプションなら、24時間を設定の目安にできます。更新頻度を高める必要がある場合は6～12時間も検討できますが、サービス提供元のレート制限に従ってください。これは設定例であり、すべてのサービスに共通する基準ではありません。サーバーから 429 が返り、Retry-After が指定されている場合は、その待ち時間を優先し、数秒おきに更新ボタンを押すのは避けてください。
設定前に入力単位を確認してください。24時間は 1440分、86400秒です。クライアントの画面では分または時間を使う場合がありますが、コアのプロバイダーにある interval の単位は秒です。同じ数値を異なる場所にそのまま入力しないでください。値が 0 の場合の動作もクライアントの説明で確認し、「すぐに更新」を意味すると決めつけないようにしましょう。
プロバイダー：既存項目の更新間隔だけを変更する
mihomoのHTTPノードプロバイダーを使い、1日1回更新したい場合は、既存のプロバイダー項目に次の行を設定します。これはフィールドの例であり、単独で読み込める完全な設定ではありません。既存の名前、URL、パスなど、必要な設定は残してください。
# 既存の proxy-providers 項目の下位に記述、単位は秒
interval: 86400変更後は、まず設定を読み込めることを確認し、ログでプロバイダーの最終更新時刻を確認してください。この行を設定の最上位に置いて、クライアント全体のリモートサブスクリプションを制御しようとしないでください。ローカルファイル型のプロバイダーを使っている場合も、HTTPの定期ダウンロードの動作をそのまま当てはめることはできません。
スマートフォンの画面ロック中に更新されない：スケジュール制限と成功時刻を確認
自動更新間隔は通常、クライアントまたはコアが更新を試みる周期を示すもので、スマートフォンが正確な時刻に処理を実行する保証ではありません。Androidの省電力機能やメーカー独自のバックグラウンド制限、ネットワークの切断、iOSのバックグラウンド処理とネットワーク拡張の制約により、更新が遅れることがあります。VPNアイコンが表示されていても、設定のダウンロードを行うアプリの画面プロセスが動作しているとは限りません。
- Android：システムのアプリ別バッテリー設定で、クライアントのバックグラウンド動作が制限されていないか確認してください。「バックグラウンドでの実行を許可」「自動起動」などの項目の場所はメーカーごとに異なります。実際の端末のメニューに従い、制限を緩和した場合のバッテリー消費にも注意してください。
- iOS：使用中のクライアントが提供するバックグラウンド機能に従ってください。一般的なアプリの定期タスクは、常時動作するサービスとは異なります。必要に応じてクライアントを開き、手動で更新結果を確認してください。
- Android・iOS共通：モバイル回線での更新が許可されているか、現在のネットワークに従量制などの制限がないか、画面の表示が「最終試行時刻」か「最終成功時刻」かを確認してください。
設定後は、まずアプリを前面に表示して手動更新し、新しい設定が保存され、読み込めることを確認します。設定した周期を過ぎたら、更新スイッチがオンかどうかだけでなく、成功時刻を確認してください。スマートフォンの再起動後も、設定が選択された状態か、VPNの権限が有効か、自動更新の設定がシステムによってリセットまたは削除されていないか確認しましょう。
問い合わせ前に記録しておきたい最小限の情報
失敗が続く場合は、アプリを何度も削除して再インストールするより、再現できる形で問題を記録するほうが効果的です。アプリのデータを消去すると、サブスクリプション、オーバーライド、プロキシグループの選択も削除される場合があります。バックアップを済ませ、ほかの方法で解決できなかった後に検討してください。
- クライアント名、アプリのバージョン、実際に使用中のコア、スマートフォンのOSバージョンを記録する。
- 失敗した時刻、Wi-Fiとモバイル回線のどちらを使ったか、リクエストが直結かプロキシ経由かを記録する。
- HTTPステータスコード、TLSエラー、設定解析時の行番号など、機密情報を伏せた完全なエラー行を保存する。
- 手動更新の成否、失敗した対象が設定全体かプロバイダーか、古い設定が引き続き使えるかを説明する。
- URLの認証やレスポンスの問題はサブスクリプションサービスの提供元へ、再現可能なダウンロード・解析・スケジュール実行の異常はクライアントの開発元へ報告する。
最終的に確認するのは、サブスクリプションのダウンロード、新しい設定の読み込み、実際の接続の3点です。更新時刻が変わっても設定を適用できなければ、問題が解決したとはいえません。モバイル版の初期設定と権限の確認については、インストール・使い方ガイドもご覧ください。