サブスクリプションの内容を確認してから読み込む
サブスクリプションURLを入手済みなら、まずはクライアントのリモートURL読み込みを使いましょう。QRコードは別のデバイスへのURL共有に便利で、ローカルYAMLはオフラインでの移行や設定内容の確認に向いています。いずれも設定をクライアントに渡す方法であり、対応プロトコルが変わったり、形式の問題が自動修正されたりするわけではありません。
読み込み前に、サブスクリプション提供元のページでClashまたはClash Meta / mihomo形式を選び、URL全体をコピーしてください。アカウントのログインページ、プラン管理ページ、サブスクリプションURLは別のものです。URLの「?」以降のクエリパラメーターには認証トークンが含まれる場合があります。コピー時に削除せず、末尾の句読点を誤って含めないようにしてください。
| 方法 | 適した用途 | 更新の仕組み |
|---|---|---|
| リモートURL | アクセス可能なClash設定URLがある場合 | URLを保持して手動更新できます。自動更新はクライアントの設定によります。 |
| QRコード | 別のデバイスからサブスクリプションURLやノード情報を読み取る場合 | リモートURLを含むQRコードなら、読み込み後にリモート設定として更新できます。 |
| ローカルYAML | ダウンロード済みの完全な設定を移行するときや、設定内容を調べるとき | ローカル設定は通常、元のサブスクリプションを自動取得しません。設定内のリモートproviderは個別に更新できます。 |
URLから読み込む：設定を取得したら有効化する
デスクトップクライアントでは、リモート設定は通常「サブスクリプション」や「設定」画面にあり、システムプロキシ設定とは別です。以下では一般的な画面名で説明します。リリース版や表示言語によってボタン名が異なる場合があるため、実際の表示に従ってください。
Windows・macOS・Linuxのデスクトップ版
- Clash Verge Revの場合、サイドバーの「サブスクリプション」を開き、サブスクリプションURLの入力欄にURL全体を貼り付けて「インポート」をクリックします。「新規作成」ダイアログが表示される場合は、リモート形式を選んでURLを入力してください。
- ダウンロードと解析が終わるまで待ちます。設定が一覧に追加され、更新日時が変わったことを確認してください。空の設定カードが表示されただけでは、内容の取得に成功したとは限りません。
- 追加した設定を選び、現在の設定として有効にしてから「プロキシ」画面でプロキシグループを確認します。設定を切り替えると、グループ名やルールが変わることがあります。以前選択していたノードだけを確認しないようにしてください。
- 「設定」でシステムプロキシを有効にするか、必要に応じてTUNを有効にします。まずはネットワーク関連の設定を複数同時に変更せず、接続方法を一つに絞って確認してください。
FlClashなどのクライアントでも、設定管理からリモート設定を追加し、現在使用する設定として選ぶ必要があります。macOSでClashX Metaを使う場合は、メニューバーアプリの「設定」→「管理対象設定」から管理画面を探してください。別のクライアントのメニュー手順をそのまま当てはめたり、「コアが起動している」ことを「新しいサブスクリプションが有効」と判断したりしないでください。
Android・iOSのモバイル版
- Clash for Androidでは通常、「設定」→「＋」→「URLからインポート」の順に進みます。名前とサブスクリプションURLを入力して保存し、リモートコンテンツのダウンロードが完了するまで待ちます。
- 設定一覧に戻って追加した項目を選び、ホーム画面に戻って起動します。Androidで初めてVPN接続を確立するときは、システムの許可が必要です。別のVPNが接続を使用中の場合は、先に停止してください。
- ほかのAndroid・iOSクライアントを使う場合は、「設定」または「サブスクリプション」からURL読み込みを選び、対応するサブスクリプション形式とノードプロトコルを確認してください。iOSクライアントがClash YAMLに対応しているとは限りません。「サブスクリプション」ボタンがあるだけで互換性を判断しないでください。
リモート読み込みに失敗したら、まずエラーの内容を確認します。接続タイムアウトはネットワーク経路の問題が考えられます。HTTP 401または403は、認証情報の失効、アクセス制限、サーバー側のブロックなどが一般的な原因です。ダウンロード後に解析エラーが出る場合は、取得した内容とコアの互換性を確認してください。原因ごとに対処が異なるため、何度もインポートをクリックして試すのは避けましょう。
QRコードから読み込む：サブスクリプションURLと単一ノードを見分ける
QRコードはテキストを格納するためのものです。HTTPSのサブスクリプションURLが含まれている場合もあれば、ss://、vmess://、trojan://で始まる単一ノードのURIが含まれている場合もあります。スキャンに成功しても、テキストを読み取れただけで、クライアントが完全な設定として利用できるとは限りません。
- クライアントの設定追加画面でQRコードの読み取り機能を探します。カメラへのアクセス許可を求められたら、システムの案内に従って許可してください。QRコードを写真アプリに保存している場合は、クライアントに対応機能があれば画像から読み取れます。
- 読み取り後、内容の種類を確認します。HTTPS URLの場合は、信頼できるサブスクリプション提供元のものか確認してから、リモート設定として保存します。単一ノードのURIの場合は、クライアントが対応するノード読み込み手順に進んでください。
- 読み込み後、設定一覧とプロキシグループを確認します。単一ノードを読み込んだ場合、ノードが一つ追加されるだけで、ルールやDNS、プロキシグループは含まれないことがあります。必要に応じてクライアントの設定テンプレートを併用してください。
同じデバイスで画像から読み取る機能が使えない場合は、元のサブスクリプションURLを直接コピーするほうが確実です。QRコードを読み取るために、サブスクリプションのQRコードを公開の解析サイトにアップロードしないでください。「対応していないQRコードの内容」と表示された場合は、サブスクリプションページに戻ってClash形式を選びます。ノードのQRコードをリモート設定の読み込み画面で何度も試すのは避けてください。
ローカルYAMLの読み込みと設定の移行
まずファイルをUTF-8で保存し、拡張子を.yamlまたは.ymlにします。次にクライアントの「ローカルファイル」「ファイルからインポート」などの項目から選択してください。Clash for Androidでは通常、「設定」→「＋」からファイルをインポートできます。デスクトップ版では、設定管理画面からローカル設定を新規作成するか、ファイルをインポートします。
拡張子だけではファイルの内容は判断できません。ブラウザーでダウンロードしたログインページは、config.yamlに名前を変えても設定として使えません。テキストエディターで冒頭を確認してください。<!DOCTYPE html>、ログインフォーム、サイトのエラー表示があれば、YAMLのインデントを修正するのではなく、サブスクリプション提供元から取得し直してください。
移行前に確認する3つのポイント
- 設定がそろっているか：使用可能なアウトバウンド設定と対応するポリシーが必要です。
proxies:だけのノード断片は、プロキシグループやルールを含む完全なサブスクリプション設定とは異なります。 - 依存ファイル：
proxy-providersとrule-providersで指定されたローカルパスを確認します。メインファイルをコピーしても、参照先のルールファイルやノードファイルは自動でコピーされません。 - 互換性：Clash Meta / mihomoの拡張フィールドやプロトコルは、古いClashコアではサポートされない場合があります。「サポートされていないプロキシタイプ」と表示されたら、フィールド名を削除するのではなく、コアの対応状況を確認してください。
ローカルファイルを読み込んだ後も、その設定を手動で選択する必要があります。外部エディターでファイルを変更した場合は、クライアントの再読み込み操作も実行してください。インポート時にファイルをコピーし、元のパスを継続して読み込まないクライアントもあります。
Clash YAMLとBase64形式のサブスクリプションの違い
「サブスクリプションURL」は取得方法を指す言葉で、ファイル形式を統一するものではありません。同じHTTPS URLでも、サーバーのパラメーターによってClash YAML、Base64エンコードされたノードリスト、または別のクライアント用JSON設定が返される場合があります。ブラウザーで開けても、現在のクライアントで解析できるとは限りません。
| 内容の種類 | 主な特徴 | 読み込み時の注意点 |
|---|---|---|
| Clash YAML | proxies、proxy-groups、rulesなどのキーを含む | 完全な設定かprovider用ノード一覧かを確認し、コアの対応範囲も確認します。 |
| Base64形式のノードリスト | デコードすると、通常はノードURIが1行ずつ並んでいます。 | 完全なルールセットを含まないことが多く、拡張子をYAMLに変えるだけでは変換できません。 |
| 単一ノードURI | ss://、trojan://などのプロトコル接頭辞で始まる | クライアントのノード読み込み機能が必要です。リモート設定URLとして使えるとは限りません。 |
| その他のJSON設定 | JSONオブジェクトまたは配列にノードや設定をまとめている | 対応するコア、またはその形式に明示的に対応した読み込み機能を使用してください。 |
Base64はエンコード方式であり、ノードのプロトコルでも暗号化でもありません。サービス提供元が複数の形式を用意している場合は、Clashまたはmihomo向けの設定を選んでください。変換が必要なら、信頼できるローカルツールか自分で運用する変換サービスを使いましょう。完全なサブスクリプションURLを変換サービスに渡すと、ノードの認証情報も読み取られる可能性があります。
混同しやすいものにproxy-providerファイルがあります。YAMLとして正しくても、一般的にはproxiesの一覧だけを含み、メイン設定のproxy-providersから参照して使います。完全な設定として直接有効にすると、想定したプロキシグループやルールがない場合があります。一方、完全な設定がproviderを主に利用し、ノードを直接記載していないこともあります。特定のキーがあるかどうかだけで、ファイルの正否を判断しないでください。
読み込み後に反映されない場合は、4つのポイントを確認
1. 設定が正しく読み込まれているか
まず、現在選択されている設定名と直近の読み込みログを確認します。YAMLの解析エラーが記録されている場合は、エラー行のインデント、コロン、引用符を確認してください。YAMLのインデントにはスペースを使い、タブは使いません。ルールで参照するプロキシグループ名は、設定内の名前と一致している必要があります。ダウンロードに成功しても読み込みに失敗すると、以前の設定で動作を続ける場合があります。
2. アプリが正しいプロキシポートを使っているか
システムプロキシが有効でなければ、設定を読み込んだだけで通常のブラウザートラフィックが自動的にコアへ送られることはありません。以下はポートの関係を説明する設定例であり、単独で使えるサブスクリプションではありません。
mixed-port: 7890
mode: rule
log-level: infomixed-port: 7890は、同じ待ち受けポートでHTTPとSOCKSのプロキシ接続を受け付ける設定です。現在の設定でこのポートを使っている場合、アプリのプロキシを手動設定するときは127.0.0.1:7890を指定できます。実際の値はクライアントの動作設定を確認してください。クライアントによっては、サブスクリプション内のポート設定を上書きします。コントロールAPIのポートはトラフィック用プロキシポートとは異なるため、ブラウザーのプロキシ設定に入力しないでください。
3. プロキシグループに利用できる接続先があるか
プロキシグループから特定のノードを選び、遅延テストを実行します。結果がtimeoutなら、まずテスト先のアドレスとノードへの接続を確認してください。120 msなどの数値が表示されても、そのテストリクエストが完了したことを示すだけで、すべてのサイトに接続できる保証にはなりません。対象サイトを開き、接続ログに記録されたルール、プロキシグループ、最終的な接続先を確認すると、リクエストの経路を特定できます。
4. トラフィックの転送方法とDNS設定が合っているか
ルールモードでは、ルールの順序に従って接続先が決まります。対象がDIRECTに一致すると、プロキシノードを選んでいても直接接続される場合があります。TUNモードはルーティング条件に一致するトラフィックを取り込みますが、対応する権限とルート設定が必要です。非対応のサブスクリプションを使える設定に変える機能ではありません。DNSエラーが発生したら、まず名前解決のログを確認し、設定内のDNS上流、Fake-IP設定、フィルター項目を調べてください。複数のパラメーターを手当たり次第に変更するのは避けましょう。
- 設定一覧に何も表示されない：ダウンロード結果、サブスクリプションURL、形式を確認します。
- 設定はあるのに想定したプロキシグループがない：ノード一覧だけを読み込んでいないか、古い設定を使用していないか確認します。
- プロキシグループにノードがあるのにタイムアウトする：ノードの状態、プロトコルの互換性、基本的なネットワーク接続を確認します。
- テストは成功するのにブラウザーに変化がない：システムプロキシ、TUNによるトラフィックの取り込み、ブラウザー個別のプロキシ設定、接続ログを確認します。
更新機能を保ち、元に戻せる設定を用意する
初回の読み込みと接続確認が済んでから、自動更新を設定してください。設定全体のサブスクリプション更新とproviderのintervalは別の仕組みです。前者はクライアントがリモート設定全体を取得し、後者はコアが設定内で参照されるリモートリソースを更新します。providerの秒数をクライアントのサブスクリプション更新間隔と混同しないでください。クライアントの画面では分や時間で指定する場合があります。
サブスクリプション全体の更新間隔は、まず24時間に設定し、提供元の案内に合わせて調整できます。モバイル端末では、バックグラウンド更新がシステムの省電力設定にも左右されます。周期を設定しても、アプリの停止中に予定どおり動作するとは限りません。更新前に使える設定を一つ保存し、更新後はプロキシグループ、ルール、現在の接続先を確認してください。再インポートやクライアントの変更が必要な場合は、利用ガイドのサブスクリプション設定手順を確認してから、接続を再検証してください。