Clashのサブスクリプションをインポートする方法｜URL・ローカルファイル・形式の違い

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

Clashのサブスクリプションをインポートするときに重要なのは、リンクの名前ではなく、リンク先から返される内容です。https://で始まっていても、WebリソースのURLであることを示すだけで、Clash設定が返されるとは限りません。末尾が.yamlでも、ファイルの構造が正しいとは限りません。まず、サービス提供元のサブスクリプションページで、使用中のクライアントのコアに合った出力形式を選び、URL全体をコピーしてください。

取得した内容	見分け方	適切なインポート方法
リモートClash設定	URLからプロキシ、グループ、ルールを含むYAMLが返される	設定画面のURLインポート、またはリモート設定の追加
ローカル設定ファイル	端末に保存した`.yaml`または`.yml`ファイル	ファイルのインポート、またはローカル設定の追加
プロキシノードのリスト	複数行の`ss://`や`vmess://`などのリンク、またはそれらをBase64エンコードした文字列	ノードの解析に対応したインポート方法を使うか、先に設定ファイルへ変換
プロキシプロバイダーファイル	トップレベルに`proxies:`のリストだけがある	メイン設定の`proxy-providers`に指定し、プロキシグループから参照

クライアントは設定の管理や画面操作を担当し、コアは設定の解析、ルール処理、接続の確立を担当します。mihomoコアを使うクライアントなら、対応する新しいプロトコルや項目を認識できますが、旧バージョンのオリジナル版Clashでは同じ設定を使えない場合があります。つまり、形式が正しいことと、コアが対応していることは別々に確認が必要です。

PCでURLからインポート：リモート設定を追加して有効化

Clash Verge Revなどのデスクトップクライアントでは、「設定」→「新規作成」→リモートを選択→サブスクリプションURLを入力→保存し、追加した設定を選択します。画面の表示はバージョンによって異なり、設定画面の上部にURL欄がある場合や、ボタンが「インポート」と表示される場合もあります。いずれも、リモート設定を追加する操作です。

サブスクリプションURLをコピーします。提供元のページでClash向け、またはmihomo対応の形式を選びます。末尾のパラメーターを取りこぼさないよう、ページのコピー機能を使ってください。ログインページや請求ページのURLはコピーしないでください。
リモート設定を追加します。設定画面を開き、URL欄にアドレス全体を貼り付け、見分けやすい短い名前を付けます。提供元から指定がない限り、リクエストヘッダー、User-Agent、更新間隔はまず既定値のままにします。
初回ダウンロードを実行します。保存またはインポートをクリックし、設定が一覧に表示されるまで待ちます。解析エラーが出た場合は、システムプロキシを何度もオンにするのではなく、返された形式を確認してください。
設定を選択して読み込みます。追加した項目が現在使用中になっていることを確認します。一覧に追加しただけでは、コアがその設定に切り替わっていない場合があります。
プロキシグループを確認します。プロキシ画面を開き、グループと選択可能なノードがあることを確認してから、必要に応じてシステムプロキシを有効にします。まずはルールモードで動作を確認し、TUNを同時に有効にする必要はありません。

URLを貼り付けるときの注意点

URLの前後にある空白、引用符、改行は取り除きます。ただし、?以降のクエリパラメーターは不用意に削除しないでください。
HTMLソースからコピーした&はエスケープされた表記です。元のページに戻り、コピー機能で実際のURLを取得してください。
HTTPSをHTTPに変更しないでください。証明書エラーが出た場合は、端末の時刻、ネットワーク環境、サーバー証明書を確認します。
User-Agentに応じて異なる内容を返すサービスもあります。提供元から指定された場合に限り、クライアントのサブスクリプション取得用User-Agentを変更してください。

スマホでインポート：URL・クリップボード・QRコード

Androidクライアントでは、「設定」画面の追加ボタンからURL、ファイル、QRコードを選ぶのが一般的です。mihomo対応のモバイルクライアントを例にすると、まず設定を追加して現在の設定に指定し、その後接続を開始します。初回起動時に表示されるシステムVPNの許可は、端末内の通信を経由させるためのものです。サブスクリプションのダウンロードとは別の手順なので、許可できたことだけでサブスクリプションが使えるとは判断できません。

サブスクリプションページで使用中のクライアントに合ったURLをコピーし、クライアントの設定一覧に戻ります。
設定の追加画面を開き、URLインポートを選んでアドレスを貼り付けます。QRコードを使う場合は、コードの内容がサブスクリプションURLであり、単一ノードのリンクではないことを確認してください。
保存してダウンロードが終わるまで待ち、設定名、プロキシグループ、エラーメッセージを確認します。
現在の設定に指定して接続を開始し、システムの許可を確認します。その後、アクセスできることが分かっているWebサイトを開いて動作を確認します。

