Clashのサブスクリプションを読み込む方法：URL・ローカルYAML・Base64形式の見分け方

サブスクリプションURLと設定内容を区別する

読み込む前に、手元にあるものが何かを確認しましょう。URLはリソースのアドレス、YAMLは設定ファイルのテキスト形式、Base64はデータのエンコード方式です。これらは互いに排他的なサブスクリプション形式ではありません。同じHTTPSアドレスでも、YAMLが返る場合もあれば、Base64でエンコードされたノード一覧やログイン画面が返る場合もあります。

Clashクライアントは設定を管理し、操作画面を提供してプロキシコアを起動します。mihomoはClashの設定体系に対応し、機能を拡張したコアで、Clash Metaとも呼ばれます。設定を利用できるかどうかは、取得した内容だけでなく、現在のコアが記述されたプロトコルや項目に対応しているかにも左右されます。

URLサブスクリプションの読み込み：アドレスのコピーから設定の選択まで

1. Clashまたはmihomo用のサブスクリプションをコピーする

サブスクリプション提供元のアカウントページを開き、「Clash」「Clash Meta」「mihomo」と表示されたエクスポート項目を選びましょう。項目によって返されるプロトコルや設定構造が異なります。「汎用サブスクリプション」は、完全なClash設定としてそのまま使えるとは限りません。

コピーするのは実際のサブスクリプションURLです。アカウント管理画面のブラウザーアドレスや、ボタンの横にある説明文ではありません。先頭に空白がなく、末尾に句点が付いていないことを確認してください。URL内の &、=、パーセントエンコードには意味がある場合があるため、自分で削除・変更しないでください。

2. クライアントの設定画面から読み込む

1. クライアントを開き、「設定」または「Profiles」画面に移動します。Clash Verge Revの場合は、まずサイドバーの「設定」をクリックし、その画面にあるサブスクリプションURLの入力欄を使います。
2. URL全体を貼り付けて「インポート」をクリックします。現在のバージョンで「新規作成」画面が表示される場合は、リモート設定を選んでURLを入力してください。
3. 設定カードが表示されるまで待ちます。更新日時やエラーメッセージを確認し、インポートを続けて何度もクリックしないでください。
4. 読み込んだ設定を選択し、現在の設定として適用します。リストに表示されただけでは有効になっていません。
5. 「プロキシ」画面を開き、実際に使うプロキシグループを展開して、ノードが表示されることを確認してから利用可能なノードを選びます。

ほかのクライアントでは、メニューバーアイコンの「設定」メニューに同様の操作がある場合もあります。項目名は異なっても、リモートの内容を取得し、設定を解析し、設定を選択して、プロキシグループを確認する流れは同じです。

3. ダウンロード成功と設定の適用を区別する

「サブスクリプションの更新に成功」と表示されても、通常は今回の内容取得と処理が完了したことを示すだけです。選択したノードに接続できることや、ブラウザーの通信がプロキシ経由になったことを意味するわけではありません。まず現在の設定を確認し、次にプロキシモードを確認しましょう。通常は「ルール」モードから始め、設定内のルールに従って直接接続するかプロキシを使うかを決めます。

ローカルYAMLを読み込む：構造と入手元を確認する

YAMLではインデントで階層を表します。Clashの設定には、ノードを表す proxies、プロキシグループを表す proxy-groups、振り分けルールを表す rules がよく使われます。また、proxy-providers から外部ノードを読み込む場合もあります。proxies が直接記述されていなくても、設定が空とは限りません。

1. ファイルは「ダウンロード」フォルダーなど、見つけやすい場所に保存します。Webページを別名で保存したHTMLファイルではないことを確認してください。
2. クライアントの設定画面を開き、「ファイルをインポート」またはローカル設定の項目を使います。ファイルのドラッグ＆ドロップに対応しているクライアントもあるため、画面の案内に従ってください。
3. 設定を選択し、解析エラーが表示されないか確認します。エラーに行番号が示されている場合は、該当行とその直前の行について、インデントやコロン、引用符を優先して確認してください。
4. 外部ノードソースやルールソースが正常に読み込まれているか確認します。ローカルファイルでも、ネットワーク上のリソースに依存する場合があります。

