まず、ダウンロード失敗か設定ファイルの解析失敗かを切り分ける

サブスクリプションの更新に失敗しても、リンク切れとは限りません。エラーが発生した段階を確認しましょう。クライアントが応答を受け取れているか、その内容がClashの設定ファイルか、現在のコアが設定内の項目に対応しているかを順番に調べると、再インストールを繰り返すより原因を特定しやすくなります。

まず、現在使えている設定を残し、テスト用の新しい設定を作成します。原因調査のためにすべてのノードを削除したり、DNS・TUN・プロキシモードを一度に変更したりしないでください。一度に変更するのは1項目だけにし、更新した時刻とエラーの全文を記録します。

表示されたメッセージまず確認する項目次の手順
401、403、404認証、リンクの状態、サーバー側の制限提供元の管理画面にログインし、購読リンクをコピーし直す
timeout、no such hostネットワーク接続、ドメイン名の解決Wi-Fiとモバイルデータで結果を比較する
yaml、unmarshal、line応答内容とYAMLの構造Webページが返されていないか確認し、エラー行を調べる
unsupported、unknown proxy typeプロトコルとコアの互換性ノードの種類とクライアントのコアを確認する
更新は成功するが、ノードが使えないノード、プロキシグループ、ルール、DNS接続のトラブルシューティングに切り替え、購読URLだけを調べるのはやめる

原因その1：リンク切れ、トークンの失効、コピー漏れ

提供元の管理画面からコピーし直す。チャット履歴からつなぎ合わせない

サブスクリプション提供元のアカウントページを開き、プランの状態、有効期限、残りの通信量を確認してから、購読ページに進みます。購読情報をリセットすると、古いURLがすぐに無効になるサービスもあります。アカウントにログインできても、以前のトークンが有効とは限りません。

  1. 管理画面でClashまたは現在使用しているmihomoクライアントに対応した形式を選び、コピー用ボタンでURL全体を取得します。
  2. クライアントの設定編集画面を開き、URLがhttps://で始まっていること、末尾に余分な空白・改行・句点がないことを確認します。
  3. 元のクエリパラメーターはそのまま残します。疑問符以降を削除したり、&以降のパラメーターを途中で切り取ったりしないでください。
  4. 新しい設定として保存し、手動で一度更新します。状態が失敗から成功に変わるか、最終更新時刻が変化するかを確認します。

コピーした文字列に&がそのまま含まれている場合、Webページでエスケープされたソースをコピーした可能性があります。パラメーターを一つずつ推測して直すのではなく、提供元のコピー画面から取得し直してください。QRコードで読み込んだ場合も、設定が実際に作成されたかを確認します。読み込みに成功しただけでは、購読リンクが有効とは限りません。

HTTPステータスコードの見方

401は通常、認証に失敗したことを示します。403は権限による制限のほか、セキュリティシステムによる遮断の可能性もあります。404はURLの変更やパスの誤り、または無効なリソースをサーバーが非公開にしている場合に発生します。ステータスコードだけでプランの期限切れとは判断できません。429の場合は連続更新を止め、サーバーの案内に従って待ちます。5xxの場合は、まず提供元のサービス状況を確認してください。

原因その2：Clashの設定ファイル以外が返されている

購読URLをブラウザーで開けても、リクエストに応答があったことしか分かりません。ログインページ、認証画面、エラーメッセージ、別のクライアント用のノード一覧が返されることもあります。ステータスコードが200でも、Clashで解析できるとは限りません。

ブラウザーで実際の応答内容を確認する

  1. コピーした購読URLを自分の端末で開きます。公開Webプロキシを介してアクセスしないでください。
  2. ファイルがダウンロードされた場合は、ローカルのテキストエディターで開きます。テキストが直接表示された場合は、先頭部分と主な項目を確認します。
  3. ログイン画面、認証画面、<html>、<!DOCTYPE html>が表示された場合、設定ではなくWebページを取得しています。
  4. ss://やvmess://などのリンクが複数並んでいる場合や、エンコードされた文字列だけが表示される場合は、管理画面でClash形式を選び直します。拡張子を.yamlに変更するだけでは解決しません。

