ClashのサブスクリプションURLを読み込む方法｜YAMLとBase64の違い

サブスクリプション形式を確認してからURLを読み込む

サービス提供元のページで「Clash」「Clash Meta」または「mihomo」と記載されたサブスクリプションURLをコピーし、クライアントの「設定」画面から読み込みます。ダウンロード、設定の有効化、通信のプロキシ経由化はそれぞれ別の手順です。設定カードが一覧に表示されても、クライアントに設定が保存されたことを示すだけで、ブラウザーがプロキシ経由で通信しているとは限りません。

サブスクリプションURLは通常、設定データを返すHTTPSリンクです。サービス提供元のログインページや、QRコードが表示されたページのURLではありません。アクセス用の認証情報が含まれる場合があります。コピーするときはページ内の「サブスクリプションURLをコピー」ボタンを使い、ブラウザーのアドレスバーからアカウントページのURLをコピーしないでください。

読み込み前に確認する3項目

• クライアントのコア：mihomoを使うクライアントは、より多くのプロトコルや設定項目に対応しています。旧式のClashコアでは新しいプロトコルを認識できない場合があります。画面上で読み込みが完了しても、コアがサブスクリプションの内容すべてを解析できるとは限りません。
• サービスの状態：アカウントの有効期限、通信量の上限、サブスクリプションURLの再発行状況を確認します。まずサービス提供元の管理画面で確認してください。ローカルのポートを何度も変更しても解決しません。
• URLの完全性：元のhttps://、パス、クエリパラメーターをそのまま保ちます。不要に見える文字を手動で削除したり、改行や引用符まで一緒に貼り付けたりしないでください。

サブスクリプションURLの読み込み：追加から有効化まで

ボタンの位置はクライアントによって異なります。デスクトップ版では通常、「設定」→「新規作成」または「インポート」の順に操作します。Clash for Androidでは「設定」→「＋」→「URLからインポート」が一般的です。以下では操作の目的に沿って説明し、特定のクライアントのメニュー名を共通仕様として扱いません。

1. 専用URLをコピーする。サービス提供元のページで、コアに合ったClashまたはmihomo形式を選びます。「汎用サブスクリプション」と「Clashサブスクリプション」の両方がある場合は、まず後者を選んでください。
2. リモート設定を新規作成する。クライアントの「設定」画面を開き、URLからインポートする項目を選びます。「ローカル／リモート」の種類を選べる場合は「リモート」を指定します。「ローカル」は通常、端末内のファイルを読み込むときに使います。
3. 名前とURLを入力する。名前は「普段使いのサブスクリプション」などにします。URL欄にはサブスクリプションURL全体だけを入力してください。更新間隔は画面に表示された単位に合わせます。分単位の欄に時間数をそのまま入力しないでください。
4. 保存してダウンロードを待つ。「保存」「インポート」または「ダウンロード」をクリックします。エラー表示、更新時刻、設定項目が表示されるか確認してください。失敗した場合は、何度も再試行して最初のエラーが分からなくなる前に、エラーメッセージを記録します。
5. 設定を有効にする。設定一覧から、読み込んだ項目を選択します。選択状態が切り替わり、設定の解析エラーがないことを確認してください。自動で適用されるクライアントもあれば、別途「有効化」をクリックする必要があるものもあります。
6. プロキシグループの接続先を選ぶ。「プロキシ」画面を開き、手動選択が必要なグループではノードを選択します。サブスクリプションに自動選択グループがある場合は、それを選んでも構いません。ノード一覧が表示されたのを確認しただけで画面を閉じないでください。
7. プロキシが必要な通信を経由させる。デスクトップでは、まず「システムプロキシ」を有効にしてブラウザーで確認できます。Androidでは通常、接続を開始してシステムVPNの使用を許可します。TUNモードはサブスクリプションを読み込むための必須条件ではありません。