読み込み手順の確認に使える最小構成の設定

以下はローカル設定として保存できるYAMLの例です。ローカルの 7890 ポートで待ち受け、リクエストを直接接続に送ります。プロキシノードは含まれていないため、ファイル形式と設定読み込みの確認専用です。プロキシ回線のテストには使えません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

mixed-port は、HTTPとSOCKSの両方のプロキシリクエストを受け付ける混合ポートです。ここでの 7890 は例であり、すべてのクライアントで固定の値ではありません。画面上のポート設定や設定の上書きで変更されている場合は、実際の待ち受けポートを確認してください。

YAMLを編集するときは、タブを使わずスペースでインデントしてください。ノードのパスワードやURL、名前に特殊文字が含まれる場合は、YAMLの構文に従って引用符で囲みます。リモート設定を直接編集すると、次回の更新で変更が上書きされる可能性があります。継続的に調整する場合は、クライアントの上書き機能やマージ機能を使いましょう。

Base64を見分ける：デコード後も内容の確認が必要

Base64は暗号化ではありません。一般的なエンコード文字列には英字、数字、プラス、スラッシュが含まれ、末尾に等号が付く場合があります。URLセーフな形式では、ハイフンやアンダースコアが使われることもあります。ただし、長い文字列に見えるだけで、有効なサブスクリプションだとは判断できません。

デコード結果によくある3つのパターン

• 複数行のノードURI：複数の ss:// や vmess:// リンクなど。ノードの一覧であり、プロキシグループや振り分けルールを含む完全な設定ではありません。
• YAMLテキスト：設定の構造とコアとの互換性を確認してください。デコードできただけでは、利用可能とは判断できません。
• エラーメッセージなどのテキスト：提供元のページに戻り、サブスクリプションの利用権限、リンクの種類、有効期限を確認してください。

オフラインで確認する必要がある場合は、Macの「ターミナル」で以下のコマンドを実行できます。確認したいエンコード文字列を先にクリップボードへコピーしてから実行してください。コマンドはローカルでデコードするだけで、結果はターミナルに表示されます。

pbpaste | /usr/bin/base64 -D

これはmacOS標準ツールで使う引数の形式です。デコードエラーが出ても、テキストの欠落や余計な文字の混入、異なるエンコード形式が原因の可能性があり、アカウントが無効になったとは限りません。結果にパスワードが含まれる場合があるため、画面を録画したり、そのまま共有したりしないでください。確認後はクリップボードを消去しましょう。

結果がノード一覧で、クライアントのリモート設定画面が完全なYAMLしか受け付けない場合は、提供元に戻ってClash専用サブスクリプションを選びます。汎用ノードサブスクリプションを明確にサポートするクライアント、または信頼できるローカル変換手段を設定済みの場合に限り、該当する読み込み方法を使ってください。認証情報を含むサブスクリプションを、出所のわからないオンライン変換サービスに渡してはいけません。

初回の動作確認：設定・ノード・通信を3段階でチェック

まず設定とプロキシグループを確認

現在の設定に選択済みのマークがあり、「プロキシ」画面のノード名が今回読み込んだ内容と一致することを確認します。プロキシグループは、利用する出口を選ぶための設定です。ルールが参照するグループが存在しない場合、ファイルをダウンロードできても、正しく読み込まれなかったり通信を振り分けられなかったりすることがあります。

次にノードが使えるか確認

「プロキシ」画面で遅延テストを1回実行します。テスト結果は、クライアントがテスト先を探査した結果を示すもので、ダウンロード速度とは異なり、すべてのWebサイトにアクセスできる保証にもなりません。タイムアウトした場合は別のノードでもう一度試し、ログに接続エラーや認証エラーがないか確認してください。赤い数値が1つ出ただけでクライアントを再インストールする必要はありません。