一般的なClash設定ファイルには、proxiesまたはproxy-providersに加えて、proxy-groupsやrulesなどが含まれます。ただし、proxiesの有無だけで有効かどうかは判断できません。リモートのプロキシセットを使う設定では、ノードが直接記述されていない場合があります。

「設定一式のサブスクリプション」と「プロキシセットファイル」は区別が必要です。プロキシセットはproxies:から始まることが多く、メイン設定のproxy-providersから参照されます。日常利用に必要なプロキシグループやルールが含まれているとは限りません。インポート先を間違えると、プロキシグループが表示されなかったり、想定と異なる動作になったりします。

原因その3：ネットワーク、DNS、TLSによる更新リクエストの遮断

接続タイムアウト、ドメイン名の解決失敗、証明書エラーが発生した場合は、まず通信経路を確認します。すぐにYAMLを編集しないでください。この段階では設定ファイルを取得できていない可能性があり、ルールを変更しても今回のダウンロード失敗は解消しないことがほとんどです。

2種類のネットワークで条件を一つずつ変えて比較する

  1. エラー全文を記録し、同じURLを使って、まずWi-Fiで一度更新します。
  2. 次にモバイルデータへ切り替え、もう一度更新します。一方のネットワークだけで失敗する場合は、そのネットワークのDNS、認証ポータル、アクセス制限を重点的に確認してください。
  3. 利用可能な設定がある場合は、サービスを停止した状態と起動した状態で更新結果を比較します。クライアントのバージョンによっては、購読リクエストがプロキシを経由するか、どの経路から送信されるかが異なります。
  4. システムの「設定」→「システム」→「日付と時刻」を開き、自動設定を有効にします。メニュー名はスマートフォンのメーカーによって異なります。端末の日付が大きくずれていると、証明書の有効期間を正しく判定できないことがあります。

no such hostはドメイン名の解決エラー、connection refusedは接続拒否、i/o timeoutはリクエストのタイムアウトを示します。x509に関するエラーがある場合は、証明書とシステム時刻を確認してください。こうした情報は、単に「更新失敗」と表示されるより原因の特定に役立ちます。

更新にプロキシが必要なのに、使える設定が一つしかなく、その設定が無効になっていると、「更新するにはネット接続が必要だが、ネット接続には更新が必要」という状態に陥ることがあります。別の信頼できるネットワークで設定を取得するか、提供元の案内に従って一時的にローカルファイルをインポートしてください。証明書エラーを回避するために検証を常時無効にしたり、HTTPSのURLを安易にHTTPへ変更したりしないでください。

設定のダウンロードは成功しているのに、ログにproxy-providerまたはrule-providerの取得失敗が記録される場合は、後続のリソース取得で問題が起きています。対象のリソース種別とドメイン名を記録し、それぞれの接続性を確認してください。メインのサブスクリプション更新が成功しても、すべてのリモートリソースが更新されたとは限りません。

原因その4：YAML構文エラーまたはコアの互換性問題

行番号が表示される場合は、その行と一つ上の階層のインデントを確認する

YAMLでは空白の数で階層を表します。タブ、全角コロン、閉じ忘れた引用符、リストのインデントずれなどが解析エラーの原因になります。エラー行はパーサーが問題を検出した位置にすぎず、実際の原因が前の行にあることもあります。前後の行もあわせて確認してください。

  • 同じ階層の項目はインデントをそろえます。以下の例は半角スペース2つで統一し、タブは使いません。
  • 項目の区切りには半角コロンを使い、YAMLの仕様に従ってコロンの後ろにスペースを入れます。
  • ノード名に: や #などの特殊な並びが含まれる場合は、文字列全体を引用符で囲みます。
  • プロキシグループが参照するノード名とグループ名は、大文字・小文字や空白を含めて一致させます。
  • 同じ階層でrulesなどのキーを重複して定義しないでください。重複キーの扱いはパーサーによって異なる場合があります。