QRコードしかない場合は、QRコードの中身がサブスクリプションURLか、単一ノードのURIかを確認してください。ss://のQRコードは通常、1つのノード情報を表すもので、ルールやプロキシグループ、リモート更新URLまで含むとは限りません。QRコードを読み取れても、完全なサブスクリプションを読み込めたとは限りません。

YAMLとBase64の違い：設定構造とエンコード方式

YAMLは設定を記述する形式、Base64はエンコード方式であり、同じ階層のものではありません。「Base64サブスクリプション」は一般に、複数のノードURIを連結してからエンコードしたものを指しますが、別のテキストをエンコードしただけの場合もあります。ダウンロードしたファイル名だけで判断せず、デコード後の内容を確認してください。

完全な設定の構成例

以下はYAMLの階層とキー名を示す例です。リモートノードは含まれず、プロキシグループから選べるのは直接接続だけなので、プロキシの接続確認には使えません。実際のサブスクリプションはproxy-providersでノードを取り込む場合もあるため、proxiesが設定内にないからといって、必ずしも破損しているとは限りません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: 接続先の選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,接続先の選択

mixed-port: 7890は、同じローカルポートでHTTPとSOCKSのプロキシ接続を受け付ける設定です。サービス提供元のノードのポートではありません。ここではrulesの最後のルールがリクエストを「接続先の選択」に渡しますが、このグループにはDIRECTしかないため、最終的に直接接続になります。YAMLのインデントにはスペースを使い、Tabは使わないでください。階層に誤りがあると、通信を始める前の解析段階で失敗することがあります。

Base64をデコードしても使えないのはなぜ？

デコードで元に戻るのはテキストだけです。proxy-groupsやDNS、ルールは追加されません。デコード後に有効なノードURIが得られても、クライアントのコアが該当するプロトコルに対応している必要があります。最も簡単なのは、サービス提供元のページから対象クライアント専用のサブスクリプションを取得する方法です。変換が必要な場合は、クライアントの内蔵機能か信頼できるローカルツールを使い、変換後のプロキシグループとルールを確認してください。

読み込みに失敗したときの切り分け：ダウンロード・解析・接続

まず、どの段階でエラーが発生したかを確認します。設定をダウンロードできていないなら、rulesを編集しても効果はありません。解析に成功しているのにサイトを開けない場合も、同じサブスクリプションURLを繰り返しコピーしても通常は解決しません。

第1段階：正しい内容を取得できない

• 401 Unauthorized：認証が必要か、トークンが無効になっている可能性があります。管理画面で生成したURL全体をコピーし直し、サブスクリプションが再発行されていないか確認してください。
• 403 Forbidden：アクセス制限、アカウントの制約、リクエストのブロックが原因の可能性があります。サービス提供元の案内を確認してください。ローカルの待ち受けポートを変更しても解決しません。
• 404 Not Found：コピーが途中で切れていないか、パスが無効になっていないか、取得したURLがウェブページのものではないかを確認してください。
• no such host：サブスクリプションのドメイン名を解決できていません。ドメインのスペルを確認し、現在のネットワークのDNSも確認してください。この段階ではノードへの接続はまだ行われていません。
• i/o timeout：ログでタイムアウトした接続先を確認します。接続先がサブスクリプションサーバーなら、まずサブスクリプションのダウンロード経路を調べてください。まだダウンロードできていないノードに切り替えても解決しません。

ブラウザーではURLを開けるのにクライアントでは開けない場合でも、URLに問題がないとは限りません。ブラウザーがログインCookie、別のプロキシ、異なるリクエスト情報を使っている可能性があります。サービスによってはリクエストに応じて異なる形式を返すため、明示的に用意されたClash専用のURLを使ってください。応答内容を確認する場合はローカルで行い、設定全体を公開しないでください。

第2段階：ダウンロードできても解析できない