iOSクライアントで使える形式やインポート方法はアプリごとに異なるため、Androidのメニュー手順をそのまま当てはめることはできません。アプリが独自のサブスクリプション形式しか受け付けない場合は、提供元のページで対応する形式を選んでください。この記事で説明する完全な設定ファイルを読み込めるのは、Clash YAMLに対応していることが明記されたインポート機能に限られます。

ローカルYAMLをインポート：ファイル構造とインデントを確認

ローカルファイルは、オフラインで設定を保存したいとき、既存設定を移行するとき、サブスクリプションのダウンロード問題を調べるときに便利です。クライアントで「設定」→「ファイルをインポート」を選び、実際に保存した.yamlまたは.ymlファイルを指定します。読み込み後、その設定を選択して有効にしてください。Webページをファイルとして保存するとHTMLになることがあり、拡張子を変更してもYAMLにはなりません。

以下は、設定を読み込めるか確認するための直結サンプルです。ローカルの待ち受けポートとフォールバックルールを明示し、プロキシノードは含みません。「クライアントがYAMLを読み込めるか」と「リモートサブスクリプションからプロキシを取得できるか」を切り分けるのに使えます。

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

proxies: []
proxy-groups: []

rules:
  - MATCH,DIRECT

mixed-port: 7890は、このサンプルが同じローカルポートでHTTPとSOCKSのプロキシ接続を受け付けることを示します。ポートが使用中の場合は、ポート番号を変更するか、使用中のプログラムを終了してください。
allow-lan: falseは、LANからのアクセスを許可しません。最初の動作確認ではtrueに変更する必要はありません。
MATCH,DIRECTは、フォールバックルールに一致するすべての接続を直接接続します。そのため、このサンプルにリモートプロキシ機能はありません。
YAMLのインデントにはスペースを使い、Tabは使いません。ノード名にコロンと空白などの特殊文字が含まれる場合は、適切に引用符で囲んでください。

ローカルファイルをインポートすると、クライアントがコピーを保存することがあります。元のファイルを編集しても、インポート済みの設定に反映されるとは限りません。通常のローカル設定は、リモートの完全な設定を自動で再取得しませんが、個別に定義されたリモートプロバイダーは設定に応じて更新される場合があります。サブスクリプション全体を継続的に同期するには、リモートURLの設定を使ってください。

Base64形式のノードリストと完全な設定の違い

Base64はエンコード方式であり、プロキシプロトコルでも暗号化方式でもありません。Base64文字列をデコードすると、複数のノードリンクだけが含まれている場合があり、通常はClashで必要なプロキシグループやルーティングルールがありません。そのまま完全なYAMLとしてインポートすると、解析に失敗したり、ノード情報だけが読み込まれて選択やルーティングに必要な構造が欠けたりすることがあります。

完全な設定ファイルとプロバイダーファイルは別物

完全な設定では、proxiesでノードを直接定義する方法と、proxy-providersで外部のノードリソースを読み込む方法があります。プロキシグループからproxiesまたはuseで参照し、ルールで接続先を決めます。トップレベルにproxies:だけを記述したファイルは、プロバイダーとして解析できても、グループやルールが設定済みのメイン設定と同じではありません。

形式を変換する場合のおすすめ手順

まず、対応形式をそのまま出力します。変換の工程を減らすため、提供元が生成するClashまたはmihomo設定を優先してください。
次に、クライアントの対応状況を確認します。ノードリンクを読み込んで設定を自動生成できるクライアントもあれば、完全なYAMLのみ対応するものもあります。使用中のクライアントの説明を確認してください。
最後に、必要な場合だけ変換します。変換が必要な場合は、信頼できるツールか自分で構築したツールを使い、ノードのプロトコル、通信パラメーター、プロキシグループのテンプレート、ルールの提供元を確認してください。

変換ツールが元のサブスクリプションやすべてのノード認証情報を扱う場合があります。出所が不明な公開変換サイトに、個人用のサブスクリプションを入力しないでください。変換しても、古いコアに未対応のプロトコルを追加することはできません。ノードがmihomoの機能を必要とする場合は、出力ファイルの名前を変えるだけでなく、クライアントが実際に使用しているコアを確認してください。

サブスクリプションをインポートできないときの対処：ダウンロード・解析・接続を切り分ける

