ClashのサブスクリプションURLをインポートする方法：URL・ローカルYAML・Base64の違い

サブスクリプションURL・設定ファイル・ノードリストの違いを確認

サブスクリプションを入手したら、まず提供元に「Clash」または「Clash Meta / mihomo」専用の項目があるか確認し、クライアントの設定画面を開きます。ブラウザーの管理画面URL、個別のノードリンク、サブスクリプションURLを混同しないようにしましょう。どれも文字列に見えますが、クライアントでの扱いは異なります。

URLはコンテンツの取得先、YAMLは設定の記述形式、Base64はテキストのエンコード方式です。この3つは同じ階層の選択肢ではありません。HTTPSのサブスクリプションURLから取得できる内容は、YAMLの場合もあれば、Base64でエンコードされたノードリストの場合もあります。インポートに失敗したら、URLがhttps://で始まるかだけでなく、実際に返される内容を確認してください。

URLからインポート：リモート設定を保存し、現在の設定として選択

クライアントに対応したサブスクリプションURLをコピーする

1. サブスクリプション提供元の管理画面にログインし、「サブスクリプション」または「設定をエクスポート」を開いて、Clashまたはmihomo用の形式を選びます。汎用形式しかない場合は、クライアントが変換に対応しているか先に確認してください。
2. ページのコピー機能でURL全体を取得します。チャットアプリからコピーすると句点、改行、引用符が混入することがあるため注意してください。特に?以降のアクセス用パラメーターを省略しないようにしましょう。
3. クライアントの設定一覧を開き、「新規作成」「追加」またはプラスボタンを選択し、リモートURLの種類に切り替えます。「普段使いのサブスクリプション」など、見分けやすい名前を付けましょう。
4. URLを貼り付けて保存し、初回の取得が完了するまで待ちます。エラーの詳細が表示された場合は、ステータスコードや解析エラーを控え、同じURLを何度も追加しないでください。
5. 設定一覧から追加した項目を選び、現在の設定として有効になっていることを確認します。次にプロキシ画面を開き、プロキシグループが表示されることを確認してから、利用可能なノードを選択します。

「ダウンロード完了」はクライアントが設定を取得したことを示すだけで、システムの通信がプロキシ経由になったとは限りません。インポート後は用途に応じてシステムプロキシを有効にしてください。より多くのアプリの通信を処理する場合はTUNを設定します。最初の動作確認ではまず一方の方式だけを使い、接続を確認してから機能を追加すると、インポートの問題とルーティングの問題を切り分けやすくなります。

更新間隔を設定し、2種類の更新を区別する

自動更新に対応している場合は、まず24時間ごとの更新に設定します。画面によって時間単位の場合と分単位の場合があり、分単位なら1440分を指定してください。これは初期設定の目安です。最終的には提供元のリクエスト頻度制限に従ってください。短時間に何度も更新すると、アクセス制限がかかることがあります。

「リモート設定全体の更新」と「設定内のproxy-providersの更新」は別の処理です。前者はクライアントの設定管理機能が担当し、後者はカーネルがプロバイダーのinterval設定に従ってノードを取得します。プロバイダーのinterval: 86400は86400秒を意味しますが、クライアントがメイン設定全体を1日ごとに再ダウンロードする設定ではありません。

ローカルYAMLをインポートする：完全な設定かどうかを確認

.yamlまたは.ymlファイルがある場合は、設定画面からファイルのインポートを選び、ファイル選択画面で対象を開きます。インポート前にテキストエディターで内容を確認してください。先頭が<!DOCTYPE html>、ログインページ、またはエラーメッセージなら、保存したのは設定ファイルではなくWebページです。拡張子をYAMLに変えても、ファイルの中身は変わりません。

設定を構成する3つの要素を確認

• ノードの定義：proxiesでノードを直接定義するか、proxy-providersでノードの一覧を読み込みます。ノードプロバイダーファイルには通常ノード一覧しか含まれず、完全なメイン設定とは異なります。
• プロキシグループ：proxy-groupsで手動選択や自動速度測定などのグループを構成します。ルールが参照するグループ名は、設定内に存在している必要があります。
• ルーティングルール：rulesで通信の経路を決めます。ルールは上から順に照合され、最初に一致したものが優先されます。存在しないグループ名を指定すると、設定を読み込めないことがあります。

以下は構成を理解するための最小限の例です。リモートノードは含まれず、すべての通信が最終的に直接接続されるため、リモートプロキシの動作確認には使えません。7890は混合ポートの例で、すべてのクライアントで固定の初期値ではありません。実際の待ち受けポートはクライアントの表示を確認してください。

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

proxies: []

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

rules:
  - MATCH,手動選択

YAMLはインデントが重要です。Tabではなくスペースを使い、同じ階層のインデントを統一してください。テキストエディターですべてのコロンを一括置換したり、文書作成ソフトで通常の引用符をスマートクォートに変換したりしないでください。特殊文字を含む名前やパスワードは、YAMLの構文に従って正しく引用符で囲みます。

元のファイルと復元用の設定を保存する

クライアントによってはファイルを独自の設定フォルダーにコピーし、別のクライアントでは外部パスを参照できます。インポート後に元ファイルを編集しても、現在の設定に反映されない場合があります。その場合は再インポートするか、再読み込みしてください。正常に動作する設定を1つ残し、DNS、ルール、ノードを変更する前にコピーを作成しておくことをおすすめします。