以下はリストと文字列の記述例です。サブスクリプションをそのまま置き換えられる完全なプロキシ設定ではありません。

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - DIRECT

rules:
  - "DOMAIN-SUFFIX,example.com,DIRECT"
  - "MATCH,手動選択"

ローカルで編集した後にエラーが発生した場合は、編集前のコピーに戻します。リモートのサブスクリプション自体に問題がある場合は、提供元に修正を依頼してください。ローカルのキャッシュだけを変更しても、次回の更新で上書きされる可能性があります。

YAMLとして正しくても、現在のコアが対応しているとは限らない

オリジナル版ClashとClash Meta（現在の名称はmihomo）では、利用できる設定機能が完全には一致しません。たとえばtype: hysteria2を含むノードには、そのプロトコルに対応したコアが必要です。古いオリジナル版Clashのコアは、ファイルがYAML形式でも該当ノードを認識できません。

クライアントの「アプリ情報」またはコア情報の画面で、クライアント名、アプリのバージョン、コアのバージョンを確認し、購読提供元が指定する要件と照らし合わせます。画面が似ていても、同じコアとは限りません。サブスクリプションを更新するだけでは、古いコアに新しいプロトコルへの対応が追加されることもありません。クライアントを変更する場合は、まずクライアント比較ガイドを確認し、新しいクライアントに合った形式を選んでください。

Androidクライアントで一通り確認する

従来のClash for Androidの画面を例にすると、「設定」→右上の「＋」→「URL」と進み、名前と購読URLを入力して保存します。既存の設定は、該当項目のメニューから編集または更新できます。派生版ではボタン名が異なる場合があるため、実際の画面を確認してください。ノードのインポート画面を設定一式のインポート画面と間違えないようにしましょう。

  1. まず更新：リクエストが完了するまで待ち、成功した時刻またはエラー全文を記録します。更新ボタンを繰り返し押しても形式の問題は解決せず、アクセス制限がかかるおそれもあります。
  2. 次に選択：一覧にある古い設定ではなく、更新したテスト用の設定が現在有効になっているか確認します。
  3. 次に起動：ホーム画面に戻ってサービスを起動します。初回起動時はAndroidのVPN接続許可を確認し、設定の読み込みエラーが表示されないか確認します。
  4. プロキシグループを確認：プロキシ画面を開き、プロキシグループに想定したノードがあることを確認してから、ノードを一つ選んで接続テストをします。
  5. 実際のアクセスを確認：対象のWebページを開きます。遅延テストの成功は、テスト先にその時点で接続できたことを示すだけで、すべてのサイトやルールが正常とは限りません。

更新に成功し、サービスも起動するのにWebページを開けない場合は、通常、サブスクリプションの解析は通過しています。次はプロキシモード、ノードの状態、DNS、アプリのアクセス制御を確認してください。この段階でTUNを切り替えたりmixed-portを変更したりする必要はありません。実際の接続問題に応じて個別に調べましょう。

解決しない場合は、個人情報を伏せて次の情報を共有する

提供元やクライアントの開発者に問い合わせる際は、「サブスクリプションが壊れた」とだけ伝えるより、再現条件を明記すると役立ちます。以下の5項目をまとめてください。

  • クライアント名、アプリのバージョン、コアの名称とバージョン、Androidのバージョン。
  • 失敗した具体的な日時、Wi-Fiとモバイルデータのどちらを使用したか、その時点でサービスが起動していたか。
  • エラーの全文と行番号。ログに含まれるトークン、パスワード、個人用ドメインは必要に応じて隠します。
  • ブラウザーに設定テキストやダウンロードファイルが表示されたか、ログインページやエラーページが表示されたか。
  • 同じリンクを別のネットワークで試した結果と、最後に更新に成功した日時。

「リンクの状態 → 応答形式 → ネットワークリクエスト → 構文とコア」の順に確認すると、問題の範囲を絞り込みやすくなります。利用できる設定を残し、一度に変更する項目を一つにして、エラー全文と更新結果で確認すれば、試行錯誤を減らせます。