応答の先頭が<!DOCTYPE html>または<html>なら、取得したのはYAMLではなくウェブページです。ログインページや認証ページの可能性があります。yaml: lineのようなエラーが出た場合は、表示された行番号を手掛かりにインデント、コロン、引用符を確認し、応答にウェブページのテキストが混ざっていないかも調べてください。ログに未対応のプロキシタイプが示されている場合は、コアの対応範囲を確認し、対応する形式を使うか互換性のあるコアに更新します。フィールドを適当に削除して回避しないでください。

第3段階：設定は有効でも通信できない

まず「プロキシ」画面で、現在のグループがDIRECTやREJECTを選んでいないことを確認します。次に「接続」または「ログ」で、実際に適用されたルールと接続先を確認してください。システムプロキシの設定が反映されるのは、その設定に従うアプリだけです。ゲーム、コマンドラインツール、独自のネットワーク処理を行うアプリでは、個別にプロキシを設定するか、ルーティングへの影響を理解したうえでTUNを使う必要があります。「読み込み成功」と「すべてのアプリの通信がプロキシ経由になる」は同じではありません。

更新後は、更新完了だけでなく設定への反映も確認する

リモート設定では通常、サブスクリプション元の情報が保持され、手動または定期的に更新できます。ローカルファイルから読み込んだ設定は、その時点のコピーにすぎないことが一般的です。更新が反映されたか確かめるには、使用中の設定カードで「更新」を実行し、更新時刻が変わったことを確認してからノード一覧を確認します。別の古い設定を使い続けている場合、ダウンロードに成功しても現在の接続先は変わりません。

1. 有効な設定を確認：一覧の並び順ではなく、選択中の表示を確認します。
2. 変更点を確認：サービス提供元が追加・削除したノードやプロキシグループ名を確認します。変化がなくても、配信元の内容が変わっていないだけの場合があります。
3. アプリのログを確認：更新後に解析エラーや再読み込みエラーが出ていないか確認します。以前正常に使えていた設定が引き続き使われるクライアントもあります。
4. 新しい接続でテスト：ページを開き直すか、新しいリクエストを送信します。既存の長時間接続は以前の接続先を使い続ける場合があるため、切り替え結果の確認には向きません。

よくある質問：ファイルの読み込み、ポート、重複登録

.yamlファイルをダウンロードすれば、サブスクリプションURLの代わりになりますか？

ローカル設定として読み込めますが、通常は元のサブスクリプションURLや自動更新の機能は引き継がれません。一時的な確認やオフラインでの移行には便利です。サービス提供元の変更を継続して反映したい場合は、リモートURLから読み込んでください。拡張子だけでは内容の正しさは保証されません。config.yamlという名前でも、実際にはエラーページが保存されている場合があります。

読み込み後、ポートを必ず7890に変更する必要がありますか？

必要ありません。7890はよく使われる例の値にすぎません。クライアントに現在表示されている待ち受けポートを使ってください。アプリに127.0.0.1:7890を手動で入力していても、クライアントの実際の待ち受けポートが7897なら一致しません。address already in useが表示された場合は、プロキシクライアントが2つ同時に起動していないか確認してください。解説記事に合わせるために、ポートをむやみに上書きしないでください。詳しくはローカルポートの設定方法を参照してください。

同じURLを何度も読み込むと通信速度は上がりますか？

上がりません。重複して読み込むと設定項目が増えるだけで、どの設定を使うかは有効な設定によって決まります。更新できるリモート設定を1つと、必要なバックアップを残せば十分です。1つのサブスクリプションに複数のノードが含まれている場合は、同じURLを何度も登録するのではなく、プロキシグループでノードを選ぶか、自動選択グループを使ってください。

最後に、専用のサブスクリプション形式が正しいこと、ダウンロードで有効な内容を取得できること、設定を解析して有効化したこと、プロキシグループの接続先が正しいこと、対象アプリの通信がプロキシ経由になっていることを順に確認します。以降、タイムアウトが発生した場合はタイムアウトの診断方法を参照してください。初めて設定する場合は、サブスクリプションの読み込みガイドに沿って確認できます。