ClashのサブスクリプションURLをインポートする方法｜YAML設定とBase64形式の違い

インポート前に確認：サブスクリプションURL・設定ファイル・ノード共有リンクの違い

Clashのサブスクリプションをインポートできない場合、ネットワーク障害ではなく、種類の異なるデータを同じ画面に入力していることがあります。サブスクリプションURLはデータ取得用のURL、YAMLは設定データの記述形式、Base64はエンコード方式です。それぞれ役割が異なるため、URLの見た目が似ているかどうかだけで互換性を判断できません。

• リモートサブスクリプションURL：通常は https:// で始まり、クライアントがアクセスして設定やノード一覧を取得します。URLにアカウント用トークンが含まれる場合があるため、認証情報として安全に管理してください。
• ローカル設定ファイル：拡張子は .yaml または .yml が一般的です。「ファイルをインポート」などのローカル設定用メニューから読み込みます。ローカルのコピーを読み込むだけでは、通常、サービス提供元から自動で更新されません。
• 個別のノード共有リンク：ss://、vmess://、trojan:// などで始まるリンクです。一部のクライアントには専用の解析機能がありますが、Clashコアで完全なYAML設定として直接読み込めるとは限りません。

操作を始める前に、クライアント名と「バージョン情報」画面に表示されるコア名を確認してください。Clash、Clash Meta（現 mihomo）、その他のプロキシコアでは、対応するプロトコルや設定項目が異なります。サービス提供元に「Clash」「Clash Meta」「汎用サブスクリプション」など複数の選択肢がある場合は、使用中のコアに合った形式を選んでからURLをコピーしてください。

YAML設定とBase64形式の違い

完全なClash YAML設定には、通常、ノード、プロキシグループ、ルールが含まれ、それぞれ proxies、proxy-groups、rules などの項目で定義されます。proxy-providers を使って外部のノードリソースを参照する場合もあります。一方、Base64形式のノードサブスクリプションは、複数行の共有リンク全体をエンコードする方式が一般的です。通常、完全なClashのルールやプロキシグループ構成は含まれません。

完全な設定とproviderファイルは相互に置き換えられない

proxies: だけのファイルはノードリソースとして有効でも、すぐに使える完全な設定とは限りません。完全な設定として読み込めても、想定したプロキシグループやルールがない場合があります。逆に、ノードリソース専用の画面に完全な設定を読み込むと、形式エラーになることがあります。拡張子だけで判断せず、インポート先が求める形式を確認してください。

以下は構造を見分けるための、最小限のローカル設定例です。プロキシノードは含まず、すべての接続を直接接続にします。YAMLの階層を示すものであり、サービス提供元のサブスクリプションの代わりに通信するための設定ではありません。

mixed-port: 7890
mode: rule
log-level: info

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

rules:
  - MATCH,手動選択

Base64をデコードしてもClash設定にはならない

Base64のデコードで復元されるのは元のテキストだけです。プロキシグループやDNS設定、ルーティングルールが自動生成されるわけではありません。形式を変換するには、ノード項目を解析し、使用するコアが受け付ける設定を生成する必要があります。変換できても、対象のコアがプロトコルやパラメーターに対応していなければ、ノードは利用できません。中間変換による設定項目の欠落を防ぐため、サービス提供元からネイティブのClash形式またはmihomo形式を入手するのがおすすめです。

ClashのサブスクリプションURLをインポートする手順

クライアントのボタン名はバージョンによって異なります。ここでは「サブスクリプション」または「設定」画面からリモートインポートする手順を説明します。ファイルしか受け付けない画面が表示された場合は、一つ前の画面に戻ってURL入力欄を探してください。URLをテキストファイルとして保存し、YAMLの代わりに読み込ませることはできません。

1. 対応する形式のURLをコピーします。サービス提供元の管理画面でClashまたはClash Meta/mihomoの項目を選びます。コピーするのはサブスクリプションURLです。管理画面のトップページ、決済ページ、ドキュメントのURLではありません。URLの先頭や末尾に空白、改行、日本語の句読点が混ざっていないことも確認してください。
2. リモート設定の画面を開きます。クライアントの「サブスクリプション」または「設定」画面を開きます。URL入力欄があれば貼り付けて「インポート」を選択します。「新規作成」から追加する画面では、リモートを選び、URLを入力して保存してください。ローカルファイルの種類は選ばないでください。
3. ダウンロードと解析が完了するまで待ちます。設定カードが追加されたか、更新日時が表示されたか、通知欄にYAMLの解析エラーが出ていないかを確認します。カードが表示されただけでは、ダウンロードが完了したとは限りません。状態も確認してください。
4. 新しい設定を選択して有効にします。設定は複数保存できますが、実際に適用されるのは現在選択中の設定です。インポート後に選択状態を確認し、プロキシ画面に想定どおりのノードとプロキシグループが表示されているか確認してください。
5. ルールモードにして接続先を選びます。動作モードを「ルール」に設定し、サブスクリプション内の選択用グループからノードを選びます。一部のサブスクリプションでは初期状態で DIRECT が選択されています。この場合、通信が直接接続になっていても、ノードの故障とは限りません。
6. アプリの通信を確認します。システムプロキシを使う場合は、クライアントで「システムプロキシ」を有効にし、システムプロキシに従うブラウザーで接続をテストします。TUNで通信を取り込む場合は、TUNの権限とルーティング状態を別途確認してください。サブスクリプションをインポートしただけでは、TUNは有効になりません。

ローカルの待ち受けポートとサブスクリプションURLは別のものです。例にある 7890 は混合プロキシの待ち受けポートで、サブスクリプションサーバーのポートではありません。ログに address already in use と表示された場合は、同じポートを別のプロキシプロセスが使用していないか確認してください。サブスクリプションのトークンを何度もリセットする必要はありません。

