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

1. サブスクリプションURLと配信される内容を区別する

Clashにサブスクリプションをインポートするとき、混同しやすいのが「どこから取得するか」と「何を取得するか」です。URLはリモートリソースのアドレス、Base64はテキストのエンコード方式、YAMLは設定ファイルのデータ形式です。この3つは同じ階層の選択肢ではありません。同じHTTPSのサブスクリプションURLでも、返される内容はYAMLの場合もあれば、Base64でエンコードされたノード一覧の場合もあります。

URLをコピーできても、現在のクライアントで使える内容とは限りません。また、ファイル名が.yamlで終わっていても、サーバーが実際に設定を返している証拠にはなりません。互換性を判断するには、サブスクリプションの取得先、レスポンスの内容、クライアントが使用するコアをあわせて確認してください。

2. サブスクリプションURLのコピー、インポート、初回接続

1. 提供元で適切な設定の取得先を選ぶ

サブスクリプション提供元のアカウントページで、「Clash」または現在のコアに対応した取得先を探します。汎用サブスクリプション、Clash設定、mihomo設定が分かれている場合は、クライアントが実際に使用しているコアに合わせて選択してください。mihomoはClash Metaで後に使われるようになったコアの名称です。一部の拡張プロトコルやフィールドには対応状況の確認が必要で、画面が似ていても設定機能が完全に同じとは限りません。

• HTTPSのURLを省略せずにコピーし、?以降のクエリパラメーターや、&で区切られたパラメーターも残してください。
• アカウント管理ページ、決済ページ、共有方法の説明ページのURLはコピーしないでください。通常、こうしたページはHTMLを返します。
• チャットアプリで転送した後は、末尾に句点や引用符、改行が余分に付いていないか確認してください。本文の句読点まで一緒にインポートしないようにしましょう。
• ランダムに見えるトークンを自己判断で削除しないでください。サーバーがトークンでサブスクリプションの権限を識別している場合があります。

2. 設定管理画面にURLを貼り付ける

メニュー名はクライアントによって異なります。一般的な操作手順は「設定」→「新規作成」→「リモート」、または「サブスクリプション」→「追加」→「URL」です。入力欄にURLを貼り付け、設定名を付けてからダウンロードまたはインポートします。「ファイルからインポート」しかない場合、その項目はローカルファイルを読み込むためのものです。URLをファイルパスとして入力しないでください。

1. 初回インポートでは、現在使えている設定を残しておきましょう。
2. 新しい設定には「日常用サブスクリプション・メイン」など、見分けやすい名前を付けます。すべて「デフォルト」にするのは避けてください。
3. ダウンロードと解析が終わるまで待ち、一覧に行が追加されたかだけでなく、処理結果が成功になっているか確認します。
4. この設定を選択して有効にします。「追加済み」と「使用中」は別の状態です。
5. プロキシグループ画面を開き、想定したグループ名とノードが表示されていることを確認してから、接続先を選んでアクセスをテストします。

システムプロキシとTUNは通信を経由させる方法であり、サブスクリプションを使える設定に変換する機能ではありません。初回のトラブルシューティングでは、まず設定が読み込まれ、プロキシグループが表示されることを確認してから、システムプロキシやTUNを設定すると原因を切り分けやすくなります。ポート番号はクライアントに表示された値を使ってください。例でよく見かける7890が、すべての環境で使われているとは限りません。

3. Base64サブスクリプションをYAMLとしてそのまま使えない理由

汎用サブスクリプションでは、複数行のノードURIをBase64テキストにまとめて配信することがあります。デコードすると、ss://、vmess://、trojan://で始まる行が現れる場合があります。これらはノードの接続情報を表すもので、Clashに必要なプロキシグループ、ルールの順序、DNS設定まで含まれているとは限りません。

一部のクライアントにはノードのインポート機能やサブスクリプション変換機能がありますが、これはクライアント独自の追加機能です。すべてのClash設定画面が対応しているとは限りません。Base64テキスト全体をconfig.yamlとして保存しても、ファイル名が変わるだけで内容はYAMLになりません。

まずネイティブ形式での出力を選び、必要な場合のみ変換する

1. まず提供元のページに戻り、Clash用YAMLを直接返す取得先を探してください。
2. 汎用サブスクリプションしかない場合は、現在のクライアントがその形式と必要なプロトコルに対応しているか確認します。
3. 変換が必要な場合は、提供元の変換機能か信頼できるローカルツールを優先し、生成された設定のノード、プロキシグループ、ルールを確認してください。
4. 変換後も、元の配信元が分かる情報を残してください。ローカルファイルとして一度だけインポートした場合、その後のリモート側のノード変更は通常自動同期されません。

4. YAML設定：完全な設定ファイルとノードプロバイダーファイル

YAMLは構文形式にすぎず、ファイルの構造は使用する場所の要件を満たす必要があります。完全な設定には、待ち受けポート、ノード、プロキシグループ、ルール、DNSを含められます。一方、proxy-providersで使うノードファイルは、通常ノード情報だけを提供します。ルーティング設定まで用意されたProfileと同じものではありません。

以下は構造を理解するための最小限の直接接続設定です。リモートプロキシノードは含まれておらず、サブスクリプションの代わりにはなりません。有効にすると、ルールにより通信はDIRECTに送られます。mixed-port: 7890は、同じ待ち受けポートでHTTPとSOCKSのプロキシ接続を受け付ける設定です。使用前に、ポートがほかのプログラムに使われていないか確認してください。

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