まずクライアントのログでエラーが起きた段階を確認し、変更する設定を判断します。ダウンロードエラーは内容の取得時、解析エラーは取得した内容の読み込み時に発生します。設定を読み込めたのにWebサイトを開けない場合は、プロキシ接続、ルール、DNSを調べます。これらを一度に対処すると、正常だった設定まで変えてしまうことがあります。

症状・ログ	まず確認すること	次の対処
HTTP 401または403	トークンの期限切れ、アクセス制限、認証要件	有効なサブスクリプションURLを再取得し、アカウントの状態と提供元の案内を確認
HTTP 404	URLのパスが誤っている、または古い接続先が無効	手動でURLを組み立てず、サブスクリプションページから再取得
HTTP 429	リクエストの頻度が高すぎる	連続での更新をやめ、サーバー側の指定に従って時間をおいてから再試行
タイムアウトまたはドメインの名前解決エラー	サブスクリプションのドメインに接続できない	ローカルのDNS、ネットワーク、クライアントが更新リクエストに使う接続方法を確認
YAMLの解析エラー、HTMLが返される	ログインページ、エラーページ、または別の形式をダウンロードしている	サブスクリプションの出力形式を確認し、インデントとエラー行付近の内容を調べる
不明なプロキシタイプ、または未対応の項目	コアのバージョンとプロトコルの対応状況が合っていない	コアの種類を確認し、対応する形式を選ぶか、適切なクライアントに更新

ブラウザーでは開けるのに、クライアントで失敗するのはなぜ？

ブラウザーはログインCookieを送ることがありますが、クライアントは通常、独立してサブスクリプションを取得します。また、ブラウザーはシステムプロキシを使う一方、クライアントの更新リクエストは直接接続、または専用のダウンロード設定を使う場合があります。そのため、ブラウザーにアカウントページが表示されても、クライアントがYAMLを取得できたとは限りません。更新にプロキシが必要な場合は、まず読み込み済みの設定が使えることを確認してから、クライアントのサブスクリプション更新用プロキシ設定を確認してください。まだ接続設定がない状態で、初回インポートをプロキシ経由にしようとしないでください。

設定を読み込めたのにWebサイトを開けない

現在選択されている設定が、今回インポートしたものか確認します。プロキシグループで使用可能なノードが選ばれているかも確認してください。
プロキシモードを確認します。ルールモードはルールに従って接続先を選び、直結モードではノードを経由しません。グローバルモードにしても、ノード自体に接続できない問題は解決しません。
システムプロキシのポートと実際の待ち受けポートが一致しているか確認します。たとえば、実際の待ち受けが7890なのに、システムプロキシが古い7897を指定していると、アプリが接続できないことがあります。
システムプロキシに従わないアプリでは、別の通信制御方法が必要かを確認してからTUNを検討してください。TUNをサブスクリプション形式の修復手段として使わないでください。

自動更新とローカル上書き：繰り返し使える設定手順

リモートサブスクリプションの更新では、通常、その項目のリモート内容が置き換わります。ダウンロードしたYAMLを直接編集すると、次回の更新で変更が失われる場合があります。DNSの固定、自分で追加したルール、プロキシグループの調整が必要な場合は、クライアントが対応するオーバーライド、設定のマージ、スクリプト機能を優先し、適用順も確認してください。オーバーライドの書式はクライアントによって異なります。あるクライアント用のスクリプトを、コアの設定項目として使うことはできません。

まず手動で一度更新します。ダウンロードと解析が正常に行えることを確認してから、定期更新を設定します。まずは24時間間隔にし、提供元の案内に応じて調整すると、短時間にリクエストを繰り返さずに済みます。
更新対象を区別します。完全な設定、プロキシプロバイダー、ルールプロバイダーには、それぞれ別の更新間隔が設定されている場合があります。ひとつを更新しても、ほかのリソースがすべて更新されるわけではありません。
オーバーライドの適用結果を確認します。編集画面だけでなく、最終的に有効な設定とログを確認してください。カスタムルールは記述する位置によって結果が変わり、通常、フォールバックのMATCHより後のルールは照合されません。
復旧手段を残します。動作を確認した設定のコピーを保存し、元のサブスクリプションの入手先も記録してください。更新に失敗したら、まず動作する設定に戻してから原因を調べます。

インポート後の最低限の確認項目は、リモートからのダウンロードが成功すること、コアが設定を読み込めること、プロキシグループでノードを選べること、対象アプリの通信が想定したルールを通ることです。システムプロキシやTUNの設定はサブスクリプションのインポートと接続設定ガイドを、項目やDNSの設定は設定マニュアルを参照してください。更新に失敗した場合の対処はサブスクリプション更新のトラブルシューティングをご覧ください。