サブスクリプションの更新間隔：クライアントとproviderの更新を区別する

リモート設定の更新は通常、クライアントのフロントエンドが担当します。設定全体を定期的に再ダウンロードし、クライアントの処理に従って再読み込みします。一方、設定内の proxy-providers は、この機能に対応したコアがノードリソースを更新します。これは別々のタイマーで動くため、画面上の「更新間隔」をYAMLの interval と同じものと考えないでください。

クライアントによるリモート設定の更新

• 初回インポート後：まず手動で更新し、URLにアクセスでき、正常に解析されることを確認してから、自動更新を有効にします。
• 通常の利用：まずは24時間ごとの更新を目安にし、サービス提供元の案内に従ってください。ノードの変更が頻繁な場合は6時間ごとも検討できますが、理由なく毎分取得する設定にはしないでください。
• 入力する単位に注意：24時間は1440分、86400秒です。画面の入力単位が分の場合、86400 を入力すると1日ごとの設定にはなりません。
• 更新が実行される条件を確認：クライアントによっては、アプリの起動中のみ定期更新が実行されます。端末のスリープ、ネットワーク切断、バックグラウンド実行の制限によって更新が遅れることがあるため、最後に更新が成功した日時を確認してください。

mihomoのノードprovider更新

mihomoのHTTPタイプのノードproviderでは、interval にリソースの更新間隔を秒単位で指定します。たとえば1日ごとの更新は interval: 86400 です。更新されるのはそのproviderが参照するノードリソースであり、外側の設定にあるすべてのルールが更新されるわけではありません。health-check の間隔はノードの疎通確認用で、サブスクリプションの更新間隔とは異なります。

サブスクリプションに proxy-providers がない場合、「自動更新を有効にする」ためだけに追加しないでください。クライアントのリモート設定にある定期更新機能を使えば十分です。複数階層で参照している場合は、外側の設定と各providerの最終更新日時をそれぞれ確認してください。

サブスクリプションをインポートできないときの対処法：HTTP・YAML・コアの互換性

問題がある階層を一つずつ切り分けます。まず正しい内容を取得できているか、次に現在のコアで解析できるか、最後にノードへ接続できるかを確認してください。以下のエラー内容を確認すると、「インポートできない」だけの場合より原因を絞り込めます。

ブラウザーで開けても、クライアントが同じ内容を取得できるとは限らない

ブラウザーはログインCookieを送信することがありますが、クライアントのリクエストには通常含まれません。また、サーバーがUser-Agentに応じて異なる内容を返す場合もあります。HTTP 200はリクエストへの応答が成功したことを示すだけで、応答内容がClash設定とは限りません。本文の先頭が <!DOCTYPE html> の場合は、ログインへのリダイレクト、アクセス認証、URLの誤りを先に解決してください。YAMLのインデントを直しても解決しません。

YAMLエラーはルールを変更する前に原文を確認

YAMLの階層は半角スペースでインデントし、タブで代用することはできません。チャットアプリにコピーすると、半角コロンが全角コロンに変わったり、インデントが崩れたりすることがあります。リモートサブスクリプションの原文に構文エラーがある場合は、機密情報を伏せたエラー行を提供元に伝えてください。起動させるために設定を丸ごと削除すると、ルールやDNS設定まで失うおそれがあります。

サブスクリプションは正常なのにWebページが開かない

まずクライアントの接続ログを確認します。対象のリクエストがなければ、システムプロキシまたはTUNによる通信の取り込みを確認してください。リクエストがある場合は、適用されたルール、プロキシグループ、実際の接続先を確認します。ノードの遅延テストに成功しても、特定のテスト通信ができることしか分かりません。すべてのドメイン、UDP通信、アプリの接続が正常とは限りません。サブスクリプションの取得、ノードの利用可否、アプリのプロキシ経由通信は、それぞれ個別に確認してください。

形式変換後・更新後に確認すること

サービス提供元から必要な形式を入手できず、クライアントも元の形式に対応していない場合に限り、サブスクリプションの変換を検討してください。変換ツールにサブスクリプションURLやノードの認証情報が渡る可能性があるため、提供元が明確でローカル実行できるツールを優先してください。URLを試すために、知らない変換サイトへ認証情報を送信しないでください。

1. 対象のコアを確認：出力形式が従来のClash互換設定かmihomo設定かを明確にし、使用するプロトコルが対応しているか確認します。変換で表現形式は変更できますが、古いコアに新しいプロトコルの実装を追加することはできません。
2. ルールの出所を確認：変換によってプロキシグループやルールが置き換わる場合があります。デフォルトの接続先、最後の MATCH の接続先、必要な直接接続ルールが維持されているか確認してください。
3. 更新方法を確認：変換後のローカルファイルを一度インポートすると、通常はその時点の静的な設定だけが保存されます。継続的に更新するには、元のサブスクリプションの取得、変換、設定の再読み込みを誰が定期的に行うのか明確にしてください。
4. 更新結果を確認：手動更新後、最終成功日時が変わったこと、ノード数が適切であること、現在の設定が選択されたままであることを確認します。次に、直接接続すべき宛先とプロキシ経由にすべき宛先を一つずつテストし、接続ログで接続先を確認してください。

動作モード、DNS、TUNの設定を確認する場合は技術リファレンスをご覧ください。初回利用の手順を順番に進めたい場合は入門チュートリアルから始めてください。まずサブスクリプションの形式と設定の選択を確認してから通信の取り込みを設定すると、原因を効率よく切り分けられます。