ローカルファイルでは通常、リモートサブスクリプションのように設定全体が自動更新されることはありません。ただし、ファイル内で参照しているリモートプロバイダーは更新される場合があります。一方、リモートサブスクリプションから取得したファイルを直接編集すると、次回の更新で上書きされることがあります。カスタムルールを継続して使う場合は、クライアントが対応する上書き、マージ、パッチ機能を利用してください。

Base64形式：デコードで得られるのはノードであり、Clash設定ではない

一般的な汎用サブスクリプションでは、複数行のノードリンクをBase64テキストにエンコードしていることがあります。デコードすると、ss://、vmess://、trojan://などのリンクが複数行で現れる場合があります。ルールやプロキシグループを含むYAMLとは限りません。Base64はあくまでエンコード方式で、元のテキストを入手した人は誰でも内容を復元できます。

文字列c3M6Ly8=を例にすると、デコード結果はss://だけです。エンコードの仕組みは確認できますが、接続可能なノードではありません。実際のサブスクリプションにはサーバー、ポート、認証パラメーターも含まれます。また、プロトコルリンクの内部でさらにエンコードが使われている場合もあり、一度デコードするだけですべてのプロトコルを解析できるわけではありません。

順番に変換方法を選ぶ

1. まず提供元のClash用エクスポートを探す。利用するクライアント向けの専用形式を使えば、ノード、グループ、ルールをまとめて取得できることが多く、手作業で補う項目を減らせます。
2. 次にクライアントのインポート機能を確認する。Base64形式の内容をそのまま貼り付けられるのは、汎用サブスクリプションやノードリンクに対応していることが明示されたインポーターだけです。クライアントがmihomoカーネルを使っているからといって、GUIがあらゆるサブスクリプション形式に対応しているとは限りません。
3. 変換が必要な場合は、信頼できる環境で行う。ローカルツール、または提供元が指定するサービスを優先してください。変換後はノード数、プロトコルの項目、プロキシグループの参照先、最終的なルールを確認してからクライアントで有効にします。

変換ツールは、エンコードされたテキストの拡張子を変更するだけのものではありません。ノードのプロトコルを解析し、Clash / mihomoのフィールドに合わせてノードを構成したうえで、メイン設定に必要なグループやルールを補います。対象カーネルが対応していないプロトコルやパラメーターは、変換しても使えるようにはなりません。クライアントの「バージョン情報」で実際のカーネルとバージョンを確認し、そのカーネルが対応する設定構文と照らし合わせてください。

インポートに失敗したら、ネットワーク・取得内容・設定構文の順に確認

まずクライアントのログまたはインポートエラーの詳細を確認してから、次の対応を判断します。ネットワーク要求の失敗、取得内容の不一致、設定構文のエラーはそれぞれ別の問題で、対処方法も異なります。ブラウザーで管理画面を開けても、クライアントがサブスクリプションを取得できるとは限りません。管理画面はログインCookieを必要とする場合がありますが、サブスクリプションAPIには専用のアクセス情報を使います。

「プロキシ経由で更新」は、利用可能なプロキシはあるものの、サブスクリプションサーバーへ直接接続できない場合に使います。利用可能な設定がない状態でこのオプションを有効にすると、設定の更新にはノードが必要なのに、ノードを取得するには更新が必要という状態になることがあります。その場合は、提供元が案内する接続可能なURLを使うか、信頼できるネットワークで設定を取得してローカルからインポートしてください。

インポート後の確認：設定・ノード・通信経路を個別に確認

1. 設定が有効か確認する。現在の設定名、最終更新日時、読み込みログを確認します。設定一覧に項目が表示されていても、カーネルがその設定を使用しているとは限りません。
2. プロキシグループの選択を確認する。プロキシ画面を開き、ルールが実際に参照しているグループでノードを選びます。遅延テストに成功しても、特定のテスト通信が通ったことを示すだけで、すべてのWebサイトに接続できるとは限りません。
3. 通信の入口を確認する。システムプロキシを使う場合は、クライアントの待ち受けポートとシステム設定が一致しているか確認します。たとえばクライアントの混合ポートが7890なら、アプリは対応する127.0.0.1:7890に接続する必要があります。別の端末のポート番号をそのまま使わないでください。
4. ルールが適用されているか確認する。対象のWebページを開いて接続ログを確認し、ドメイン、適用ルール、プロキシグループ、実際の出口を調べます。ログにリクエストがまったく記録されない場合は、サブスクリプションを何度も変えるのではなく、まずアプリがプロキシの入口を使っているか確認してください。

TUNでの通信制御が必要なアプリでは、クライアントの指示に従って権限を付与し、ルートとDNSを設定します。TUNは通信を取り込む方式であり、サブスクリプション形式の変換機能ではありません。DNSハイジャックを設定しても、Base64形式のノードリストが完全な設定になるわけではありません。設定の取得、カーネルの読み込み、通信の取り込みを分けて確認すると、問題の場所を特定できます。

日常のメンテナンスでは、復元できる設定を1つ残し、更新周期を記録し、サブスクリプションの変更後にプロキシグループ名を確認してください。提供元がグループ名を変更すると、カスタムルールや上書き設定が古い名前を参照したままになることがあります。参照先を確認してからルールを調整すれば、「サブスクリプションの更新は成功したのに設定の読み込みに失敗する」という問題を繰り返し調べずに済みます。