最後にアプリの通信がプロキシを通るか確認

クライアントで「システムプロキシ」を有効にし、ブラウザーで確認したいWebサイトを開きます。システムプロキシはmacOSがアプリに提供するプロキシ設定で、この設定に従うアプリだけが利用します。ターミナルのコマンドや一部のアプリは自動で設定に従わないため、プロキシポートを明示してテストできます。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

実行前に、コマンド内のポートをクライアントで使用しているHTTPポートまたは混合ポートに変更してください。127.0.0.1 はこのMacを指します。接続待ちの上限は10秒、リクエスト全体の上限は20秒です。HTTPレスポンスが返ればリクエスト経路から応答を受け取れたことはわかりますが、リモートノードを経由したかどうかは、「接続」画面やログのルール適用先と出口も確認してください。

TUNは仮想ネットワークインターフェースで通信を取り込む方式で、通常はシステムプロキシより広い範囲をカバーします。サブスクリプションを初めて読み込んだ段階で、すぐにTUNを有効にする必要はありません。まず設定と通常のプロキシリクエストが動作することを確認してから、アプリの用途に合わせて通信の取り込み方法を調整すると、問題の切り分けが簡単になります。

サブスクリプションの更新間隔を設定する：まず手動更新を成功させる

設定カードの操作メニューから、まず「更新」を1回実行します。更新日時が変わり、設定が引き続き読み込めることを確認したら、その設定の編集または設定画面を開き、自動更新と更新間隔の項目を探します。クライアントによって単位は分・時間・秒と異なるため、入力前に必ず確認してください。

• 一般的な個人利用：まずは24時間に1回、つまり1440分または86400秒から始めるとよいでしょう。あくまで初期設定の目安であり、プロトコルの規定ではありません。
• ノードが頻繁に更新される場合：提供元の案内に従って6時間または12時間ごとに設定します。間隔を数秒まで短くしないでください。
• ノードやプランを一時的に変更する場合：提供元で変更した後に手動で更新し、プロキシグループに新しいノードが表示されることを確認します。
• Macを頻繁に閉じる場合：スリープ中はクライアントのタスクが予定どおり実行されないことがあります。復帰後に実際の更新日時を確認し、必要に応じて手動更新してください。

サブスクリプションの更新、ノードソースの更新、ルールソースの更新、遅延テストは、それぞれ別の処理です。YAML内のproviderにある interval は秒単位の場合がありますが、クライアントの設定カードに共通する更新間隔ではありません。更新頻度を上げるために、interval を含む項目をむやみに変更しないでください。

現在の設定の更新に既存のプロキシが必要な場合は、更新前に利用可能なノードを1つ残しておきます。更新に失敗したときに古い設定が保持されるか確認し、新しいアドレスにアクセスできないと判明する前に、唯一動作する設定を削除してしまわないようにしてください。

読み込み・更新に失敗した場合：エラーの種類ごとに対処

内容はダウンロードできたが、ノードがない

ルールだけを含むファイルを誤って使っていないか、ほかの設定から参照する必要があるノードソースファイルを読み込んでいないか確認します。完全な設定、ノードproviderファイル、ルールproviderファイルは用途が異なります。拡張子が同じYAMLだからといって、互いに置き換えられるわけではありません。

ブラウザーではURLを開けるのに、クライアントの更新は失敗する

ブラウザーはログインCookieを送る場合がありますが、クライアントは通常、ブラウザーのログイン状態を引き継ぎません。また、サーバーがリクエストヘッダーに応じて異なる形式を返すこともあります。アカウントページに戻って専用のサブスクリプションURLを取得し、クライアントのログで実際のエラーを確認してください。エラーを回避するために証明書の検証を無効にしないでください。

URLを公開してしまった場合の対処

提供元の管理画面でサブスクリプショントークンをリセットし、すべての端末で新しいURLに更新したうえで、古いURLが無効になったことを確認します。チャットのスクリーンショットを削除したり、ローカル設定を消したりしても、漏えい済みのアクセス情報は無効になりません。