proxies: []

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

rules:
  - MATCH,手動選択

設定を確認するときに見るべき3つのポイント

• ノードの取得元：proxiesにノードを直接定義するか、proxy-providersから読み込みます。インラインのノードが見当たらなくても、設定が空とは限りません。プロバイダーの読み込み状況も確認してください。
• プロキシグループの参照先：グループ内で指定するノード名、ほかのグループ名、プロバイダー参照が存在している必要があります。名前を変更すると、以前の参照が無効になることがあります。
• ルールの接続先：rulesの接続先は、有効なポリシーとして解決できる必要があります。例の「手動選択」はグループ名と完全に一致しています。一方を変更する場合は、もう一方も確認してください。

YAMLを編集するときはスペースでインデントし、Tabは使わないでください。パスワード、特殊文字、コロンを含む文字列は、YAMLの構文に従って適切に引用符で囲みます。リモートサブスクリプションの設定ファイルを直接編集すると、次回更新時に変更が上書きされる場合があります。変更を維持するには、クライアントが正式にサポートするオーバーライド、マージ、拡張機能を使い、適用順序も確認してください。

5. サブスクリプションの更新：リモート設定、ローカルファイル、上書き範囲

リモートのサブスクリプション設定は通常URLを保持し、更新時にコンテンツを再取得します。ローカルからインポートしたYAMLは、通常その時点のファイルのスナップショットです。ファイルの監視や自動更新に対応しているかどうかは、クライアントの実装によって異なります。どちらも設定一覧に表示されますが、更新元は異なります。

初回インポート後に手動で一度更新する

現在の設定のメニューから「更新」または「再読み込み」を選び、最終更新時刻が変わるか、処理が成功したかを確認します。定期更新に対応している場合は、まず24時間間隔に設定し、提供元の案内に合わせて調整してください。間隔の単位は分、時間、秒の場合があるため、入力欄の表記をよく確認します。短い間隔で繰り返しリクエストすると、サーバーで制限されることがあります。

• 更新は成功したのにノードが変わらない：サーバーが同じ内容を返しているか、別の設定が有効になっている可能性があります。現在のProfile名を確認してください。
• サブスクリプションの更新後もプロバイダーでエラーが出る：メイン設定のダウンロードと、proxy-providersからのリモートノード取得は別の処理です。それぞれ個別に確認してください。
• ローカルルールが消えた：リモート更新によって元のファイルが上書きされた可能性があります。長期的に使うルールは、サブスクリプション本文を繰り返し編集するのではなく、対応するオーバーライド設定に保存してください。
• 更新用URLが変わった：提供元がトークンをリセットすると、古いURLが無効になる場合があります。更新を何度も試すのではなく、保存済みのURLを新しいものに置き換えてください。

サブスクリプションのダウンロードにプロキシを使うかどうかも、クライアントの実装と関連設定によって異なります。「先に接続しないと更新できない」という状態が続く場合は、以前使えていた設定に戻してから新しい設定を更新してください。サブスクリプションを取得するためだけに、システムプロキシ、DNS、TUNを同時にリセットしないでください。

6. インポート後にノードが表示されない：リクエスト、形式、読み込み順を確認

「ノードが表示されない」問題は、ダウンロード前、解析中、表示段階のいずれでも起こり得ます。エラーの原文を残し、次の表に沿って原因を絞り込みましょう。再インストールを繰り返すより効果的です。ログにURLのパラメーター、ノード認証情報、アカウント識別情報が含まれる場合は、共有前に隠してください。

「接続テストのタイムアウト」を「インポート失敗」と決めつけない

ノードが表示された後に遅延テストがタイムアウトする場合、問題は通常、接続テストの段階まで進んでいます。テスト先のURLに到達できない、ノード認証に失敗する、ネットワークで遮断される、DNSに問題があるといった原因でタイムアウトすることがあります。正常なYAMLを別形式に変換し直すのではなく、該当する接続ログを確認してください。

一方、設定カードに「追加成功」と表示されても、コアが設定を受け入れたとは限りません。先に設定を保存し、その後にダウンロードや切り替えを行う画面もあります。最終的に、ダウンロード成功、コアの読み込み成功、現在の設定が選択済み、プロキシグループの参照が有効、のすべてを確認してください。

7. インポート後の確認リスト

• サブスクリプションの提供元が明確で、URLが完全な状態になっている。トークンが公開スクリーンショットやメモに写っていない。
• レスポンスが現在の取得先の要件を満たしている。完全なYAML、ノードプロバイダーファイル、Base64のノード一覧を区別できている。
• 正しいProfileが有効になっており、プロキシグループに想定したノード、または正常に読み込まれたプロバイダーが表示されている。
• 手動更新が少なくとも1回成功しており、自動更新の間隔とクライアントに表示される単位が一致している。
• ローカルルールを別途バックアップし、サブスクリプションの更新で変更が上書きされるか確認している。
• 接続テストに失敗した場合は具体的なエラーを記録し、設定の読み込み、ノード接続、通信の経由設定の順に対処する。

システムプロキシ、ルールモード、TUNの設定方法はClashの使い方ガイドをご覧ください。ノード、プロキシグループ、ルールの参照関係を確認するには、上級設定を参照してください。まずサブスクリプションの形式と更新経路を確認してから通信の経由設定を変更すると、原因を絞り込みやすくなります。